amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Neue Frage zu Überdeckungen [ - Search - New posts - Register - Login - ]

1 -2- 3 4 5 6 [ - Post reply - ]

2011-02-15, 20:05 h

Reth
Posts: 1858
User
@Holger:
Danke für Deine Hilfen!

Zitat:
Original von Holger:
Nein, es liegt daran, dass Intuition nicht weiß, dass der Hintergrund neu gemalt werden muss. Dazu muss dieser Bereich erstens in der Damage-Liste enthalten sein und zweitens ist ein Refresh-Trigger nötig, anders gesagt, Intuition braucht einen Grund, um anzunehmen, dass ein Refresh nötig ist. Denn leider gibt es dafür keine passende Funktion.

Und der Refresh-Trigger wäre dann das EraseRect?

Zitat:
Original von Holger:
Vergiss das ganze. Stell Dir einfach mal vor, es gibt, ganz abstrakt gesprochen, irgendeine Art von Hintergrund. Dafür gibt es eigentlich nur zwei Möglichkeiten, a) Farbe 0 oder b) das, was ein evtl. installierter Backfill-Hook tut.

Egal, auf welche Weise der Hintergrund definiert ist, wird ein Aufruf von EraseRect diesen wiederherstellen. Wenn Du dies innerhalb von BeginRefresh und EndRefresh tust, wird diese Operation auf die Bereiche, die einen Refresh benötigen, beschränkt.

Wenn ich es richtig verstanden habe muss ich dann zwischen BeginRefresh und Endrefresh auch das Rechteck mit in die DamageList aufnehmen, das der alten Cursor-Position entspricht. Wer ermittelt denn die Bereiche, die einen Refresh benötigen? Intuition oder ich oder beides (also ich füge meine Rechtecke mit OrRectRegion der bereits ermittelten ClippingRegion des Fensters hinzu)?
Und werden dann eigentlich die ganzen BlitOperationen zwischen meinem Aufruf von BeginRefresh und EndRefresh direkt ausgeführt, oder erst anschließend alle auf einmal?

Zitat:
Original von Holger:
Wenn Du sowieso dafür sorgst, dass Deine Animationen und veränderlichen Objekte auf das Spielfeld beschränkt sind, ist die ganze Sache ziemlich einfach. Da Du keine Fensterrahmen oder Gadgets refreshen musst, funktioniert das ganze ohne zusätzliche Verrenkungen.
Einfach EraseRect für das ganze Spielfeld aufrufen und danach das Spielfeld zeichnen.

Das ist doch aber ziemlich inperformant, wenn ich alle Hex-Tiles und auch alle "darüber liegenden" Objekte neu blitte. Bisher läuft das Ganze bei mir so ab:
  • Im Rahmen der IntuiTicks (oder später bei MouseMove) werden alle Objekte geprüft, ob sie sich verändert haben
  • Für jedes veränderte Objekt wird ein Refresh der Grafik gemacht (<= das muss noch optimiert werden):

    • Das Rechteck, in dem das Objekt liegt wird als Clipping-Region im Layer des Fenster-Rastports gesetzt
    • Es wird geprüft, welche Objekte über oder unter dem sich ändernden Objekt liegen, diese werden alle entsprechend ihrer "Tiefe" "von unten nach oben sortiert" in eine Liste gelegt
    • Die Objekte in der Liste werden der Reihenfolge nach durch ihre Masken geblittet
    • Die ClippingRegion wird wieder deinstalliert.
BeginRefresh und EndRefresh oder EraseRect nutze ich bisher gar nicht.

Zitat:
Original von Holger:
Zitat:
Habe mir auch schon überlegt, das Spielfeld und die Status-/Bedienleiste in je ein eigenes Fenster zu stecken. Oder würden hier getrennte Layer reichen?
Brauchst Du nicht.
Wäre das aber nicht was für nen scrollbaren Statusbereich o.ä.?

[ - Answer - Quote - Direct link - ]

2011-02-16, 12:33 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Und der Refresh-Trigger wäre dann das EraseRect?

Nein. EraseRect macht, was der Name sagt, es löscht einen rechteckigen Bereich. Wobei die Definition von Löschen davon abhängt, wie der Hintergrund definiert ist. Standard ist Füllen mit der Hintergrundfarbe.
Zitat:
Wenn ich es richtig verstanden habe muss ich dann zwischen BeginRefresh und Endrefresh auch das Rechteck mit in die DamageList aufnehmen, das der alten Cursor-Position entspricht.
Um Himmels Willen, nein. Alle Bereiche müssen vor dem Aufruf von BeginRefresh in die DamageListe eingetragen werden. Der Aufruf von BeginRefresh macht aus die aktuellen DamageListe einen aktuellen Clipping-Bereich.
Zitat:
Wer ermittelt denn die Bereiche, die einen Refresh benötigen? Intuition oder ich oder beides (also ich füge meine Rechtecke mit OrRectRegion der bereits ermittelten ClippingRegion des Fensters hinzu)?
Nicht der ClippingRegion, sondern der DamageListe. Das System ermittelt betroffene Bereiche, die durch Layer-Operationen oder durch Scrolling-Operationen beschädigt wurden. Wenn die Layer-Operationen durch Fenster-Operationen verursacht wurden, dann schickt Intuition den zu den Layern gehörenden Fenstern eine Refresh-Message.
Zitat:
Und werden dann eigentlich die ganzen BlitOperationen zwischen meinem Aufruf von BeginRefresh und EndRefresh direkt ausgeführt, oder erst anschließend alle auf einmal?
Während. Oder gar nicht. Je nach aktuellem Clipping.
Zitat:
Das ist doch aber ziemlich inperformant, wenn ich alle Hex-Tiles und auch alle "darüber liegenden" Objekte neu blitte.
Nein, alles, was außerhalb der Clip-Bereiche liegt, hat keinen Effekt.
Das ist ja der Sinn der Sache.

Zitat:
Wäre das aber nicht was für nen scrollbaren Statusbereich o.ä.?
Braucht genausowenig ein eigenes Fenster.

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

[ - Answer - Quote - Direct link - ]

2011-02-16, 23:22 h

Reth
Posts: 1858
User
Zitat:
Original von Holger:
Um Himmels Willen, nein. Alle Bereiche müssen vor dem Aufruf von BeginRefresh in die DamageListe eingetragen werden. Der Aufruf von BeginRefresh macht aus die aktuellen DamageListe einen aktuellen Clipping-Bereich.
...
Nicht der ClippingRegion, sondern der DamageListe. Das System ermittelt betroffene Bereiche, die durch Layer-Operationen oder durch Scrolling-Operationen beschädigt wurden.

Hm. Ich dachte, ich füge die Bereiche, die ich neu blitten möchte der umgewandelten DamageListe hinzu (also dem Clipping-Bereich). Wie komme ich denn an die DamageListe vor BeginRefresh? Und wie füge ich meine Bereiche dann hinzu? Habe beim Stöbern in den Funktionen nichts Entsprechendes gefunden!
Ist dann mein bisheriges Vorgehen mit Installation/Deinstallation von ClippingRegions im Layer des Window-Rastports ohne Begin-/EndRefresh überhaupt systemkonform?

Zitat:
Original von Holger:
Wenn die Layer-Operationen durch Fenster-Operationen verursacht wurden, dann schickt Intuition den zu den Layern gehörenden Fenstern eine Refresh-Message.

Kann ich denn die Aktualisierung mit BeginRefresh/EndRefresh auch bei Events wie MOUSEMOVE anwenden?

Zitat:
Original von Holger:
Zitat:
Original von Reth:
Das ist doch aber ziemlich inperformant, wenn ich alle Hex-Tiles und auch alle "darüber liegenden" Objekte neu blitte.

Nein, alles, was außerhalb der Clip-Bereiche liegt, hat keinen Effekt.
Dann kann ich mir ja die ganze Überdeckungsprüfung sparen!

Zitat:
Original von Holger:
Zitat:
Original von Reth:
Wäre das aber nicht was für nen scrollbaren Statusbereich o.ä.?

Braucht genausowenig ein eigenes Fenster.
Aber den eigenen Layer kann ich doch nutzen, damit ich schon mal das Scrolling usw. habe, oder?

[ - Answer - Quote - Direct link - ]

2011-02-17, 14:09 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Hm. Ich dachte, ich füge die Bereiche, die ich neu blitten möchte der umgewandelten DamageListe hinzu (also dem Clipping-Bereich). Wie komme ich denn an die DamageListe vor BeginRefresh? Und wie füge ich meine Bereiche dann hinzu? Habe beim Stöbern in den Funktionen nichts Entsprechendes gefunden!

DamageList ist ein Eintrag in der Layer-Struktur, genauso wie ClipRegion, der einzige Unterschied ist der, dass Du natürlich den Layer locken musst, bevor Du etwas veränderst.

Allerdings erscheint es mir für Deinen Fall doch einfacher, die Bereiche der normalen Clip-Liste während des Refreshs hinzuzufügen, Du musst nur daran denken, den exakten Originalzustand vor EndRefresh wiederherzustellen.
Zitat:
Ist dann mein bisheriges Vorgehen mit Installation/Deinstallation von ClippingRegions im Layer des Window-Rastports ohne Begin-/EndRefresh überhaupt systemkonform?
Systemkonform ist es schon. Allerdings fehlt Dir der Refresh des Spielfeldes, wenn andere Fenster über Deinem Spielfeld bewegt oder geschlossen werden. Auf einem Custom-Screen ohne weitere Fenster kein Problem, allerdings ist selbst da mal schnell ein System-Requester geöffnet, wenn man nicht drüber nachdenkt.

Und da hakt's dann auch mit dem INTUITICKS-basiertem Refresh, der an sich mit dem NoCareRefresh harmoniert. Aber wenn ein neues Fenster geöffnet und aktiviert wird, bekommt Dein Fenster als inaktives keine Ticks mehr und da es auch keine Refresh-Meldungen erhält, wird Dein Spielfeld nicht aktualisiert, wenn das darüberliegende Fenster bewegt wird.
Zitat:
Kann ich denn die Aktualisierung mit BeginRefresh/EndRefresh auch bei Events wie MOUSEMOVE anwenden?
Klar, dann kann es allerdings passieren, dass Du später eine RefreshMessage bekommst, obwohl inzwischen alles wiederhergestellt wurde.

Zitat:
Zitat:
Original von Holger:
Nein, alles, was außerhalb der Clip-Bereiche liegt, hat keinen Effekt.

Dann kann ich mir ja die ganze Überdeckungsprüfung sparen!
Ja, genau das ist der Zweck des Clippings: Aktualisierungsroutinen zu vereinfachen, in dem man sie einfach komplett durchläuft, aber nur das tatsächlich zeichnet, was aktualisiert werden muss.

Nur wenn der Zeichenalgorithmus selbst im Verhältnis zu den Zeichenprimitven (sprich dem Blitting) viel Performance benötigt, lohnt es sich, diesen so anzupassen, dass er kleinere Teilbereiche effizienter abhandeln kann.

Zitat:
Aber den eigenen Layer kann ich doch nutzen, damit ich schon mal das Scrolling usw. habe, oder?
Wofür brauchst Du beim Scrolling einen eigenen Layer?

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

[ - Answer - Quote - Direct link - ]

2011-02-19, 09:26 h

Reth
Posts: 1858
User
Zitat:
Original von Holger:
DamageList ist ein Eintrag in der Layer-Struktur, genauso wie ClipRegion, der einzige Unterschied ist der, dass Du natürlich den Layer locken musst, bevor Du etwas veränderst.

Ah, ok. Danke. Sowas in der Art hatte ich mir schon gedacht, es aber in den Beschreibungen noch nicht gefunden!

Zitat:
Original von Holger:
Allerdings erscheint es mir für Deinen Fall doch einfacher, die Bereiche der normalen Clip-Liste während des Refreshs hinzuzufügen, Du musst nur daran denken, den exakten Originalzustand vor EndRefresh wiederherzustellen.

Das wäre ja dann ca. das Gleiche, wie das, was ich bisher mache mit dem Unterschied, dass ich ein SMARTREFRESH-Window anlege, keine Überdeckungsermittlung mehr mache, sondern nur die sich ändernden Teile ermittle, damit die ClippingRegion setzr und alles zw. BeginRefresh und EndRefresh aktualisiere. Dabei binde ich auch das umgebende Rechteck des animierten Cursors an der alten Position vor seiner Bewegung mit ein (oder mache 2 Refreshs, einen vorher, einen nachher ist aber unperformanter).

Allerdings hab ich dazu noch folgende Fragen:
Wie ist es denn, wenn sich an vielen, weit auseinander liegenden Bereichen des Spielfeldes Dinge ändern? Dann ermittle ich doch mit OrRectRegion im Endeffekt eine riesengroße ClippingRegion, in der auch Dinge geblittet werden, die sich gar nicht geändert haben, oder?
Wenn ich Ist denn dann OrRectRegion überhaupt das Richtige, oder brauche ich eine andere Rect-/Region-Funktion?
Nach meinem Verständnis müsste OrRectRegion aber eigentlich das Richtige machen und wenn ich
C code:
struct RegionRectangle

richtig verstanden habe, dann liegen darin alle Rechtecke für die ClippingRegion. Aber wer sagt mir, dass Intuition daraus nicht ein umgebendes, großes Rechteck macht?
Und muss ich für die ermittelte ClippingRegion erst ein EraseRect machen?

Zitat:
Original von Holger:
Und da hakt's dann auch mit dem INTUITICKS-basiertem Refresh, der an sich mit dem NoCareRefresh harmoniert. Aber wenn ein neues Fenster geöffnet und aktiviert wird, bekommt Dein Fenster als inaktives keine Ticks mehr und da es auch keine Refresh-Meldungen erhält, wird Dein Spielfeld nicht aktualisiert, wenn das darüberliegende Fenster bewegt wird.
Zitat:
Original von Reth:
Kann ich denn die Aktualisierung mit BeginRefresh/EndRefresh auch bei Events wie MOUSEMOVE anwenden?

Klar, dann kann es allerdings passieren, dass Du später eine RefreshMessage bekommst, obwohl inzwischen alles wiederhergestellt wurde.
Du meinst, weil ich bei MouseMove schon aktualisiert habe, Intuition das nicht merkt und mir ne Refresh-Message schickt?
Hatte eigentlich geplant, alles zu kombinieren: INTUITICKS, MOUSEMOVE und Refresh-Messages. Dabei könnte ich dann die Refresh-Messages ja als erstes verarbeiten und mir merken, ob der Refresh schon gelaufen ist!?

Zitat:
Original von Holger:
Zitat:
Reth:
Aber den eigenen Layer kann ich doch nutzen, damit ich schon mal das Scrolling usw. habe, oder?

Wofür brauchst Du beim Scrolling einen eigenen Layer?
Na der bietet das doch schon. Dachte da in der Art von den Statusleisten bei anderen RTSs, die sich von der Seite her einblenden (z.B. über HotKey o.ä.). Und der Layer würde dann das "Rein- und Rausscrollen" übernehmen können.

[ - Answer - Quote - Direct link - ]

2011-02-21, 12:16 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Das wäre ja dann ca. das Gleiche, wie das, was ich bisher mache mit dem Unterschied, dass ich ein SMARTREFRESH-Window anlege, keine Überdeckungsermittlung mehr mache, sondern nur die sich ändernden Teile ermittle, damit die ClippingRegion setzr und alles zw. BeginRefresh und EndRefresh aktualisiere.

Und EraseRect aufrufst.
Zitat:
Allerdings hab ich dazu noch folgende Fragen:
Wie ist es denn, wenn sich an vielen, weit auseinander liegenden Bereichen des Spielfeldes Dinge ändern? ...
Nach meinem Verständnis müsste OrRectRegion aber eigentlich das Richtige machen ... Aber wer sagt mir, dass Intuition daraus nicht ein umgebendes, großes Rechteck macht?

Einigen wir uns doch darauf, dass die graphics.library höchstwahrscheinlich nur dann Rechtecke zusammenfasst, wenn die Verwaltung der Fläche als einzelne kleine Rechtecke in keinem sinnvollen Verhältnis zum Gewinn durch nicht enthalten Teilflächen mehr steht.
Falls so etwas überhaupt passiert.
Jedenfalls würde das System niemals disjunkte Rechtecke zu einem großen zusammenfassen.

Für Dich gilt doch erst mal, dass Du den einfachen Zeichenalgorithmus implementieren solltest, bevor Du Dir darüber Gedanken machst, ob die resultierende Performance das Ersetzen der Systemalgorithmen durch eigene (kannst Du es denn überhaupt besser?) erforderlich macht.
Zitat:
Und muss ich für die ermittelte ClippingRegion erst ein EraseRect machen?
Nein, EraseRect rufst Du für das gesamte Spielfeld einmal auf, bevor Du es zeichnest. Wie alle Zeichenbefehle zwischen BeginRefresh und EndRefresh.
Zitat:
Du meinst, weil ich bei MouseMove schon aktualisiert habe, Intuition das nicht merkt und mir ne Refresh-Message schickt?
Hatte eigentlich geplant, alles zu kombinieren: INTUITICKS, MOUSEMOVE und Refresh-Messages. Dabei könnte ich dann die Refresh-Messages ja als erstes verarbeiten und mir merken, ob der Refresh schon gelaufen ist!?

Ich glaube, da hast Du einen Denkfehler. Egal, in welcher Reihenfolge die Verarbeitung im Code steht, wirst Du die Events in der Reihenfolge verarbeiten, wie Du sie empfängst.

Das ist aber überhaupt kein Problem. Jeder Layer hat ein Flag, das besagt, ob Damage vorhanden ist und das bei EndRefresh(...,TRUE) zurückgesetzt wird. Wenn Du eine Refresh-Message bekommst, das Flag aber nicht gesetzt ist, dann weißt Du, dass Du zwischen der Ursache und dem Empfang schon einen Maus oder Timer getriggerten Refresh durchgeführt hast und die Message ignorieren kannst.

Zitat:
Na der bietet das doch schon. Dachte da in der Art von den Statusleisten bei anderen RTSs, die sich von der Seite her einblenden (z.B. über HotKey o.ä.). Und der Layer würde dann das "Rein- und Rausscrollen" übernehmen können.
Wenn Du mit Intuition-Fenstern hantierst, darfst Du nicht gleichzeitig mit Layern (direkt) hantieren, sondern musst dafür auch Fenster nehmen. Dann aber schießt Du mit Kanonen auf Spatzen. Du bewegst den Layer und musst dann auf die Refresh-Message des Systems warten, um betroffene Regionen wiederherzustellen.

Mit ScrollRasterBF kannst Du denselben Effekt innerhalb Deines primären Layers (Fensters) erreichen und sofort im Anschluss den nötigen Refresh ohne Zeitverzögerung durchführen.

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

[ - Answer - Quote - Direct link - ]

2011-02-27, 20:28 h

Reth
Posts: 1858
User
Zitat:
Einigen wir uns doch darauf, dass die graphics.library höchstwahrscheinlich nur dann Rechtecke zusammenfasst, wenn die Verwaltung der Fläche als einzelne kleine Rechtecke in keinem sinnvollen Verhältnis zum Gewinn durch nicht enthalten Teilflächen mehr steht.
Falls so etwas überhaupt passiert.
Jedenfalls würde das System niemals disjunkte Rechtecke zu einem großen zusammenfassen.

Für Dich gilt doch erst mal, dass Du den einfachen Zeichenalgorithmus implementieren solltest, bevor Du Dir darüber Gedanken machst, ob die resultierende Performance das Ersetzen der Systemalgorithmen durch eigene (kannst Du es denn überhaupt besser?) erforderlich macht.

Ja, einigen wir uns darauf und Nein, ich kann es wahrscheinlich nicht besser.
Idee hinter diesem Vorgehen ist, die benötigten Systemaufrufe zu minimieren. Sprich: Warum eine Blitoperation für ein Objekt rufen, das sich nicht geändert hat, auch wenn das System dann feststellt, dass die ClippingRegion nicht betroffen ist.

Zitat:
Mit ScrollRasterBF kannst Du denselben Effekt innerhalb Deines primären Layers (Fensters) erreichen und sofort im Anschluss den nötigen Refresh ohne Zeitverzögerung durchführen.
Aah, danke! Werd ich mir mal ansehen.

[ - Answer - Quote - Direct link - ]

2011-03-01, 19:15 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Idee hinter diesem Vorgehen ist, die benötigten Systemaufrufe zu minimieren. Sprich: Warum eine Blitoperation für ein Objekt rufen, das sich nicht geändert hat, auch wenn das System dann feststellt, dass die ClippingRegion nicht betroffen ist.

Wir reden aber immer noch vom AmigaOS, oder? ;)
Der Overhead eines Systemaufrufs spielt beim AmigaOS im Vergleich zur Blitoperation selber überhaupt keine Rolle.
Außerdem fängst Du die Sache schon wieder falsch an. Implementiere einen straight-forward Algorithmus und schau dann, ob es Performanceprobleme gibt oder nicht.

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

[ - Answer - Quote - Direct link - ]

2011-03-21, 23:55 h

Reth
Posts: 1858
User
@Holger:

Für das Straight-Forward-Verhalten hätt ich dann noch ne Frage:

Welches Vorgehen ist denn besser:

1. Begin Refresh - Ermitteln aller geänderter Spielobjekte inkl. der alten Cursorposition - OrRectRegion für diese Objekte in neuer, eigener ClipRegion - InstallClipRegion mit der Ergebnisregion - EraseRect fürs Spielfeld - Blitten der Objekte - Reinstall OriginalClipRegion - EndRefresh

oder wie hier im Bsp. dargestellt:

2. Begin Refresh - Ermitteln der alten Cursorposition - InstallClipRegion für dieses Objekt - EraseRect fürs Spielfeld - Reinstall OriginalClipRegion - Ermitteln 1. geändertes Spielobjekt - InstallClipRegion für dieses Objekt - EraseRect fürs Spielfeld - Blitten des Objektes - Reinstall OriginalClipRegion - Ermitteln 2. geändertes Spielobjekt - InstallClipRegion für dieses Objekt - EraseRect fürs Spielfeld - Blitten des Objektes - Reinstall OriginalClipRegion - ... - Ermitteln letztes geändertes Spielobjekt - InstallClipRegion für dieses Objekt - EraseRect fürs Spielfeld - Blitten des Objektes - Reinstall OriginalClipRegion - EndRefresh

In beiden Fällen sollte mir Intuition für die alte Cursorposition außerhalb des Spielfelds den grauen Hintergrund wiederherstellen (wenn man mal den Statusbereich rechts auslässt)! Ist dem so, oder muss ich hier noch was machen?

Im 2. Fall reicht EraseRect auch für das aktuell bearbeitete Objekt.

Rein intuitiv würde ich eher zu Methode 1 neigen.

[ - Answer - Quote - Direct link - ]

2011-03-22, 15:03 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
In beiden Fällen sollte mir Intuition für die alte Cursorposition außerhalb des Spielfelds den grauen Hintergrund wiederherstellen (wenn man mal den Statusbereich rechts auslässt)! Ist dem so, oder muss ich hier noch was machen?

Dem ist so.
Zitat:
Rein intuitiv würde ich eher zu Methode 1 neigen.
Ich auch. Schließlich ermöglicht die OR-Operation, dass Flächen bei überlappenden Objekten zusammengefasst und ein einem Rutsch aktualisiert werden. Je mehr veränderliche Objekte ins Spiel kommen, desto drastischer dürfte der Unterschied ausfallen.

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

[ - Answer - Quote - Direct link - ]

2011-03-25, 14:41 h

Reth
Posts: 1858
User
@Holger:

Danke nochmal für Deine Hilfe. Jetzt steht mir "nur" noch mein Design im Weg (s. a. meine anderen Threads dazu). Derzeit hab ich das Message-Handling komplett in meiner Window-Klasse und die "Abnehmer" (also die, welche über aufgetretene Ereignisse informiert werden möchten) werden alle über eine parameterlose Methode angetriggert. Für den Refresh muss ich aber das Fenster (oder zumindest dessen Rastport) an die Klasse übergeben, die den Refresh durchführt (bisher hab ich nen Zeiger auf den RastPort in jedem darzustellenden Objekt liegen, da gehört er aber nicht hin)! Muss ich mal knobeln, wie ich das nun am besten designe bei meiner bestehenden Klassenkonstellation - hab zwar schon ein paar Ansätze, aber noch nichts konkretes!

Da ich das Ganze auch in C++ mache, um in die Sprache reinzukommen, hab ich damit gerade z.T. doppelt Probleme.

Z.B. versuche ich soviel Konstantes wie möglich zu machen (hatte ich als Empfehlung zu C++ so verstanden). Aber an den Schnittstellen zwischen den Systemfunktionen und -komponenten und meinen Klassen hab ich so meine Probleme, wie bei der Übergabe von BitMaps, die Grafiken enthalten. Diese sind in Frame-Klassen gekapselt. Wenn ich allerdings ein Frameobjekt blitten möchte, muss ich dessen BitMap nach außen geben, um sie z.B. in BltBitMapRastPort. Da die Funktion aber eine nicht-konstante BitMap erwartet kann ich diese in der Frame-Klasse nicht als const bzw. als const-pointer auf const zurückgeben.

Zudem bin ich mir immer noch unschlüssig, wie ich die animierten Grafikklassen designe. Derzeit bekommt jedes Objekt den RastPort im Konstruktor mit, auf dem es sich darstellen/entfernen können soll (wobei dann die Blitoperation meiner RastPort-Klasse dafür gerufen und dabei der aktuelle Frame übergeben wird). Allerdings finde ich das nicht mehr so sinnvoll, da sich die Objekte theoretisch ja in unterschiedlichen RastPorts gleichzeitig anzeigen lassen könnten (auch wenn es evtl. an praktischen Hintergründen fehlt)!

Insgesamt bin ich mir auch nicht ganz klar darüber, wo ich z.B. die Blit-Funktionen kapsele. Da ich derzeit nur eine benötige (BltBitMapRastPort), ist sie in meiner "RastPort-Klasse" enthalten. Dann gibt es ja aber noch die Blit-Operationen mit/auf BitMaps und die ganzen Draw-Funktionen. Hätte die alle gern zusammen in einer Klasse, aber die Basis des Ganzen ist doch sehr heterogen!
Oder ist BltBitMapRastPort "nur ne Convenience-Funktion", da dann BltBitMap auf der BitMap im RastPort ausführt?

Eine ca. 1:1-Abbildung von AOS-Libs oder ähnlichem hab ich mir nicht vorgenommen!

Aber das sind alles schon wieder Themen für einige neue Threads!

[ Dieser Beitrag wurde von Reth am 01.04.2011 um 10:10 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]

2011-04-04, 11:39 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Aber das sind alles schon wieder Themen für einige neue Threads!

Ja, pack das mal lieber in eigene Threads. Bekommt man sonst nicht so richtig mit, wenn Du Änderungen in einem älteren Beitrag machst. Vor allem, da das Forum keine Funktion hat, um sich die Änderungen anzeigen zu lassen...

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

[ - Answer - Quote - Direct link - ]

2011-04-10, 14:29 h

Reth
Posts: 1858
User
@Holger:

Jetzt noch ne Frage:

Woher bekomme ich denn bei einer nicht von mir verursachten Refresh-Message mit, welche Bereiche denn betroffen sind, so dass ich sie zur Clipping Region hinzufügen kann?

Nach meinem Verständnis von
C code:
InstallClipRegion()

wären diese Bereiche in der ClipRegion, die von dieser Funktion zurückgegeben wird, oder?

D.h., ich würde:
  • BeginRefresh rufen
  • InstallClipRegion rufen
  • mir die zurückgegebene Region merken
  • meine zu aktualisierenden Bereiche zu dieser alten Region hinzu-ODERn
  • wieder InstallClipRegion mit dieser neu ermittelten Region rufen
  • alles blitten
  • die alte gemerkte Region wieder installieren
  • EndRefresh rufen
Kommt das ungefähr so hin? Oder läuft das Ganze anders? Die bisher hier im Thread beschriebenen Abläufe habe ich nur auf die Situationen bezogen, bei denen ich selbst einen Refresh ausführen möchte, z.B. nach Änderungen, die sich auch auf die Grafik auswirken, so dass Teile neu geblittet werden müssen, dann brauch ich ja auch "nur" meine Bereiche beim Erstellen der Clipping-Region berücksichtigen. Wobei der allgemeine Ablauf (also so, als ob auch schon Bereich betroffen sind, bei denen ich nicht Refresh-Verursacher bin) wohl für eine einheitliche Bearbeitung am sinnvollsten wäre.

Zu dem Thema hier:
Zitat:
Original von Holger:
Mit ScrollRasterBF kannst Du denselben Effekt innerhalb Deines primären Layers (Fensters) erreichen und sofort im Anschluss den nötigen Refresh ohne Zeitverzögerung durchführen.

ist mir immer nocht nicht ganz klar, wann ich denn nun direkt mit Layern hantiere (bzw. hantieren darf) und wann nicht? Verstanden habe ich bisher, wenn ich ein Fenster habe, Hände weg von Layern. Aber wieso? Und wann kann/sollte ich denn Layer benutzen?

Zum Thema Refresh: Wenn das Fenster kein "NOCAREREFRESH" angegeben hat, ist es dann automatisch im SIMPLEREFRESH oder SMARTREFRESH Modus, wenn nichts angegeben wird?

Und noch eine Frage: Kann ich bei einem RastPort eines Fensters immer davon ausgehen, dass er eine gültige BitMap enthält? Gibt mir diese die Dimension der Zeichenfläche im RastPort an (z.b. für Koordinaten + Abmessungen für EraseRect, so dass ich nicht an Stellen des RastPorts komme, die ggf. außerhalb der Zeichenfläche liegen)?

[ Dieser Beitrag wurde von Reth am 14.04.2011 um 22:49 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]

2011-04-15, 11:55 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Kommt das ungefähr so hin? Oder läuft das Ganze anders?

Ich denke schon. Ich habe allerdings gerade keine Dokumentation zur Hand, um das noch mal genau zu überprüfen.

Zitat:
ist mir immer nocht nicht ganz klar, wann ich denn nun direkt mit Layern hantiere (bzw. hantieren darf) und wann nicht? Verstanden habe ich bisher, wenn ich ein Fenster habe, Hände weg von Layern. Aber wieso? Und wann kann/sollte ich denn Layer benutzen?
Im Fenster-System verschickt intuition an alle Beteiligten Refresh-Nachrichten, wenn Refreshs nötig sind, bzw. zeichnet auch schon mal Fensterrahmen und Gadgets selbst neu. Voraussetzung ist, dass intuition auch weiß, dass eine Situation eingetreten ist, die Refreshs nötig machen könnte.

Deshalb sind sämtliche Layer-Operation tabu, die dazu führen könnten, dass irgendein Unbeteiligter einen Refresh durchführen müsste, von dem er dann nichts mitbekommt. Für alle diese Operationen gibt es aber Pendants, MoveWindow statt MoveLayer, WindowToFront statt LayerToFront, etc.

Da für reine Layer, die nicht zu einem Fenster gehören, keine solchen Alternativen zur Verfügung stehen, können diese eben nicht systemkonform mit Fenstern vermischt werden.

Etwas anderes sind Operationen, die ausschließlich den Layer Deines Fensters betreffen. Wenn Du also Scroll-Operationen innerhalb Deines Fensters durchführst, erhältst Du u.U. Damage in Deinem Layer, aber Du weißt ja, dass Du diese Operation durchgeführt hast, kannst also im direkten Anschluss das Damage Bit überprüfen und, wenn nötig, einen Refresh durchführen.
Zitat:
Zum Thema Refresh: Wenn das Fenster kein "NOCAREREFRESH" angegeben hat, ist es dann automatisch im SIMPLEREFRESH oder SMARTREFRESH Modus, wenn nichts angegeben wird?
Das sind zwei verschiedene Paar Schuhe. Der Refresh-Modus eines Fensters ist immer simple, smart oder super-bitmap. no-care ist ein zusätzliches Flag, das lediglich besagt, dass man keine Refresh-Nachrichten bekommen möchte.

Zitat:
Und noch eine Frage: Kann ich bei einem RastPort eines Fensters immer davon ausgehen, dass er eine gültige BitMap enthält?
Ja
Zitat:
Gibt mir diese die Dimension der Zeichenfläche im RastPort an (z.b. für Koordinaten + Abmessungen für EraseRect, so dass ich nicht an Stellen des RastPorts komme, die ggf. außerhalb der Zeichenfläche liegen)?
Nein.
Die BitMap ist mit Ausnahme von super-bitmap-refresh Fenstern die BitMap des Screens und hat dementsprechend deren Ausmaße, bzw. je nach Alignment ist sie sogar größer als der Screen.

Die Größe Deiner Zeichenfläche ist die Größe des Fensters abzüglich des Rahmens. Wenn Du GZZ-Fenster benutzt, ist die Zeichenfläche identisch mit der Größe Deines Layers, d.h. Du kannst einfach munter draus los löschen, ohne etwas zu überschreiben. Der Nachteil ist, dass das Fenster dann zwei Layer besitzt (Overhead), einen für den Rahmen und einen für die Zeichenfläche.

Normale Fenster haben nur einen Layer und Du musst selbst dafür sorgen, dass Du den Fensterrahmen nicht überschreibst.

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

[ - Answer - Quote - Direct link - ]

2011-04-15, 22:56 h

Reth
Posts: 1858
User
@Holger:
Danke fürs Antworten!

Zitat:
Original von Holger:
Da für reine Layer, die nicht zu einem Fenster gehören, keine solchen Alternativen zur Verfügung stehen, können diese eben nicht systemkonform mit Fenstern vermischt werden.

Wann und warum kann ich denn dann überhaupt reine Layer ohne Fenster benutzen (sprich was wäre denn ein gutes Beispiel)?
Zitat:
Original von Holger:
Etwas anderes sind Operationen, die ausschließlich den Layer Deines Fensters betreffen. Wenn Du also Scroll-Operationen innerhalb Deines Fensters durchführst, erhältst Du u.U. Damage in Deinem Layer, aber Du weißt ja, dass Du diese Operation durchgeführt hast, kannst also im direkten Anschluss das Damage Bit überprüfen und, wenn nötig, einen Refresh durchführen.

Kann ich denn Scrolloperationen im eigenen Fenster durchführen, ohne Schaden anzurichten (nur mit Clipping, oder)?
Zitat:
Original von Holger:
Der Refresh-Modus eines Fensters ist immer simple, smart oder super-bitmap.

Und welcher ist es, wenn ich nichts angebe?
Zitat:
Original von Holger:
Die Größe Deiner Zeichenfläche ist die Größe des Fensters abzüglich des Rahmens. Wenn Du GZZ-Fenster benutzt, ist die Zeichenfläche identisch mit der Größe Deines Layers

Dann kann ich die Dimension der "bezeichenbaren Fläche" eines RastPorts nie ermitteln, ich muss immer die Dimension des Fensters und die Angabe GZZ ja/nein kennen, wenn ich die Dimension der "bezeichenbare Fläche" wissen will?

[ - Answer - Quote - Direct link - ]

2011-04-18, 10:39 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Wann und warum kann ich denn dann überhaupt reine Layer ohne Fenster benutzen (sprich was wäre denn ein gutes Beispiel)?

Wenn Du beispielsweise einen Custom-Screen öffnest und auf diesem niemals Fenster benutzt. Keiner sagt, dass es überhaupt sinnvolle Anwendungsmöglichkeiten dafür geben muss. Layers sind einfach das von intuition verwendete Back-End. So wie auch das input.device, für das es auch in den seltensten Fällen Gründe für die direkte Benutzung gibt.
Zitat:
Kann ich denn Scrolloperationen im eigenen Fenster durchführen, ohne Schaden anzurichten (nur mit Clipping, oder)?
Ja klar, der RastPort Deines Fensters enthält auch einen Pointer auf den Layer Deines Fensters, weshalb Scroll-Operationen in diesem RastPort auch korrektes Clipping verwenden.

Zitat:
Und welcher ist es, wenn ich nichts angebe?

Musst Du einfach mal in die includes gucken, welches dieser Flags den Wert 0 hat. Ich glaube, es war simple-refresh.

Zitat:
Dann kann ich die Dimension der "bezeichenbaren Fläche" eines RastPorts nie ermitteln, ich muss immer die Dimension des Fensters und die Angabe GZZ ja/nein kennen, wenn ich die Dimension der "bezeichenbare Fläche" wissen will?
Sofern Du nicht durchgängig auf GZZ-Fenster setzt, ja.

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

[ - Answer - Quote - Direct link - ]

2011-04-29, 23:35 h

Reth
Posts: 1858
User
@Holger:
Bin gerade über
C code:
GT_BeginRefresh(), GT_EndRefresh() und GT_RefreshWindow()

gestolpert.

Letzteres nutze ich schon, da ich Gadtools Gadgets verwende. So wie ich die Beschreibung verstehe, dient diese Funktion aber nur dem Aktualisieren der Gadgets.

Sollte ich in meinem Fall dann besser GT_BeginRefresh() und GT_EndRefresh() verwenden, auch wenn ich meine Gadgets gar nicht mehr aktualisieren muss? Oder spielt das hier keine Rolle und ich kann BeginRefresh() bzw. EndRefresh() verwenden?

Habe auch gerade gesehen, dass ich WFLG_NOCAREREFRESH mit Gadtools gar nicht verwenden darf/soll. Hatte damit bisher aber keine Probleme!

[ - Answer - Quote - Direct link - ]

2011-05-01, 14:38 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Sollte ich in meinem Fall dann besser GT_BeginRefresh() und GT_EndRefresh() verwenden, auch wenn ich meine Gadgets gar nicht mehr aktualisieren muss? Oder spielt das hier keine Rolle und ich kann BeginRefresh() bzw. EndRefresh() verwenden?

Woher weißt Du denn bei einem normalen Refresh-Zyklus, dass die Gadgets keinen Refresh benötigen?
Zitat:
Habe auch gerade gesehen, dass ich WFLG_NOCAREREFRESH mit Gadtools gar nicht verwenden darf/soll. Hatte damit bisher aber keine Probleme!
Ich vermute mal, dass diese Beschränkung ab AOS3.0 keine Rolle mehr spielt, aber offiziell aufgehoben wurde sie nicht. Das hängt aber auch von den verwendeten Elementen ab, simple Objekte wie Buttons haben schon immer ohne expliziten Refresh funktioniert.

Die korrekte Verwendung gemäß Spezifikation schließt aber NoCareRefresh aus.

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

[ - Answer - Quote - Direct link - ]

2011-05-04, 21:24 h

Reth
Posts: 1858
User
@Holger:

Wenn wir gerade beim Thema sind, und weil ich auch gerade die Refreshmethoden in meine Windowklasse einbaue:

Was ist denn mit den folgenden Funktionen:
C code:
RefreshGadgets() und GT_RefreshWindow()

?

Nach meinem Verständnis brauch ich die 2. nach dem initialen Hinzufügen von Gadgets zu einem Fenster, um die Gadgets anzuzeigen. Die erste Funktion benötige ich immer dann, wenn ich denke, dass die Gadgets refreshed werden müssen, oder wenn ich Gadgets verändert habe und deswegen aktualisieren will.
Passt das soweit?

Nach diesem Verständnis würde ich dann RefreshGadgets auch immer zwischen BeginRefresh und EndRefresh rufen, sobald ich eine Refresh-Message bekommen habe. Korrekt?

Und noch eine Frage dazu:
Zitat:
Original von Holger:
Egal, in welcher Reihenfolge die Verarbeitung im Code steht, wirst Du die Events in der Reihenfolge verarbeiten, wie Du sie empfängst.

Das ist aber überhaupt kein Problem. Jeder Layer hat ein Flag, das besagt, ob Damage vorhanden ist und das bei EndRefresh(...,TRUE) zurückgesetzt wird. Wenn Du eine Refresh-Message bekommst, das Flag aber nicht gesetzt ist, dann weißt Du, dass Du zwischen der Ursache und dem Empfang schon einen Maus oder Timer getriggerten Refresh durchgeführt hast und die Message ignorieren kannst.

Wenn ich nach getaner Arbeit den Originalzustand der ClippingRegion wieder herstelle, verursache ich damit nicht "neuen Damage" und komme so in einen "Teufelskreis"?

Für das Herstellen des Originalzustandes: Ich hatte verstanden meine Bereiche mit der alten ClipRegion zu verknüpfen, muss diese Originalregion aber am Schluss wieder herstellen.
Ist dies denn überhaupt sinnvoll, oder merke ich mir nur die alte ClipRegion nach BeginRefresh, aktualisiere dann meine Bereiche mit einer eigenen, neuen ClipRegion und stelle die Original-ClipRegion vor EndRefresh wieder her?

[ - Answer - Quote - Direct link - ]

2011-05-04, 22:02 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Die erste Funktion benötige ich immer dann, wenn ich denke, dass die Gadgets refreshed werden müssen, oder wenn ich Gadgets verändert habe und deswegen aktualisieren will.
Passt das soweit?

Passt.
Zitat:
Nach diesem Verständnis würde ich dann RefreshGadgets auch immer zwischen BeginRefresh und EndRefresh rufen, sobald ich eine Refresh-Message bekommen habe. Korrekt?
Nein. Intuition zeichnet Gadgets und Fensterrahmen selbsttätig neu, wenn es Damage verursacht hat und nur in diesen Fällen bekommst Du Refresh-Messages. Nur wenn Du hinterm Rücken von Intuition Damage verursacht hast (siehe vergangene Diskussion zu Scroll-Funktionen), der auch Gadgets betreffen könnte, musst Du den Refresh der möglicherweise betroffenen Gadgets selbst anstoßen. Ansonsten dient RefreshGadgets() ausschließlich zum Updaten nach Änderungen.

Bei gadtools gibt es die Besonderheit, dass die Gadgets u.U. nicht alle Grafik-Informationen zum automatischen Neuzeichnen beinhalten. Das liegt daran, dass gadtools zumindest in älteren Versionen nicht auf BOOPSI aufsetzt (es war eine Parallelentwicklung). Genau deshalb gibt es die Funktionen GT_BeginRefresh und GT_EndRefresh, die die entsprechenden Intuition-Funktionen komplett ersetzen, wenn man gadtools benutzt. Diese Funktionen rufen nicht nur BeginRefresh und EndRefresh auf, sondern führen auch die für den kompletten Gadget-Refresh nötigen Zeichenbefehle aus.

Deshalb sieht die Trivial-Routine zum vollständigen Refresh eines Gadtools-Fenster (wenn man eine Refresh-Message bekommen hat, wohlgemerkt), das außer Gadgets nicht anderes enthält, genau so aus:
code:
GT_BeginRefresh();
GT_EndRefresh();

Weil aber mindestens diese zwei Routinen für einen Refresh aufgerufen werden müssen, arbeiten Gadtools-Oberflächen auch nicht mit NoCareRefresh zusammen.

Zitat:
Für das Herstellen des Originalzustandes: Ich hatte verstanden meine Bereiche mit der alten ClipRegion zu verknüpfen, muss diese Originalregion aber am Schluss wieder herstellen.
Ist dies denn überhaupt sinnvoll, oder merke ich mir nur die alte ClipRegion nach BeginRefresh, aktualisiere dann meine Bereiche mit einer eigenen, neuen ClipRegion und stelle die Original-ClipRegion vor EndRefresh wieder her?

Letzteres.
Vor BeginRefresh besitzt der Layer ja noch gar keine ClippingRegion. Erst der Aufruf von BeginRefresh macht ja aus der bisherigen Damage-Liste die zugehörige Clipping-Region. Dann kannst Du diese manipulieren, musst natürlich vor EndRefresh den alten Zustand wiederherstellen.

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

[ - Answer - Quote - Direct link - ]

2011-05-04, 23:15 h

Reth
Posts: 1858
User
@Holger:

Danke!
Zitat:
Original von Holger:
Zitat:
Für das Herstellen des Originalzustandes: Ich hatte verstanden meine Bereiche mit der alten ClipRegion zu verknüpfen, muss diese Originalregion aber am Schluss wieder herstellen.
Ist dies denn überhaupt sinnvoll, oder merke ich mir nur die alte ClipRegion nach BeginRefresh, aktualisiere dann meine Bereiche mit einer eigenen, neuen ClipRegion und stelle die Original-ClipRegion vor EndRefresh wieder her?

Letzteres.
Vor BeginRefresh besitzt der Layer ja noch gar keine ClippingRegion. Erst der Aufruf von BeginRefresh macht ja aus der bisherigen Damage-Liste die zugehörige Clipping-Region. Dann kannst Du diese manipulieren, musst natürlich vor EndRefresh den alten Zustand wiederherstellen.

Aber mit der unter "Letzteres" genannten Lösung manipuliere ich ja die ClippingRegion nicht, sondern installiere meine eigene, die ich aus allen zu aktualisierenden Bereichen ermittle. Dann werden alle Objekte neu gezeichnet und abschließend wird die bei BeginRefresh erzeugte originale ClippingRegion wieder installiert. Oder hab ich das falsch verstanden?
Die Frage war nur, ob ich zu meiner eigenen ClippingRegion die Bereiche der Original-ClippingRegion hinzufügen muss oder nicht, bevor ich meine Objekte aktualisiere?

[ - Answer - Quote - Direct link - ]

2011-05-05, 19:34 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Aber mit der unter "Letzteres" genannten Lösung manipuliere ich ja die ClippingRegion nicht, sondern installiere meine eigene, die ich aus allen zu aktualisierenden Bereichen ermittle.

Den Teil hatte ich wohl überlesen. Mir ging es nur darum, dass alles zwischen BeginRefresh und EndRefresh stattfindet.
Zitat:
Die Frage war nur, ob ich zu meiner eigenen ClippingRegion die Bereiche der Original-ClippingRegion hinzufügen muss oder nicht, bevor ich meine Objekte aktualisiere?
Ja, Du willst ja sowohl die Bereiche, die sich aus der Anwendungslogik her verändert haben, als auch die Bereiche, die "beschädigt" wurden, aktualisieren. Das heißt, Du nimmst eine Oder-Verknüpfung vor.

Die Alternative wäre zwei Zeichenvorgänge durchzuführen, einen mit der Clip-Region, die von BeginRefresh installiert wurde, und einen mit Deiner Clip-Region.

Der Vorteil des Verknüpfens liegt darin, dass Bereiche, die sowohl "beschädigt", als auch von veränderten Objekten betroffen sind, nur einmal gezeichnet werden.

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

[ - Answer - Quote - Direct link - ]

2011-05-05, 23:53 h

Reth
Posts: 1858
User
Zitat:
Original von Holger:
Zitat:
Original von Reth:
Die Frage war nur, ob ich zu meiner eigenen ClippingRegion die Bereiche der Original-ClippingRegion hinzufügen muss oder nicht, bevor ich meine Objekte aktualisiere?

Ja, Du willst ja sowohl die Bereiche, die sich aus der Anwendungslogik her verändert haben, als auch die Bereiche, die "beschädigt" wurden, aktualisieren. Das heißt, Du nimmst eine Oder-Verknüpfung vor.
Aber wenn ich in diesem Fall die OriginalRegion nach EndRefresh wieder herstelle, wird dann nicht auch wieder das Damage-Flag gesetzt und die in dieser alten Region enthaltenen Bereiche ebenfalls wieder als beschädigt angesehen? Damit wäre doch einiges umsonst gewesen und die Katze beißt sich ein bisschen in den eigenen Schwanz, oder?

[ - Answer - Quote - Direct link - ]

2011-05-06, 12:31 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Aber wenn ich in diesem Fall die OriginalRegion nach EndRefresh wieder herstelle, wird dann nicht auch wieder das Damage-Flag gesetzt und die in dieser alten Region enthaltenen Bereiche ebenfalls wieder als beschädigt angesehen?

Moment mal.
Wie oft soll ich eigentlich noch sagen, dass alles, was Du tust, zwischen BeginRefresh und EndRefresh passieren soll?

Insofern möchte ich nie wieder etwas von nach EndRefresh hören.

Aber trotzdem möchte ich noch mal für die Akten festhalten, dass das Installieren einer Clipping-Region weder die Damage-Liste verändert, noch das Damage-Flag setzt.

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

[ - Answer - Quote - Direct link - ]

2011-05-06, 17:30 h

Reth
Posts: 1858
User
Zitat:
Original von Holger:
Moment mal.
Wie oft soll ich eigentlich noch sagen, dass alles, was Du tust, zwischen BeginRefresh und EndRefresh passieren soll?

Insofern möchte ich nie wieder etwas von nach EndRefresh hören.

Ja, Herr Lehrer! Mein Fehler! Hast ja recht und soll auch nicht passieren!

Zitat:
Original von Holger:
Aber trotzdem möchte ich noch mal für die Akten festhalten, dass das Installieren einer Clipping-Region weder die Damage-Liste verändert, noch das Damage-Flag setzt.

Danke! Das wollte ich wissen und es hilft weiter!

Aber mal OT für alle:
So interessant und hilfreich die ganze Diskussion ist (und ich bin Dir überaus dankbar für Deine/eure Hilfe), zeigt sie doch auch ein großes Manko bei der Programmierung von AOS: Man muss das System ja fast auswendig kennen, um vernünftig dafür programmieren zu können. Das ist in der heutigen Zeit ein sehr großer Nachteil in meinen Augen, da Entwickler für alle neueren Systeme doch einfach nur ihre Ideen umsetzen wollen, ohne das ganze System dafür in- und auswendig kennen zu müssen (wiederhole hier mal nen Teil, den jmd. schon in nem anderen Thread gepostet hat)!

Dem AOS fehlt eine vernünftige, einfach zu nutzende High-Level-API (die einzig Vergleichbare, die ich hier kenne ist die von Java, speziell 1.4 - einfach, intuitiv, leicht erlernbar und leicht bedienbar; man kann sich auf das Problem konzentrieren und muss sich nicht mit der "Infrastruktur" herumplagen! So lange das nicht behoben ist, wird es mit neuer Software eher schlechter werden als besser!)
Meine Meinung dazu!

[ - Answer - Quote - Direct link - ]

2011-05-06, 19:13 h

Holger
Posts: 8116
User
Zitat:
Original von Reth:
Danke! Das wollte ich wissen und es hilft weiter!

Gut, aber ich fasse es trotzdem nochmal zusammen:
  • BeginRefresh verwandelt die aktuelle Damage-Liste in eine Clipping-Region
  • EndRefresh deinstalliert diese Region und gibt die Liste frei (und löscht das Damaged-Flag)
    Zitat:
    Dem AOS fehlt eine vernünftige, einfach zu nutzende High-Level-API
    Ich glaub', das habe ich schon mal irgendwo gelesen ;)

    Mit Hollywood gibt es ja sogar eine.
    Allerdings ist diese halt kommerziell.

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

    [ - Answer - Quote - Direct link - ]

  • 2011-05-08, 18:09 h

    Reth
    Posts: 1858
    User
    Zitat:
    Original von Holger:
    Mit Hollywood gibt es ja sogar eine.
    Allerdings ist diese halt kommerziell.

    Habe mich damit noch nicht beschäftigt, auch noch nicht mit den SDKs für AOS4 und MOS bzw. den Möglichkeiten, die AROS hier bietet.

    Sind denn die "Executables" von Hollywood auch performant und leistungsfähig genug z.B. für echte 68060er oder gar 68040er?

    [ - Answer - Quote - Direct link - ]

    2011-05-08, 18:32 h

    Holger
    Posts: 8116
    User
    Zitat:
    Original von Reth:
    Sind denn die "Executables" von Hollywood auch performant und leistungsfähig genug z.B. für echte 68060er oder gar 68040er?

    Keine Ahnung, das ganze liegt nicht so sehr in meinem Interessengebiet. Ich glaube auch, dass "leichter Einstieg" und "kommerzielles SDK" keine günstige Kombination sind. Ich erwähne das Produkt nur der Fairness halber.

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

    [ - Answer - Quote - Direct link - ]

    2011-05-08, 23:00 h

    Reth
    Posts: 1858
    User
    @Holger:

    Finde ich auch gut so. Hatte gerade viele Antwortzeilen geschrieben aber nicht abgeschickt, da dies nicht mehr Thema dieses Threads ist.
    Würde gern einen neuen aufmachen, fürchte aber, das eine ggf. entstehende Diskussion u.U. weniger konstruktiv ausfallen könnte!

    [ - Answer - Quote - Direct link - ]

    2011-05-08, 23:33 h

    Holger
    Posts: 8116
    User
    @Reth:
    Na ja, einiges dazu findet sich im letzten Drittel dieses Threads:
    http://www.amiga-news.de/forum/thread.php?id=33913&BoardID=1

    (und bestimmt auch schon in älteren)

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

    [ - Answer - Quote - Direct link - ]


    1 -2- 3 4 5 6 [ - Post reply - ]


    amiga-news.de Forum > Programmierung > Neue Frage zu Überdeckungen [ - Search - New posts - Register - Login - ]


    .
    Masthead | Privacy policy | Netiquette | Advertising | Contact
    Copyright © 1998-2024 by amiga-news.de - all rights reserved.
    .