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!

---

[ - Antworten - Zitieren - Direktlink - ]

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ß).

---

Zitat:

---

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

---

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.

---

Zitat:

---

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

---

[ - Antworten - Zitieren - Direktlink - ]

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
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

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?

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

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!

@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 - ]

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?

---

Zitat:

---

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

---

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.

---

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.
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

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
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

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).

---

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.
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

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

---

[ - Antworten - Zitieren - Direktlink - ]

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.

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

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).

---

Zitat:

---

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

---

[ - Antworten - Zitieren - Direktlink - ]

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.

---

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.

---

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.

---

Zitat:

---

Original von Reth:
Und das wird vom System automatisch erledigt?

---

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!

---

[ - Antworten - Zitieren - Direktlink - ]