|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Neue Frage zu Überdeckungen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| 1 2 3 -4- 5 6 | [ - Beitrag schreiben - ] |
|
12.07.2011, 21:25 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ja, aber [GT_]BeginRefresh zeichnet das Fenster und nicht die Menüs neu. Die Menüs sind während des Refresh-Vorgangs nicht zu sehen. Es geht dabei ausschließlich um Gadgets. Und Menüs sind keine Gadgets. Nicht beim AmigaOS. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
12.07.2011, 21:38 Uhr Thore Posts: 2266 Nutzer |
Okay. Ja dann machts wieder Sinn. [ - Antworten - Zitieren - Direktlink - ] |
|
12.07.2011, 23:29 Uhr Reth Posts: 1858 Nutzer |
Zitat:Davon bin ich auch ausgegangen, aber weniger wegen der Menüs sondern weil ich dachte, dass die Fenstergadgets dann von GadTools gemacht würden (in meinem Fall werden aber weder Rahmen noch Fenstergadgets angezeigt). [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2011, 10:54 Uhr Holger Posts: 8116 Nutzer |
Zitat:Warum sollte gadtools irgendetwas mit Fenstergadgets machen? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.07.2011, 11:52 Uhr Thore Posts: 2266 Nutzer |
Die Fenstergadgets werden bei AmigaOS von Intuition geregelt. Das hat mit deinen eigenen Gadgets und Menu nichts zu tun. [ - Antworten - Zitieren - Direktlink - ] |
|
15.07.2011, 10:40 Uhr akl Posts: 265 Nutzer |
@Holger: >Ja, aber [GT_]BeginRefresh zeichnet das Fenster und nicht die Menüs >neu. Die Menüs sind während des Refresh-Vorgangs nicht zu sehen. >Es geht dabei ausschließlich um Gadgets. Und Menüs sind keine Gadgets. >Nicht beim AmigaOS. Umso seltsamer, dass man sie unbedingt in die GadTools-API integriert hat, und keine eigene MenuTools-API bereitgestellt hat ;-) [ - Antworten - Zitieren - Direktlink - ] |
|
15.07.2011, 13:52 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich schätze, das ist historisch bedingt. Die gadtools-Library scheint eine Parallelentwicklung zum restlichen AmigaOS zu sein. Sie benutzt in der ersten Fassung kein BOOPSI und es gibt auch eine Version, die unter AmigaOS 1.x läuft. Sie ist also eher so etwas wie eine guiutil.library, die man als Aufsatz implementiert und später ins OS integriert hat. Nur der Namen gadtools ist insofern unpassend gewählt. Hätte man die Library konsequent als AOS2.0 Feature unter Verwendung des ebenfalls mit AOS2.0 eingeführten BOOPSI entwickelt, wäre die Geschichte mit dem CreateContext und den speziellen Refresh und Notification Funktionen komplett überflüssig gewesen. Dann hätte man die übrig gebliebenen acht Funktionen (vielleicht hätte man es auf noch weniger reduzieren können) auch direkt in intuition eingebaut. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
17.07.2011, 19:57 Uhr Reth Posts: 1858 Nutzer |
Langsam wird es echt megafrustrierend! Habe nun alles so umgestellt, dass ich zuerst meine ClippingRegion erzeuge, dann BeginRefresh() rufe, danach die dadurch erzeugte ClippingRegion mit meiner VerODERe, das Ergebnis als ClipRegion installiere, den Blit durchführe, die OriginalClipRegion wieder installiere und EndRefresh rufe. Für das erste anzuzeigende Objekt wird das auch durchgeführt, nur leider wird nix dargestellt (kein Blitergebnis zu sehen)! Beim 2. Objekt komme ich nur bis OrRegionRegion, dann friert alles ein! (Argfhmpfgrfxl!!!) Ich könnte schreien vor Wut (musste mal raus)! Keine Ahnung was falsch läuft, allerdings ist eines auffällig: Für meine Eigene ClippingRegion wird bei jedem neuen Objekt eine neues Regionobjekt erzeugt und intern mit NewRegion() eine neue Region initialisiert (das liegt am Spielfeldaufbau, für jedes neu ermittelte 6-Eck wird die Schleife für den Aufbau wieder neu gerufen - das ist noch suboptimal). Komisch ist dabei, dass beim ersten und zweiten Aufruf die Adresse der Region-Struct immer die gleiche ist, obwohl nach dem Blitten des 1. Objektes das Region-Objekt zerstört wird (hat nur Scope innerhalb der Schleife), dabei wird DisposeRegion auf die Region-Struct ausgeführt und beim nächsten Refresh wird wieder NewRegion() ausgeführt und das Ergebnis dem Zeiger im Region-Objekt zugewiesen! Ist doch seltsam, dass dabei immer wieder die gleiche Adresse für die Region-Struct verwendet wird, oder (hab ich schon bei den ganzen letzten Tests gemerkt)? Oder kann es damit zusammenhängen, dass ich die Referenz meiner ClipRegion als const übergebe und über diese Referenz auf den Zeiger meiner Region-Struct zugreife? Wird immer verrückter! Hab noch nen Test gemacht und BeginRefresh() und EndRefresh() weggelassen. Dann wird auch brav geblittet (darf man diese Funktionen mit dem AOS4-SDK nicht mehr verwenden?)! Allerdings wird auch in Bereiche ausserhalb der erzeugten ClipRegion geblittet und das ist irritierend! So, um mal beim Blog-Character zu bleiben: Neuer Test mit Begin-/EndRefresh(), aber ohne Verknüpfung meiner Region mit der vorher installierten. Ergebnis: Es wird nichts geblittet, auch nicht ausserhalb meiner selbst erzeugten Region (diese hat folgende Ausmaße: MinX: 0 MinY: 20 MaxX: 810 MaxY: 740, ermittelt mit region->bounds.MinX usw.)! Zitat:Versuche nun zusätzlich noch die aktuell im Layer des RastPorts befindliche ClippingRegion mit zu VerODERn. Allerdings stellt mir hier das AOS4-SDK ein Bein, da der Zeiger auf die ClipRegion im Layer mit einem CONST versehen wurde! Habe mich erst einmal mit dem Weg-Casten des CONST begnügt, da der Zeiger auf die Region-Struct in meiner selbst gebauten Region-Klasse natürlich nicht CONST ist (und sein kann)! Gibt es hier noch eine bessere Lösung (für meine Konstellation)? Habe nun auch den letzten Test zusammen mit dem CONST-Hack wiederholt und die vor BeginRefresh() im Layer installierte ClipRegion zu meiner hinzugeODERt. Ergebnis ist immer noch ein leeres Spielfeld, da trotz installierter Region und trotz Begin-/EndRefresh() kein einziger Blit zu ner Darstellung führt! Hab ich noch was übersehen? Muss ich ausser auf Begin-/EndRefresh() auf noch was Anderes achten, z.B. auf Refresh-Messages, die ich dadurch erzeuge? So wie es aussieht erfolgt der Refresh einfach nicht, sobald ich mit und zwischen Begin-/EndRefresh() arbeite! Oder darf ich dann nicht mehr BltMaskBitMapRastPort() verwenden? [ Dieser Beitrag wurde von Reth am 18.07.2011 um 23:15 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
19.07.2011, 12:12 Uhr Holger Posts: 8116 Nutzer |
@Reth: Ich seh’ schon, da wird ein Beispielsprogramm benötigt. Allerdings weiß ich nicht, wann ich die Zeit dafür habe… -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
19.07.2011, 16:07 Uhr Reth Posts: 1858 Nutzer |
@Holger: Hi nochmal Holger, aus meinem Code oben kannst Du die Reihenfolge der Aufrufe entnehmen. Ich kann auch nochmal selbst versuchen die relevanten Teile in ein C-Bsp.-Programm zu packen, zu testen und hier zu posten! (Wie gesagt, derzeit funktioniert es nicht, sobald ich Begin-/EndRefresh benutze, wenn ich alles Andere unverändert lasse und nur die beiden Aufrufe auskommentiere klappts!) Bei weiterem Nachdenken ist mir allerdings aufgefallen, dass die Lösung für mich wohl auch nicht 100% funktionieren wird! Und zwar aus folgendem Grund: Am Spielfeldrand liegen ja meine 6-Ecke über dem grauen Hintergrund, dort sind aber die entstehenden Clipping-Rechtecke nicht 6-eckig! D.h., Türme, die dort am Rand blinken und wieder entfernt werden müssen, würden mit diesem Ansatz auch nicht richtig behandelt werden und Spuren wie auf meinen Screenshots hinterlassen! D.h., ich brauche hier eine grundsätzlich andere Vorgehensweise und stehe mir wohl gerade selbst immer im Weg. Das Problem ham doch schon zig Andere auf dem Amiga vor mir gelöst, dann müsste es doch probate Mittel dafür geben! Den Vorschlag mit Doublebouffering hab ich allerdings noch nicht ganz kapiert (außer die Trivialvariante alles in ner Offscreen-BitMap neu zu blitten und diese dann in den Rastport zu blitten! Wie wäre denn eine gute Herangehensweise für meine Anforderungen:
[ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2011, 01:00 Uhr Holger Posts: 8116 Nutzer |
Zitat:Alles Trockenübung, zwischen Theorie und Praxis klafft ein Unterschied. Zitat:Hast Du es inzwischen unter AOS3.x ausprobiert? Zitat:Ja, wozu gibt es denn die Möglichkeit, mit einer Maske zu blitten? Zitat:Das bezweifle ich. Wie viele Spiele sind systemkonform programmiert und wie viele davon zeichnen nicht einfach alles neu? Zitat:Doublebuffering löst nicht die angesprochenen Probleme. Wenn Du eine Offscreen-BitMap benutzt, kannst Du alles exakt so machen, wie ohne. D.h. Du zeichest mit Clipping in die Offscreen-BitMap und blittest diese dann mit Clipping auf den Bildschirm. Du kannst es natürlich auch ohne Clipping machen, so wie Du es auch ohne Offscreen-BitMap ohne Clipping machen könntest. Die Auswirkungen sind die gleichen. Nur bei Flip-Buffer Strategien muss man ohnehin jedesmal alles neu zeichnen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2011, 12:55 Uhr Reth Posts: 1858 Nutzer |
Zitat:Nein noch nicht. Dort müsste ich erst einmal das Projekt komplett neu aufsetzen und compilierbar machen. Oder ein einfaches C-Bsp. programmieren und dieses dann unter 68k nochmal compilieren und ausführen. Zitat:Hilft in diesem Fall nicht, da die Türme an diesen Stellen ja teilweise über dem grauen Hintergrund erscheinen dürfen! Nur wenn man die Maus wieder wegbewegt, dann soll dort auch wieder der graue Hintergrund dargestellt werden und nicht Reste vom Turm! Zitat:Aber das Flimmern und der langsame Bildaufbau sollten bei einer Offscreen-Bitmap doch nicht mehr erfolgen! [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2011, 13:21 Uhr Holger Posts: 8116 Nutzer |
Zitat:Dann versteh ich das Problem nicht. Der graue Hintergrund wird doch beim Refresh wiederhergestellt. Zitat:Schonmal auf einem AGA-Screen mit hoher Auflösung und voller Farbanzahl einen kompletten Screen geblittet? Klar, dank interleaved BitMaps flimmert das nicht, das ruckelt. Der Ausgangspunkt war der, das Dank Clipping überflüssige Operationen nicht durchgeführt werden, was die Systemlast insgesamt reduziert. Und das ändert sich bei Verwendung einer Offscreen-BitMap nicht, im Gegenteil. Da sich die zu transferierende Datenmenge fast verdoppelt, ist es um so nützlicher, selbige zu reduzieren. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
20.07.2011, 18:46 Uhr Reth Posts: 1858 Nutzer |
Zitat:Aber durch wen den? Selber blitten oder Backfill-Hook einbauen? Derzeit passiert da gar nichts (s. Screenshots in diesem Thread), egal, welchen der beiden Ansätze ich nehme (mein ursprünglicher und der mit Begin-/EndRefresh). [ - Antworten - Zitieren - Direktlink - ] |
|
22.07.2011, 00:43 Uhr Reth Posts: 1858 Nutzer |
Also! Hab mal ein Bsp.-Programm mit Source erstellt (AOS4 binary), was mich dank "Amiga-API", rauskopieren und anpassen aus meinem C++ Code einige Stunden gekostet hat (bin immer noch Anfänger in diesen Dingen)! (Da könnt ich mich aufregen, für solch simple Sachen, wie in dem Bsp. angegeben so viel Code mit so vielen Fehlermöglichkeiten! So kommt keiner und programmiert für den Amiga oder das AmigaOS! Für meine C++-Gehversuche hab ich schon einiges gekapselt und gewrapped, als API taugt das aber nie und nimmer, v.a., da ich die Fehlerbehandlung hab schleifen lassen. Dafür lässt es sich etwas intuitiver und einfacher verwenden [finde ich]!) So, zurück zum Thema! Bei dem Bsp. passiert Folgendes (wähle immer einen 1024x768 Screenmode): In der aktuellen Sourceversion wird alles brav geblittet. Sobald ich aber BeginRefresh() und EndRefresh() aktiviere wird nichts mehr dargestellt! Dasselbe Problem hab ich auch in meinem eigentlichen Programm. Der Einfachheit halber hab ich mal alle Menüs und das Clipping weggelassen! Wo ist denn nun aber mein fundamentaler (Denk-)Fehler? Sobald ich mit Begin-/EndRefresh() arbeite erfolgt keine Blitausgabe mehr! [ - Antworten - Zitieren - Direktlink - ] |
|
22.07.2011, 18:53 Uhr Thore Posts: 2266 Nutzer |
Ja Du hast einen Denkfehler. Der zeichnet bei Begin/EndRefresh auch nur wenn die Layer zerstört wurden. Wenn du z.B. ein IDCMP_REFRESHWINDOW einbaust, kannst Du im Main-Loop (while Schleife mit den cases) BeginRefresh/EndRefresh verwenden, und das Bild refresht dann sobald die Layer zerstört werden (z.B. durch Verschieben des Fensters oder Größe ändern...also wenn systemseitig neu gezeichnet werden muss) Übrigens crasht der Hook unter MorphOS... > Da könnt ich mich aufregen, für solch simple Sachen, wie in dem Bsp. angegeben so viel Code mit so vielen Fehlermöglichkeiten! So kommt keiner und programmiert für den Amiga oder das AmigaOS! Lass mal die IDE bei Win weg und frag dann, wer hier noch was programmieren würde  Die haben hier die gleichen Probleme mit Messages, Refreshing etc pp. Die IDEs haben jedoch schon Programmteile eingebaut, die dann einfach mitgelinkt werden (z.B. der Main-Loop). Oft muss man aber auch hier eine Refresh-Routine aufrufen.[ - Antworten - Zitieren - Direktlink - ] |
|
22.07.2011, 21:08 Uhr Reth Posts: 1858 Nutzer |
Zitat:Dann hab ich irgendwo an Holgers Ausführungen was übersehen oder falsch verstanden! Wie kann ich denn dann nun meine Aktualisierungen am besten durchführen? Ohne Begin-/EndRefresh()? Bleibt immer noch das Problem mit dem grauen Hintergrund an den 6-Eck-Grenzen, der nicht wieder hergestellt wird. Dafür hab ich noch keine Idee (meine ursprüngliche möchte ich eigentlich nicht wieder einführen)! Zitat:Was soll ich tun? Beim Thema MOS bin ich (leider) noch lange nicht (Ziel ist zwar schon, dass die Programme möglichst überall laufen, aber nicht das Primäre)! [ - Antworten - Zitieren - Direktlink - ] |
|
22.07.2011, 22:30 Uhr Thore Posts: 2266 Nutzer |
Hast Du versucht, mal eigene Layer, bzw ClipRegions zu erstellen? Wenn die zerstört werden könnte bei EndRefresh diese wieder rekonstruiert werden, und klappen, auch ohne dem IDCMP. Hab ich allerdings jetzt nicht ausprobiert. Hab eben den Standardfall dargelegt, wie man das zersören des Fensters umgeht durch Fensterveränderungen. Zum Hook, das muss ich mir mal genauer anschauen. Ich denk irgendwie wär das machbar, aber er lief in einen Crash. [ - Antworten - Zitieren - Direktlink - ] |
|
22.07.2011, 22:44 Uhr Reth Posts: 1858 Nutzer |
Zitat:In meinem Originalcode erstelle ich eine ClippingRegion, rufe BeginRefresh(), installiere die ClippingRegion im Rastport, Blitte alles, installiere die originale ClippingRegion wieder und rufe EndRefresh(). So wie hier im Thread besprochen. Ergebnis ist dasselbe: Ohne Begin-/EndRefresh() funktioniert das Blitten, mit nicht. Ich versuch mal mein Bsp. anzupassen! [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2011, 00:31 Uhr Holger Posts: 8116 Nutzer |
Zitat:Der Sinn von Begin/EndRefresh besteht darin, nur dorthin zu zeichnen, wo es aus Sicht das Systems nötig ist. Die hohe Kunst besteht nun darin, die Regionen, die aus Sicht der Anwendung aktualisiert werden müssen, damit zu verknüpfen. Wenn das nicht geht, braucht man zwei getrennte Zeichenvorgänge, mit dem Nachteil, dass Regionen, die aus beider Sicht einen Refresh benötigen, zweimal gezeichnet werden. Zitat:Ich verstehe immer noch nicht das Problem. EraseRect zum Löschen und dann das Sechseck drübergepinselt. Zitat:Das dürfte unter AOS 3.x ebenfalls Probleme bereiten. Um eine Hook-Funktion in C zu implementieren muss der h_Entry auf eine Compiler-spezifische Support-Funktion zeigen, die die Umgebung für die in h_SubEntry stehende C-Funktion einrichtet und sie dann aufruft. Alternativ kann man auch mit viel Magie die C-Funktion selbst dafür vorbereiten, dazu muss man die Registerübergabe deklarieren und das Sichern und Wiederherstellen der Umgebung (z.B. Pointer auf die globalen Variablen) aktivieren.Zitat:Was soll ich tun? Beim Thema MOS bin ich (leider) noch lange nicht (Ziel ist zwar schon, dass die Programme möglichst überall laufen, aber nicht das Primäre)! Wenn das in AOS4 auch ohne dem klappt, gut. Mit anderen Systemen kann man das nicht so machen. Zitat:Wie bereits gesagt, man muss herausfinden, was es bedeutet, wenn man es so macht. Es deutet alles darauf hin, dass eine so installierte eigene Clipping-Region mit der durch BeginRefresh installierten UND-verknüpft wird. Ist natürlich doof, wenn man eigentlich gerne ODER gehabt hätte. Und wenn Du schon dabei bist, Dein Beispiel zu überarbeiten, solltest Du ein wenig Aufmerksamkeit auf den Unterschied zwischen Public-Screen und Custom-Screen legen. Außerdem darüber nachdenken, ob es gut ist, eine Message zurückzuschicken und danach noch darauf zuzugreifen. Und ob es sinnvoll ist, NoCareRefresh anzugeben, wenn man doch eigentlich den Refresh selbst in die Hand nehmen will. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2011, 01:11 Uhr Reth Posts: 1858 Nutzer |
Zitat:Im Originalcode verknüpfe ich die ClippingRegion via ODER mit der bereits im Layer vorhandenen Region. Das Ergebnis setze ich als neue Region (s. weiter oben im Thread). Werde das im Bsp. mal anpassen. Zitat:Danke für die Hinweise! Bin wie gesagt noch Anfänger (aus meiner Sicht) bzgl. AmigaOS-Programmierung! Allerdings hab ich den Teil mit den Messages woanders aufgeschnappt nur hier falsch umgesetzt! Wenn man die Message gleich mit einem Reply versehen, aber dennoch weiter nutzen will, muss man sich die benötigten Attribute kopieren. Im Originalcode mach ich das auch (hoffentlich richtig)! [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2011, 01:26 Uhr Reth Posts: 1858 Nutzer |
So, habe mal ein neues Bsp. (AOS4 binary) mit Source bereitgestellt. Hier bekomme ich nun immer einen DSI-Fehler! Egal, ob mit oder ohne Begin-/EndRefresh()! Das Blit-Verhalten ist dennoch unverändert, also mit den Refresh-Funktionen sieht man nix, ohne allerdings das ganze 6-Eck! Also nicht nur den Bereich, den mein ClipRect angibt! Dabei ist es egal. ob ich Begin-/EndRefresh um den ganzen Code-Bereich (also mit den InstallClipRegion-Aufrufen) setze, oder nur direkt vor und nach dem Blitaufruf! Was passt denn hier noch nicht? [ Dieser Beitrag wurde von Reth am 23.07.2011 um 01:28 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2011, 02:15 Uhr Holger Posts: 8116 Nutzer |
Zitat:Also, jetzt noch mal ganz langsam. 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. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2011, 02:33 Uhr Holger Posts: 8116 Nutzer |
Also so in der Art müsste es gehen.code:BeginRefresh(window); struct Region* r=NewRegion(); OrRegionRegion(window->RPort->Layer->DamageList, r); // Für jedes eigene Objekt, das Refresh benötigt OrRectRegion(r, &rect); EndRefresh(window, TRUE); struct Region* oldR=InstallClipRegion(window->RPort->Layer, r); // Hier kommen die Zeichenbefehle fürs gesamte Spielfeld hin InstallClipRegion(window->RPort->Layer, oldR); DisposeRegion(r); -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2011, 12:26 Uhr Reth Posts: 1858 Nutzer |
@Holger: Vielen Dank für den Beispielcode, werde ihn hoffentlich heute noch ausprobieren! Zitat:Kam die ganze Erkenntnis durch mein Beispiel? Denn einige der Sachen hatte ich schon weiter vorn im Thread gefragt (z.B., ob ich das ganze Clipping, Begin-/EndRefresh usw. auch ohne entspr. Intuition-Message durchführen kann und auch, dass ich meine ClippingRegion mit der aus dem Layer des RastPorts verknüpfen solle)? Oder wolltest Du, dass ich es selbst rausfinde (sind ernst gemeinte Fragen, also bitte nicht böse sein)? Zitat:Ist das sicher, oder ne starke Vermutung? Vielleicht steht er ja doch in der ClipRegion des Layers, doch diese ist leer, da kein Schaden vorhanden ist (solange ich keine eigenen Aktionen durchführe)? [ - Antworten - Zitieren - Direktlink - ] |
|
23.07.2011, 23:40 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die Sache, wie die Verknüpfung zwischen den zwei Clips im AmigaOS implementiert ist, wusste ich nicht, sonst hätte ich nicht gefragt, was das Setzen des Clips vor BeginRefresh bewirkt. Das war nicht rethorisch gemeint. Zitat:Einiges geht unter, wenn so viel auf einmal kommt. In diesen Punkten dachte ich eher, dass Du es schon verstanden hättest. Zitat:Die Verknüpung war (und ist) das Konzept. Wenn ich Beispielcode für eine konkrete Implementierung gehabt hätte, hätte ich ihn auch gepostet. Zitat:Das lässt sich ziemlich leicht überprüfen. ClipRegion hat nach BeginRefresh denselben Wert wie vorher, also NULL, wenn man keine eigene clip-Region gesetzt hat. Auch dann, wenn effektiv geclippt wird. Das habe ich für AOS3.x überprüft.Zitat:Ist das sicher, oder ne starke Vermutung? Aber allein vom Verhalten des Programms war eigentlich auch nichts anderes mehr möglich. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
24.07.2011, 01:40 Uhr Reth Posts: 1858 Nutzer |
@Holger: Danke für das Code-Beispiel, hat funktioniert! Auch vielen Dank an die anderen Helfer hier im Thread. Ein neues Bsp. (AOS4) mit Source hab ich bereitgestellt. Einige Sachen hab ich allerdings noch nicht verstanden, dazu hier noch mehr. Zitat:Zumindest soweit, als dass ich die Refresh-Funtkionen brauche, wenn ich kein NOCAREREFRESH angegeben habe und entsprechende Messages von Intuition bekomme. Und auch, was bei Begin-/EndRefresh so grob passiert, weshalb wir es ja hier für mein Refresh-Problem diskutieren. Zitat:Wieso funktioniert es dann mit der DamageList? Es ist doch darin auch kein beschädigter Bereich vorhanden, wenn ich BeginRefresh rufe! (Wenn ich Dein Bsp. mit ClipRegion des Layers statt mit Damagelist ausführe friert das ganze System ein, hab ich auch noch nicht kapiert wieso.) Und wenn ich dann meine ClipRegion installiere müsste nach dem von Dir Gesagtem doch diese auch wieder mit 0 verUNDet werden!? Das passiert in diesem Fall aber offensichtlich nicht, oder? Was ist der Unterschied? Also ich hab auch noch nicht verstanden, wieso ich beim installieren meiner ClipRegion, die ich mit der DamageList verODERt habe (die aber keinen Damage enthält) Erfolg habe, wenn ich die gleiche ClipRegion installiere, die ich mit der ClipRegion des Layers verODERt habe (die ja NULL sein müsste bzw. leer) aber nicht!? Zitat:Aber wo liegt der System-Clip denn dann? 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!) Und noch eine Frage: Macht es einen Unterschied, ob ich meine Region vor oder nach BeginRefresh() mit NewRegion() anlege? [ Dieser Beitrag wurde von Reth am 24.07.2011 um 23:06 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
25.07.2011, 14:36 Uhr Holger Posts: 8116 Nutzer |
Zitat:Spielt keine Rolle. Zitat:In meinem Code wird aber erst nach EndRefresh() gezeichnet, deshalb findet die VerUNDung nicht statt. Zitat:Nein. Nur die ODER-Operation muss zwischen BeginRefresh und EndRefresh stattfinden, um sicherzustellen, dass der Layer gelockt ist. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
25.07.2011, 22:33 Uhr Reth Posts: 1858 Nutzer |
Danke!Zitat:Das ganze funktioniert aber auch nicht mit Deiner Code-Version! Wenn ich die DamageList nehme klappt alles, nehme ich mit Deinem Bsp. die ClipRegion friert das System komplett ein (wie beschrieben). Woran liegt das denn? [ - Antworten - Zitieren - Direktlink - ] |
|
25.07.2011, 23:04 Uhr Thore Posts: 2266 Nutzer |
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) Warum das System einfriert weiß ich nicht, gibts dazu nen Sourcecode? [ - Antworten - Zitieren - Direktlink - ] |
| 1 2 3 -4- 5 6 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Neue Frage zu Überdeckungen | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|