amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Hintergrundbild für eigenen Screen laden [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- [ - Beitrag schreiben - ]

16.04.2010, 17:46 Uhr

Holger
Posts: 8116
Nutzer
@whose:
Was Du schreibst, ist ja alles richtig. Aber ändert letztendlich nichts daran, dass ein Spiel, das nunmal nicht nur rechteckige Objekte besitzt (wie sähe das denn aus...), diese Objekte irgendwie zeichnen muss. Und egal, ob die Routine zum Zeichnen eines Objekts den Blitter oder die CPU, Chip-, Fast- oder VideoRAM verwendet, ändert das nichts daran, dass um diese Routine herum ein Algorithmus gebaut werden muss, der alle Objekt zeichnet, bzw. aktualisiert und das möglichst effizient.

Zitat:
Original von Reth:
Kann ich denn mit Layern und ClipRegions verhindern, dass dargestellte Objekte innerhalb eines Layers durch darüber liegende Layer und deren Darstellung "zerstört" werden?
Das würde eine Neudarstellung von überdeckten Objekten von "unten" nach "oben" erleichtern!

Was meinst Du mit zerstört? Die Teile, die von einem anderen Objekt verdeckt sind, sind auf dem Bildschirm auch nicht vorhanden. Wenn sich ein Objekt aus einer Verdeckung hervor bewegt, muss der Teil, der vorher nicht sichtbar war, aktualisiert werden, und zwar nur dieser Teil. Das beherrscht die layer.library.

Das ganze ist doch gar nicht so schwierig zu verstehen. Guck Dir die Workbench an, mache ein Dutzend Fenster auf und schiebe diese hin und her, auch mal eines, das teilweise hinter anderen liegt. Das sind nichts anderes als Layer, nur halt um Rahmen, Gadgets, MessagePort und Eingabeverwaltung erweitert. Aber die logische Zeichenfläche, das ist ein Layer.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.04.2010, 18:07 Uhr

Reth
Posts: 1858
Nutzer
@whose:

Hmpf! Na toll! Heisst das, ich sollte ne Fallunterscheidung programmieren für Amiga-native Screens und RTG-Screens oder 2 Executables machen?

Zitat:
Original von whose:
Das bedeutet im Endeffekt, daß das böse "Lesen aus dem VMEM" ständig vorkommt, weil Du mit hoher Wahrscheinlichkeit die zu blittenden Bitmaps als Friend und Displayable angelegt hast (das wird einem ja auch dauernd als essentiell verkauft. Blöd nur, daß das nur bei nicht-maskiertem Blitten/Vanilla-Copy wirklich sinnvoll ist. Wieder eine Klippe mehr, die "dank" RTG umschifft werden muß).


Dann sollte ich die BitMaps nicht auf diese Weise anlegen, auch wenn der Nutzer mal einen AGA-Screen nutzen will?

Zitat:
Original von whose:
Meiner Meinung nach solltest Du Dich mehr darauf konzentrieren, so wenig wie überhaupt möglich durch Masken zu blitten.


Was wäre dann die Alternative?

Zitat:
Original von whose:
Noch schneller wäre, vollständig auf die Blit-Funktionen der RTG-Systeme zu verzichten und statt dessen die erforderlichen Bilddaten aus dem FastRAM zur GraKa zu schieben. RLE kann da schon hilfreich sein, da Du damit eine Art Maske implementieren kannst.


Vom direkten Programmieren des GraKa-Speichers hab ich keinerlei Ahnung, v.a. nicht, wie dabei solche Dinge wie maskiertes Blitten umgesetzt werden sollen.

Zitat:
Original von whose:
Erwarte aber keine Wunder auf Z2-Systemen


Ich habe bei meiner ersten Version Performanceprobleme auf einer CSPPC mit 060 und CVPPC gehabt. Also mehr geht ja für AOS3.x auf Amigas schon nicht mehr!

Ciao

[ - Antworten - Zitieren - Direktlink - ]

16.04.2010, 18:12 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
@whose:
Was Du schreibst, ist ja alles richtig. Aber ändert letztendlich nichts daran, dass ein Spiel, das nunmal nicht nur rechteckige Objekte besitzt (wie sähe das denn aus...), diese Objekte irgendwie zeichnen muss. Und egal, ob die Routine zum Zeichnen eines Objekts den Blitter oder die CPU, Chip-, Fast- oder VideoRAM verwendet, ändert das nichts daran, dass um diese Routine herum ein Algorithmus gebaut werden muss, der alle Objekt zeichnet, bzw. aktualisiert und das möglichst effizient.


Das will ich Reth ja auch gar nicht ausreden ;) Er und ich haben uns schon vor längerer Zeit mal über das Thema unterhalten, nur war mir damals noch nicht bewußt, wie bescheiden RTG in Sache Blitten arbeitet.

Da bringt es ihm dann nicht viel, wenn er den Flaschenhals in der Tiefensortierung seiner Grafikobjekte vermutet, obwohl er eigentlich ganz woanders steckt und sein eigener Algorithmus zur Objektsortierung möglicherweise schon effizient genug ist, oder?

Ist aber sicher nicht verkehrt, wenn Du ihm da ein bißchen Hilfestellung gibst bzw. über die Schulter schaust :)
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

16.04.2010, 18:27 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Da bringt es ihm dann nicht viel, wenn er den Flaschenhals in der Tiefensortierung seiner Grafikobjekte vermutet, obwohl er eigentlich ganz woanders steckt und sein eigener Algorithmus zur Objektsortierung möglicherweise schon effizient genug ist, oder?

Es geht ja nicht um den Algorithmus zur Sortierung (die Objekte müssen so oder so sortiert vorliegen), sondern darum, dass man mit dem richtigen Algorithmus unterm Strich möglicherweise weniger Pixel transferieren muss, wovon man gerade dann profitiert, wenn der Transfer so langsam ist.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.04.2010, 18:28 Uhr

Reth
Posts: 1858
Nutzer
Zitat:
Original von Holger:
Was meinst Du mit zerstört? Die Teile, die von einem anderen Objekt verdeckt sind, sind auf dem Bildschirm auch nicht vorhanden. Wenn sich ein Objekt aus einer Verdeckung hervor bewegt, muss der Teil, der vorher nicht sichtbar war, aktualisiert werden, und zwar nur dieser Teil. Das beherrscht die layer.library.

Das ganze ist doch gar nicht so schwierig zu verstehen. Guck Dir die Workbench an, mache ein Dutzend Fenster auf und schiebe diese hin und her, auch mal eines, das teilweise hinter anderen liegt. Das sind nichts anderes als Layer, nur halt um Rahmen, Gadgets, MessagePort und Eingabeverwaltung erweitert. Aber die logische Zeichenfläche, das ist ein Layer.


Das hab ich ja auch verstanden, ebenso das Prinzip, dass die Layers-Library nur mit rechteckigen Bereichen (bis AOS3.x) in dieser Form umgehen kann!

Mein Gedanke war der, dass ich mir die Funktionalität der Layers-Library zu Nutze mache, die mir die überdeckten Bereiche ermittelt (was ich derzeit selber ausprogrammiert habe), das Blitten durch Masken aber nach wie vor selber erledige.

Nach dem Verständnis Deiner bisherigen Beiträge zu diesem Thema sehe ich das aber so, dass mir das wohl nicht hilft, da die Layer durch ihre rechteckige Ausdehnung mir dann wohl eher im Weg stehen.

Zitat:
Original von whose:
Ist aber sicher nicht verkehrt, wenn Du ihm da ein bißchen Hilfestellung gibst bzw. über die Schulter schaust :)


Na da wär ich aber sehr für verbunden! :D

@All:
Übrigens natürlich auch allen, die immer so hilfreich posten und antworten (z.B. Thomas Rapp u.a.)!

Vielen Dank und weiter so Leute!

[ - Antworten - Zitieren - Direktlink - ]

16.04.2010, 18:31 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Reth:
@whose:

Hmpf! Na toll! Heisst das, ich sollte ne Fallunterscheidung programmieren für Amiga-native Screens und RTG-Screens oder 2 Executables machen?


Wenn es auf beiden möglichen Grafik-Varianten wirklich schnell sein soll: Ja (welche Möglichkeit Dir als die bessere erscheint).

Du würdest staunen, wie schnell AGA sein kann, wenn man etwas tiefer angreift. Direkte Blitter-Programmierung usw.

Zitat:
Dann sollte ich die BitMaps nicht auf diese Weise anlegen, auch wenn der Nutzer mal einen AGA-Screen nutzen will?

Naja, das ist der Nachteil dabei: Für AGA auf einer RTG-Maschine (ja, es gibt so verrückte Leute, die das ausprobieren) würdest Du das wieder brauchen, da die Bitmaps sonst möglicherweise im FastRAM landen. Was das bedeutet brauche ich glaube ich nicht extra zu erwähnen.

Zitat:
Zitat:
Original von whose:
Meiner Meinung nach solltest Du Dich mehr darauf konzentrieren, so wenig wie überhaupt möglich durch Masken zu blitten.


Was wäre dann die Alternative?


Gute Frage... das hängt von Deinen Grafiken ab. Bei den Sechsecken ist allerdings schon Essig mit ohne ;) Maske...

Zitat:
Vom direkten Programmieren des GraKa-Speichers hab ich keinerlei Ahnung, v.a. nicht, wie dabei solche Dinge wie maskiertes Blitten umgesetzt werden sollen.

Ist im Prinzip nicht anders wie bei einer stinknormalen Offscreen-Bitmap, die Du per CPU mit Werten füllst. Nur die Adresse ist eine andere und liegt physikalisch auf der GraKa.

Ich habe allerdings auch nicht gesagt, daß das irgendwie einfacher wäre. Nicht umsonst sprach ich davon, daß RTG einem einige Klippen zu umschiffen gibt. Das Optimum wäre halt immer noch ein Blitter auf der GraKa, der annähernd die gleiche Funktionalität bietet wie der Blitter des Amiga-Chipsatzes. Ich fürchte nur, daß wir sowas nicht mehr erleben werden...

Zitat:
Zitat:
Original von whose:
Erwarte aber keine Wunder auf Z2-Systemen


Ich habe bei meiner ersten Version Performanceprobleme auf einer CSPPC mit 060 und CVPPC gehabt. Also mehr geht ja für AOS3.x auf Amigas schon nicht mehr!


Schon richtig. Aber bedenke auch, daß Du enorm viel maskierte Blits laufen hattest, die durch die Verwendung des "normalen Weges" schon nicht gerade rekordverdächtig schnell waren. Eher im Gegenteil.

Bei Amijeweled paßt die Geschwindigkeit noch so eben gerade mit dieser Konfiguration, selbst unter OS4 ists gerade noch schnell genug, damit keine Langeweile aufkommt. Ich bin mir aber sehr sicher, daß da noch einiges zu holen wäre, wenn man auf die maskierten Blits der graphics.library verzichtet und statt dessen bspw. RLE-codierte Grafiken verwendet.
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

17.04.2010, 00:52 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Da bringt es ihm dann nicht viel, wenn er den Flaschenhals in der Tiefensortierung seiner Grafikobjekte vermutet, obwohl er eigentlich ganz woanders steckt und sein eigener Algorithmus zur Objektsortierung möglicherweise schon effizient genug ist, oder?

Es geht ja nicht um den Algorithmus zur Sortierung (die Objekte müssen so oder so sortiert vorliegen), sondern darum, dass man mit dem richtigen Algorithmus unterm Strich möglicherweise weniger Pixel transferieren muss, wovon man gerade dann profitiert, wenn der Transfer so langsam ist.

Hm, entschuldige, ich habe verdrängt, daß Du das Projekt von Reth nicht ganz so gut kennst.

Die Grafik setzt sich eigentlich hauptsächlich aus Bitmaps zusammen, die maskiert geblittet werden müssen, weil sie eben nicht rechteckig sind und zusätzlich sehr viele Überlagerungskombinationen bestehen.

Deswegen meinte ich, daß er, wie ausgefuchst der Algorithmus für die Blit-Reihenfolge auch sein mag, kaum Geschwindigkeitsgewinn bekommen wird. Die Möglichkeiten, maskierte Blits einzusparen, sind einfach an Zahl viel zu gering.

Ich habe mir dazu schon Gedanken gemacht heute, aber ich kam nicht auf sehr viele Einsparmöglichkeiten. Das Beste, was mir einfiel, war, bei den Hex-Tiles mit rechteckigen Unterteilungen zu arbeiten.

Da die Hex-Tiles selbst unterschiedlich in der Farbgebung sind und sich teilweise überlappen (Tile-Transition), wird das Blitten dann zwar etwas leichter, dafür der Rest doch arg kompliziert. Er müßte alle möglichen Transition-Kombinationen vorhalten, die einzelnen Rechtecke, die diese Kombinationen dann darstellen, extra verwalten usw. usw.

Meiner Meinung nach ist es daher sinnvoller, mehr Denk-Aufwand in die Übertragung der Grafiken ins Bild zu investieren. Sprich, eigene "Blit"-Funktionen zu entwickeln, die die beschriebenen Schwächen der graphics.library-Funktionen eben nicht haben.

Ist auch nicht wirklich einfacher, ich weiß... ist das Beste, was mir bisher dazu einfiel.

Ich bin mir sicher, wenn jemand mit einer anderen, brauchbaren und trivialen, Idee um die Ecke kommt, wird Reth ihm nicht böse sein ;)
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

17.04.2010, 09:28 Uhr

Reth
Posts: 1858
Nutzer
@whose:

Das Einzige, was mir noch einfällt wäre "Zusammenfassen".

Z.B. den Hintergrund immer als Ganzes Bild irgendwo vorzuhalten (es ändert sich während einer Spielrunde ja nicht) und dann entweder immer einen rechteckigen Ausschnitt daraus zu blitten (ohne Maske), oder das ganze Bild (was aber wieder viel zu viel wäre).

Daher auch meine Frage, ob Layer und ClipRegions nicht eine Art Schutz bieten, so dass ich den Hintergrund nicht immer neu blitten muss, wenn sich ein darüber befindliches Objekt ändert, einfach weil beide in unterschiedlichen Layern liegen!?

Ciao

[ - Antworten - Zitieren - Direktlink - ]

17.04.2010, 14:36 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Reth:
@whose:

Das Einzige, was mir noch einfällt wäre "Zusammenfassen".

Z.B. den Hintergrund immer als Ganzes Bild irgendwo vorzuhalten (es ändert sich während einer Spielrunde ja nicht) und dann entweder immer einen rechteckigen Ausschnitt daraus zu blitten (ohne Maske), oder das ganze Bild (was aber wieder viel zu viel wäre).


Das wäre auch noch eine Option. Und dabei könnten Dir Layer behilflich sein, weil Du Dich dann nicht selbst um die Ermittlung der zerstörten Bereiche des Hintergrunds kümmern mußt. Das macht dann die layer.library für Dich.

Zitat:
Daher auch meine Frage, ob Layer und ClipRegions nicht eine Art Schutz bieten, so dass ich den Hintergrund nicht immer neu blitten muss, wenn sich ein darüber befindliches Objekt ändert, einfach weil beide in unterschiedlichen Layern liegen!?

So einfach ist die Sache leider nicht. Dein Screen ist eine große Bitmap. Eine einzige. Das bedeutet, was immer Du auch an Grafik auf diesen Screen bringst (Fenster, BOBs), es hinterläßt Spuren in der Bitmap des Screens. Sobald Du an dieser Stelle erneut etwas änderst, zum Beispiel die vorher eingebrachte Grafik wieder rausnimmst, mußt Du die Bitmap des Screens restaurieren, um das ursprüngliche Aussehen zurückzuerhalten.

Layer helfen Dir dabei, indem sie die Verwaltung der Koordinaten des von einer Zeichenoperation betroffenen Bereichs für Dich übernehmen und sogar in bestimmten Fällen die Restaurierung des betroffenen Bereiches selbständig durchführen. Sie können aber nicht verhindern, daß die Bitmap des Screens verändert wird. Oder das "darüber" liegende Objekte, die von einem weiteren verdeckt werden, nach Löschen des weiteren Objekts ebenfalls "zerstört" sind. Im Endeffekt ist ja alles nur eine einzige Bitmap, die Du auf dem Bildschirm siehst.

ClipRegions wiederum verhindern nur, das Bereiche außerhalb eines von Dir definierten Bereichs von Änderungen betroffen werden. Sie begrenzen schreibende Pixel-Operationen auf von Dir bestimmte Koordinaten. Innerhalb dieser Koordinaten wird die Screen-Bitmap durchaus verändert, so daß Du sie ebenfalls wieder restaurieren mußt.

Das ist auch der Grund, weshalb ich meinte, daß Dein Algorithmus zur Ermittlung der zerstörten Bereiche und der Blit-Reihenfolge zur Restauration u.U. schon ziemlich optimal ist. Oder zumindest geschwindigkeitsmäßig ausreichend.
--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

18.04.2010, 00:12 Uhr

Reth
Posts: 1858
Nutzer
Zitat:
Original von whose:
Layer helfen Dir dabei, indem sie ... in bestimmten Fällen die Restaurierung des betroffenen Bereiches selbständig durchführen.


Das würde schon helfen! Wie kann ich das nutzen? Zur Erhaltung des Hintergrundes würde das schon viel bringen, da dieser am häufigsten restauriert werden muss. Andere Objekte überdecken sich gegenseitig seltener!

Ciao

[ - Antworten - Zitieren - Direktlink - ]

18.04.2010, 01:59 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Reth:
Zitat:
Original von whose:
Layer helfen Dir dabei, indem sie ... in bestimmten Fällen die Restaurierung des betroffenen Bereiches selbständig durchführen.


Das würde schon helfen! Wie kann ich das nutzen? Zur Erhaltung des Hintergrundes würde das schon viel bringen, da dieser am häufigsten restauriert werden muss. Andere Objekte überdecken sich gegenseitig seltener!


Wie das genau funktioniert habe ich noch nicht erforscht... im Endeffekt ist es aber das, was bei SmartRefresh-Fenstern den Refresh besorgt (Kopieren des betroffenen Bereichs in eine temporäre Bitmap und Wiederherstellung des Hintergrunds aus dieser).

Es wird Dir nur "helfen", wenn Du (wie schon erwähnt) rechteckige Bereiche zu restaurieren hast. Allerdings glaube ich, daß Du die gleiche Funktionalität schon in Deinem Code hast, nur für nicht-rechteckige Bereiche.

Ich kann es nur nochmals betonen: Die Feststellung der Überdeckung dürfte höchstwahrscheinlich nicht das eigentliche Problem sein. Auch die Restauration (sprich: Ermittlung zerstörter Bereiche und Auslösen des Neuzeichnens) als solche kannst Du vermutlich nicht entscheidend beschleunigen, selbst das OS kocht nur mit Wasser ;)

Du mußt Dir wohl noch einige Gedanken darüber machen, wie Du möglichst viele rechteckige Blits bekommst statt der maskierten Blits.

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

18.04.2010, 10:21 Uhr

Reth
Posts: 1858
Nutzer
Zitat:
Original von whose:
Wie das genau funktioniert habe ich noch nicht erforscht... im Endeffekt ist es aber das, was bei SmartRefresh-Fenstern den Refresh besorgt (Kopieren des betroffenen Bereichs in eine temporäre Bitmap und Wiederherstellung des Hintergrunds aus dieser).

Und das wird vom System automatisch erledigt?
Zitat:
Du mußt Dir wohl noch einige Gedanken darüber machen, wie Du möglichst viele rechteckige Blits bekommst statt der maskierten Blits.
Wie gesagt wäre das beim Hintergrund kein Problem, wenn dieser erst einmal vollständig ist, da er sich nicht ändert. Daher kann ich aus diesem immer rechteckige Bereiche nehmen. Diese müsste ich aber zunächst einmal den fertigen Hinter als eigenes Bild bzw. eigene BitMap verwenden, da er ja ursprünglich aus lauter 6-Ecken erstellt wurde!

Ciao

[ - Antworten - Zitieren - Direktlink - ]

20.04.2010, 11:52 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von whose:
Die Grafik setzt sich eigentlich hauptsächlich aus Bitmaps zusammen, die maskiert geblittet werden müssen, weil sie eben nicht rechteckig sind und zusätzlich sehr viele Überlagerungskombinationen bestehen.

Das habe ich schon verstanden.
Zitat:
Deswegen meinte ich, daß er, wie ausgefuchst der Algorithmus für die Blit-Reihenfolge auch sein mag, kaum Geschwindigkeitsgewinn bekommen wird. Die Möglichkeiten, maskierte Blits einzusparen, sind einfach an Zahl viel zu gering.
Ich habe ja von Anfang an betont, dass es sehr stark davon abhängt, wieviele Objekte vorhanden sind, und wie viele davon sich verändern.

Wenn Du 100 Objekte hast und alle Objekte von hinten nach vorne neu zeichnen musst, weil sich eines bewegt hat, kann ein Algorithmus, der dafür sorgt, dass Du nur 10 Objekte aktualisieren musst, enorm viel einsparen.
Zitat:
Meiner Meinung nach ist es daher sinnvoller, mehr Denk-Aufwand in die Übertragung der Grafiken ins Bild zu investieren. Sprich, eigene "Blit"-Funktionen zu entwickeln, die die beschriebenen Schwächen der graphics.library-Funktionen eben nicht haben.
Möglicherweise bringt es ja etwas, die 3D-Funktion der Grafikkarte zu benutzen. Das hängt von der jeweiligen Grafikkarte (und natürlich den Treibern) ab.
Zitat:
Original von Reth:
Und das wird vom System automatisch erledigt?

Ja.
Zitat:
Wie gesagt wäre das beim Hintergrund kein Problem, wenn dieser erst einmal vollständig ist, da er sich nicht ändert. Daher kann ich aus diesem immer rechteckige Bereiche nehmen. Diese müsste ich aber zunächst einmal den fertigen Hinter als eigenes Bild bzw. eigene BitMap verwenden, da er ja ursprünglich aus lauter 6-Ecken erstellt wurde!
Wenn Du den Hintergrund in einer eigenen BitMap vorhältst, wäre es Ressourcenverschwendung, beim Hintergrund-Layer auch noch Smart-Refresh einzustellen.

Die manuelle Variante ist aber auch nicht so schwer zu programmieren. Der Hintergrund-Layer muss nur dann aktualisiert werden, wenn sich ein darüber liegender Layer bewegt oder geschlossen wird. Wann immer Du eine solche Aktion durchführst, musst Du also danach das Dirty-Flag des Layers überprüfen. Wenn es gesetzt ist, dann rufst Du BeginRefresh auf, das bewirkt, dass die betroffenen Regionen in umgekehrte Clipping-Bereiche umgewandelt werden, auf deutsch, ab diesem Moment zeichnest Du nur in Bereiche, die die layers.library als beschädigt markiert hat. Dann musst Du nur einen Blit des gesamten Hintergrund-Bilders in diesen Layer durchführen und das System begrenzt diesen automatisch auf den neu zu zeichnenden Bereich. Danach rufst Du EndRefresh auf, um den Normalzustand wiederherzustellen.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


1 -2- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Hintergrundbild für eigenen Screen laden [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.