Zitat:

---

Original von Holger:
Bleibt nur SimpleRefresh + eigene BitMap.

---

Zitat:

---

Original von Holger:
Klingt für mich nach einem Fehler. Welche OS-Version?

---

Zitat:

---

Original von Holger:
Da musst Du es aber von Hand programmieren. Der in dem Beispiel gezeigte Fall, dass man die SuperBitMap von Hand anlegt, sollte der Sonderfall sein. Was Dir SuperBitMap-Fenster außerdem abnehmen, ist das Nachdenken über systemseitigen Damage, da die entsprechenden Regionen automatisch wiederhergestellt werden. Was ich nicht genau weiß, ist, wie das System die programmseitigen Updates handhabt.

---

Zitat:

---

Original von Holger:
SuperBitMap Fenster sind keine Screens. Dein Scrollen einer SuperBitMap ist nichts anderes, als ein Blit von der SuperBitMap in die Screen-BitMap.

---

Zitat:

---

Original von Holger:
Wenn Du Fenster verwendest, kannst Du keine Pointer-Updates oder ähnlich gelagerte Buffer-Techniken einsetzen.

---

Zitat:

---

Original von Holger:
Aber unter Verwendung der ClipRects? Theoretisch sollte die Größe der sowieso nicht geblitteten Bereiche überhaupt keine Rolle spielen.

---

Zitat:

---

Na ja, nach meinem Verständnis wäre das gar nicht nötig, wenn man zuerst alles in die Offscreen-BitMap rendert und diese dann in das Fenster blittet. Übergroße BitMaps brächte man dazu gar nicht.

---

Zitat:

---

Original von Holger:
Ich dachte, das wäre sowieso der Fall?

---

Jetzt schon. Hatte zuerst die grobe Kelle geschwungen und immer den ganzen Spielbereich gelöscht.

Zitat:

---

Original von Holger:
Auch das habe ich bereits geschrieben. Im selben Beitrag.

---

Zitat:

---

Original von Holger:
Wie bereits gesagt, alles neu zeichnen plus double-buffering, ohne mit dem System zu interagieren, ist der am häufigsten anzutreffende Algorithmus.

---

Zitat:

---

Original von Holger:
Das ist die Holzhammer-Methode. Dafür gibt es zwei bessere Alternativen. Die systemfreundlichste wäre es, die extra dafür vorgesehenen Funktion der intuition.library namens AllocScreenBuffer, ChangeScreenBuffer und FreeScreenBuffer zu benutzen. Da diese in der Anfangszeit von RTG Probleme auf RTG-Systemen bereiteten, hat es sich zu dieser Zeit eingebürgert, stattdessen einen doppelt hohen Screen zu verwenden und diesen über Änderungen des Offsets in ViewPort->RasInfo gefolgt von ScrollVPort zwischen der oberen und unteren Hälfte umzuschalten. Letzteres ist auch die Methode, die auf Systemen vor AOS3.0 funktioniert.

---

Zitat:

---

Original von Holger:
Erst einmal eine Verständnisfrage: der graue Hintergrund flimmert nur innerhalb des durch die ClipRects festgelegten Bereiches, oder?

---

Zitat:

---

Original von Holger:
Wenn Du obige Frage mit ja beantwortet hast, kannst Du versuchen, die die Zeit zwischen den Zeichenvorgängen zu verringern, d.h. den gesamten Prozess zu beschleunigen, oder Du brauchst eine Offscreen-BitMap. Natürlich kann man auch das EraseRect so begrenzen, dass Bereiche, die definitiv immer vom Spielfeld verdeckt sind, nicht extra gelöscht werden. Das reduziert mögliches Flimmern, löst das Problem aber nicht grundsätzlich.

---

Zitat:

---

Original von Thore:
Weil bei BeginUpdate die zerstörten Regions berücksichtigt werden. Wenn Du eigene zur Damage Liste hinzugefügt hast, dann werden diese auch verwendet. Beim EndUpdate wird die Damage Liste zurückgesetzt und das Layer freigegeben.
(Anm: BeginUpdate und EndUpdate sind Bestandteil der Layers-Lib und werden automatisch mit BeginRefresh und EndRefresh aufgerufen)

---

Zitat:

---

Original von Thore:
Warum das System einfriert weiß ich nicht, gibts dazu nen Sourcecode?

---

Zitat:

---

Original von Holger:

Zitat:

---

Und wie gerade gefragt, wieso funktionierts, wenn ich die DamageList dazuODERe, nicht aber, wenn ich die ClipRegion des Layers dazuODERe?
In beiden Fällen wird doch bei BeginRefresh mit ner leeren System-ClipRegion verUNDet, denn es ist ja kein Schaden im Layer vorhanden! (Trotzdem tut es mit der DamageList!)

---

In meinem Code wird aber erst nach EndRefresh() gezeichnet, deshalb findet die VerUNDung nicht statt.

---

Zitat:

---

Original von AmigaHarry:
Ja, Probier mal einen RGB-Mode. Wenn gar nichts hilft sende mit deine Mail per PN.....

---

Zitat:

---

Original von Holger:
Einiges geht unter, wenn so viel auf einmal kommt. In diesen Punkten dachte ich eher, dass Du es schon verstanden hättest.

---

Zitat:

---

Original von Holger:
Wenn Du BeginRefresh aufrufst, obwohl Du gar keine Refresh-Message bekommen hast, dann gibt es nichts, was neu zu zeichnen wäre, und damit wird auch nichts gezeichnet. Egal, wie Du Deine ClipRegion konstruierst, wird sie zwischen Begin- und EndRefresh mit dem Damage-basierten Clip AND-verknüpft und x AND 0 ist immer 0.

---

Zitat:

---

Original von Holger:
Denn die Erkenntnis des Tages ist, dass zwischen Begin- und EndRefresh immer eine AND-Verknüpfung zwischen dem System-Clip und dem User-Clip stattfindet, woraus sich schließen lässt, dass der System-Clip gar nicht in Layer->ClipRegion gespeichert wird.

---

Zitat:

---

Original von Holger:
Wenn Du BeginRefresh aufrufst, obwohl Du gar keine Refresh-Message bekommen hast, dann gibt es nichts, was neu zu zeichnen wäre, und damit wird auch nichts gezeichnet. Egal, wie Du Deine ClipRegion konstruierst, wird sie zwischen Begin- und EndRefresh mit dem Damage-basierten Clip AND-verknüpft und x AND 0 ist immer 0.

Ohne Begin-/EndRefresh und ohne anderes zutun Deinerseits ist die Grundeinstellung kein Clipping. Wenn Du damit eine OR-Verknüpfung durchführst, ist das Ergebnis logischerweise wieder kein Clipping. Deshalb wird dann alles gezeichnet.

Und jetzt kommt der Clou: keine der beiden Methoden kann man auf das gewünschte Ergebnis biegen. Denn die Erkenntnis des Tages ist, dass zwischen Begin- und EndRefresh immer eine AND-Verknüpfung zwischen dem System-Clip und dem User-Clip stattfindet, woraus sich schließen lässt, dass der System-Clip gar nicht in Layer->ClipRegion gespeichert wird.

Das erklärt dann auch, warum es egal ist, ob man diese Region vor oder nach BeginRefresh setzt, sie wird davon gar nicht beeinflusst.

Die Lösung wäre dann die am Anfang der Diskussion genannte Alternative, nämlich mit der Damage-Liste zu hantieren.

---

Zitat:

---

Original von Holger:
Denn die Erkenntnis des Tages ist, dass zwischen Begin- und EndRefresh immer eine AND-Verknüpfung zwischen dem System-Clip und dem User-Clip stattfindet, woraus sich schließen lässt, dass der System-Clip gar nicht in Layer->ClipRegion gespeichert wird.

---