|
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 - ] |
|
25.07.2011, 23:43 Uhr Reth Posts: 1858 Nutzer |
@Thore: Dir auch vielen Dank für die Hilfe! Zitat:Daher sollte es in meinem Bsp.(-Code) auch keinen Unterschied machen, ob ich die DamageList oder die ClipRegion des Layers nehme. Nach meinem Verständnis zumindest. Zitat:Ja, wie gesagt. Nimm einfach mein letztes Bsp. und ersetze die DamageList mit der ClipRegion. [ - Antworten - Zitieren - Direktlink - ] |
|
26.07.2011, 00:40 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die ClipRegion ist NULL, solange Du keine gesetzt hast, d.h. Du rufst OrRegionRegion mit einem NULL-Pointer auf. Vielleicht mag das System das nicht so sehr. Zitat:Natürlich macht es einen Unterschied, das eine ergibt einen Sinn, das andere nicht. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 22:43 Uhr Reth Posts: 1858 Nutzer |
So, hallo mal wieder. Ich habe meinen Code mal umgestellt und es funktioniert soweit. Die alte Position bewegter Objekte wird noch nicht berücksichtigt, dazu muss ich erst mal meine Objektstruktur ändern, so dass die alten Positionen gemerkt werden. Einen Nachteil hat die Lösung allerdings! Durch das EraseRect flimmerts, da dabei jedesmal der graue Hintergrund des Fensters/Screens durchscheint. Was kann ich gegen diesen Nachteil noch unternehmen? Offscreen-BitMap nehmen oder Doublebuffering (was ich noch nicht so durchdrungen habe) oder gibt es noch einen einfacheren "Kniff"? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
29.07.2011, 23:03 Uhr Thore Posts: 2266 Nutzer |
Steht dein EraseRect auch zwischen BeginRefresh und EndRefresh? Oder außerhalb? [ - Antworten - Zitieren - Direktlink - ] |
|
30.07.2011, 11:36 Uhr Reth Posts: 1858 Nutzer |
@Thore: Außerhalb. Liegt aber daran, dass ich den Code nun nach dem funktionierenden Vorschlag von Holger umgestellt habe und die ClipRegion auch erst nach EndRefresh() installiert wird. Daher kann ich EraseRect auch erst danach aufrufen. [ Dieser Beitrag wurde von Reth am 30.07.2011 um 11:45 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
30.07.2011, 11:53 Uhr Thore Posts: 2266 Nutzer |
Probiers trotzdem reinzuquetschen. Wenns absolut nicht geht: Du kannst ein neues BeginRefresh und EndRefresh einbringen, und die Variable auf FALSE setzen. Also EndRefresh(MyClip, FALSE); Damit ist die Zeichnung noch nicht fertig, und erst bei EndRefresh(MyClip, TRUE); wird sie angezeigt. Also EraseRect dann zwischen den "neuen" Begin/EndRefresh. [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2011, 18:12 Uhr Holger Posts: 8116 Nutzer |
Zitat:Erst einmal eine Verständnisfrage: der graue Hintergrund flimmert nur innerhalb des durch die ClipRects festgelegten Bereiches, oder? Zitat: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. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2011, 18:14 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich glaube, Du hast eine völlig falsche Vorstellung davon, was BeginRefresh und EndRefresh machen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2011, 20:22 Uhr Thore Posts: 2266 Nutzer |
> Ich glaube, Du hast eine völlig falsche Vorstellung davon, was BeginRefresh und EndRefresh machen. Sie werden dafür benötigt, daß nur die beschädigten Regionen bei einem Refresh neu gezeichnet werden müssen, also nur die, die ein Refresh nötig haben. Vermutlich hab ich das in dem Context mit dem Windows BeginRefresh/EndRefresh zusammengeschmissen, wobei es hier so ist, daß die sichtbare Änderung erst beim EndRefresh dargestellt wird? [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2011, 20:27 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nein, Zeichenoperationen gehen trotzdem direkt und sofort in die Zielbitmap, es wird lediglich geclippt. Das mag vielleicht im Falle von SuperBitmap-Fenstern anders sein, aber von denen war hier nicht die Rede. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2011, 21:22 Uhr Thore Posts: 2266 Nutzer |
Alles klar, dann kommt er um eine doppelte Zeichenfläche wohl nicht drumherum. Ob per DoubleBuffer oder anderer Weise mal offengelassen. [ - Antworten - Zitieren - Direktlink - ] |
|
01.08.2011, 23:29 Uhr Reth Posts: 1858 Nutzer |
Danke für eure Tips!Zitat:Ja, genau. Zitat:Wie wäre dann die Offscreen-BitMap-Lösung am geeignetsten? Lege ich die BitMap für jeden Refresh-Vorgang in der gerade benötigten Größe neu an oder halte ich vorsorglich eine BitMap in Spielfeldgröße bereit, erstelle nur den zerstörten Bereich mit Clipping neu und blitte diesen in den sichtbaren Bereich? Der Vorschlag, den immer verdeckten Bereich nicht zu erasen würde z.T. helfen. Wenn ich um mein Spielfeld irgendwie ne "Hintergrund-" bzw. "Umgebungsgrafik" hinbekäme wäre das Problem komplett gelöst. Denke auch wieder über meine frühere Alternative nach, in der jedes Objekt den Hintergrund sichert, den es überdeckt. Das ist allerdings sehr ineffektiv, da ich so wieder Überdeckungsprüfungen machen muss (mit Hashing kann man das zwar beschleunigen, ist aber dennoch aufwendig und man muss auch viel blitten)! Frage mich, wie es z.B. bei MegaLoMania gemacht wurde. Dort liegen die Grafiken direkt in ner Datei vor, die werden doch bestimmt auch nur geblittet. Wird dort auch alles immer neu erstellt? Lief ziemlich flüssig aufm A500! [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 10:19 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich gehe mal davon aus, dass eine permanente BitMap in Komplettgröße in den meisten Fällen am effizientesten ist. Vielleicht lohnt es sich an dieser Stelle, sich doch mal das Verhalten der selten genutzen SuperBitmap-Refresh Fenster anzuschauen. Möglicherweise liefern sie schon das gewünschte frei Haus. Zitat:Ob der Hintergrund grau oder eine Umgebungsgrafik ist, spielt eigentlich keine Rolle. Der Unterschied wäre ja nur, dass es nicht mehr grau aufblitzt, sondern die Umgebungsgrafik durchblitzt, wenn man die Bereiche nicht trennt. Zitat:Wie bereits gesagt, alles neu zeichnen plus double-buffering, ohne mit dem System zu interagieren, ist der am häufigsten anzutreffende Algorithmus. Flüssig ist übrigens eher das Gegenteil von Ruckeln. Ob dabei etwas aufblitzt oder nicht, ist eine andere Frage. Oder ruckelt Deine Grafik? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 11:49 Uhr Thore Posts: 2266 Nutzer |
> Ich gehe mal davon aus, dass eine permanente BitMap in Komplettgröße in den meisten Fällen am effizientesten ist. Ist korrekt, wobei Effizienz sich hier wohl auf Performanz bezieht. Allerdings verbrauchts mehr Speicher. Hier musst du abwägen: Mehr Speicherverbrauch und performanter, oder weniger performant und dafür weniger Speicherverbrauch. Ich tendiere auch eher zu einer großen BitMap. > Zitat:Der Vorschlag, den immer verdeckten Bereich nicht zu erasen würde z.T. helfen. Wenn ich um mein Spielfeld irgendwie ne "Hintergrund-" bzw. "Umgebungsgrafik" hinbekäme wäre das Problem komplett gelöst. Eigentlich nicht weil die Figur dann auf dem Hintergrund "blinken" würde. > Zitat:Frage mich, wie es z.B. bei MegaLoMania gemacht wurde. Dort liegen die Grafiken direkt in ner Datei vor, die werden doch bestimmt auch nur geblittet. Wird dort auch alles immer neu erstellt? Lief ziemlich flüssig aufm A500! Blitter von Agnus (Bereichskopieren) mit DoubleBuffer. Die Grafiken liegen nach dem Laden als Bild im Speicher, daraus wird dann geblittet. Oft wird bei Spielen der komplette Bildschirm getauscht, um sich die Berechnung der damage Regionen zu sparen. [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 19:29 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nun ja, es kann immer passieren, dass für einen Refreshvorgang die gesamte BitMap benötigt wird. Ein in dieser Hinsicht schwankender Speicherverbrauch bietet keinen wirklich Vorteil, es sei denn, man will wirklich riskieren, dass mittendrin nicht mehr genug Speicher frei ist. Dann kann man zwar immer noch auf die flackernde Variante zurückfallen, aber ein Spielvergnügen wird das dann nicht. Dann lieber eine konsequente Mindestanforderung definieren, bei der das Spiel dann aber auch wirklich läuft. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 20:09 Uhr Thore Posts: 2266 Nutzer |
Genau, das meinte ich auch vorhin mit "ich tendiere zur großen Bitmap" also eine gesamte zweite Bitmap und kein partielles DB. In der Regel haben Rechner mit mehr Speicher auch schnellere Prozessoren. Megalomania hat ein 320x200 Bildschirm und 16 Farben (4 Bitplanes) Das macht 32000 Bytes pro Bild. Also nur 31,35KB mehr Speicher. Das ist für einen 1 MB Amiga schon nichts. Befindet er sich dann auch noch im ChipRAM geht das Blitten dank Agnus sehr schnell. Für einen 1024x786x16 Screen sind es 1572 KB = 1,535 MB Speicherverbrauch für den Doublebuffer Screen. Für Systeme ab 16 MB absolut kein Thema. [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 23:20 Uhr Reth Posts: 1858 Nutzer |
Danke für eure Hinweise. Das mit der Hintergrundgrafik würde schon helfen, da die Objekte, die ihre Position ändern sich auch in ihrer Darstellung (Form, Größe, ...) ändern. Da ich meine Schichten von unten nach oben alle neu blitte könnte ich bei einem Hintergrundbild mit Clipping auf das EraseRect verzichten und hätte kein Blinken mehr, denn alle Grafiken im geclippten Bereich werden ja eh neu geblittet! Zudem sähe das Spiel auch besser aus. Hatte zu dem Thema Hintergrundgrafik auch schon mal nen eigenen Thread gestartet. Noch mal die Frage nach dem Doublebuffering: Nach dem bisher Gesagten ist das wohl nicht nur ne OffScreenBitMap, in die man blittet, um aus dieser BitMap in die sichtbare BitMap zu blitten. Oder liegt da noch mehr dahinter, bzw. gibt es weitere Alternativen (einfachere, oder performantere im Hinblick auf Geschwindigkeit)? [ - Antworten - Zitieren - Direktlink - ] |
|
02.08.2011, 23:50 Uhr Thore Posts: 2266 Nutzer |
> Nach dem bisher Gesagten ist das wohl nicht nur ne OffScreenBitMap, in die man blittet, um aus dieser BitMap in die sichtbare BitMap zu blitten. Oder liegt da noch mehr dahinter, bzw. gibt es weitere Alternativen (einfachere, oder performantere im Hinblick auf Geschwindigkeit)? Es gibt verschiedene Ansätze. Grundsätzlich gilt aber immer "zeichne im nicht-sichtbaren Bereich deine Szene und mach sie sichtbar. Wiederhole diesen Vorgang". Für Intuition gibts z.B. diese 3 Möglichkeiten. 1. Screenswapping: Du hast 2 Screens, zeichnest auf dem hinteren und holst ihn dann nach vorne. Gut für Animationen, schlecht wenn man im Screen Dinge abfragt und Menu verwendet. 2. Screen-Bitmap tauschen: Du hast 1 Screen und 2 Bitmaps. Du zeichnest auf der "losen" BitMap und hängst sie in den Screen ein. Damit tauschst du immer die Bitmaps aus. Ggf muss der Screen durch ein RethinkDisplay neu gezeichnet werden. 3. BitMap Copy: Du hast einen Screen mit BitMap und eine ZeichenflächenBitMap. Auf dieser losen zeichnest Du und blittest diese immer komplett auf die Screen Bitmap. Nachteil: Nochmaliger Speicherverbrauch weil das Bild in 2 Bitmaps + RAM Buffer gehalten werden muss. Ebenso ist Blitten zeitaufwendiger als Pointer verbiegen (Ein Pointer sind in der Regel 4 Bytes) (Gilt ebenso für Intuition Windows...) Es gibt noch weitere ohne Intuition Screens und sicher noch mehr, das sind nur mal 3 Beispiele. Ich tendiere bei Intuition hier bei interaktiven Spielen zu Methode 2. [ Dieser Beitrag wurde von Thore am 02.08.2011 um 23:56 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
03.08.2011, 01:09 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wie bereits geschrieben, spielt es doch überhaupt keine Rolle, ob Du ein Hintergrundbild oder einen grauen Bereich blittest. Entweder Du bist schnell genug und der Hintergrund (egal ob Bild oder grau) ist wieder verdeckt, bevor der Benutzer es bemerkt, oder Du bist zu langsam und es flackert. Wenn es flackert hilft nur a) beschleunigen oder b) offscreen BitMap resp. double-buffering. Zitat:Auch das habe ich bereits geschrieben. Im selben Beitrag. Zitat: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. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
03.08.2011, 08:38 Uhr Thore Posts: 2266 Nutzer |
> 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. Das ist auch das gleiche Prinzip wie bei den ASM Demos die DB benutzen, nur da hier kein Intuition Screen verwendet wird sondern ein ViewPort installiert wird. Der sichtbare Ausschnitt wird dann immer hin und her gewechselt. Es gibt viele Methoden, sie sollte dann am Ende effizient genug sein, und möglichst kompatibel zu allen. [ - Antworten - Zitieren - Direktlink - ] |
|
03.08.2011, 22:23 Uhr Reth Posts: 1858 Nutzer |
Zitat:Meinst Du den Teil hier: Zitat:Oder frühere Posts? Mir gings speziell ums Doublebuffering. Zitat:Hatte mich schon gefragt, ob das so gut ist, wenn man nem Window einfach den Zeiger auf die BitMap permanent umbiegt! Zu Deinem Vorschlag für den doppelt hohen Screen: Geht das denn auch, wenn man Autoscroll-Screens verwendet (wie in meinem Fall)? Oder scrollen diese dann den anderen Bereich in den sichtbaren Teil? Oder kann ich die doppelte Höhe unabhängig von der Auflösung angeben? Wie steht es denn mit sowas hier? Ist das denn nicht auch ne systemkonforme Möglichkeit und geht das genau so mit nem Window auf dem Screen (was ich derzeit benutze, um mit Gadgets, genauer Buttons arbeiten zu können)? Für diesen Fall ist wohl SuperBitMapWindow keine schlechte Idee! Muss mir aber erst einmal dieses Beispiel genauer ansehen, und verstehen, wie es genau funktioniert (ne Idee hab ich schon) und welche Teile für mich davon relevant sind! [ Dieser Beitrag wurde von Reth am 03.08.2011 um 23:31 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
04.08.2011, 13:42 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nein, ich meinte, schau Dir mal SuperBitMap-Refresh an. Das ist letztendlich ein Art von Double-Buffering, nur weiß ich nicht, ob sie für Deine Zwecke brauchbar ist. (Diese Methode wird halt selten benutzt). Zitat:Das ist doch exakt die von Thore beschriebene Holzhammer-Methode. Wie gesagt, seit AOS3.0 gibt es bessere Methoden. RethinkDisplay berechnet übrigens die Strukturen aller Screens neu und ist somit nur bedingt als systemkonform zu bezeichnen. Zitat:Nein, double-buffering verträgt sich überhaupt nicht mit Fenstern, Gadgets und vielen anderen System-Features. Zitat:Ich kann nur noch mal davor warnen, zu sehr an den veralteten RKRM-Beispielen zu kleben. Abgesehen davon, dass sie eben vor AOS3.0 oder teilweise auch vor 2.0 entstanden sind, habe ich erst letztens Beispielprogramme in den Fingern gehabt (im Zusammenhang mit diesem Thread übrigens), die schlichtweg deshalb broken waren, weil sie offenbar aus einer gedruckten Fassung eingescannt wurden und dabei ein paar Zeichen falsch waren oder verloren gingen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
04.08.2011, 16:14 Uhr Reth Posts: 1858 Nutzer |
@Holger: Danke für den Hinweis! Das zweite Bsp., das ich angeführt hatte bezieht sich auf SuperBitMaps (so wie von Dir schon angesprochen)! Mein bisheriges Verständnis davon ist, dass dort die BitMap größer sein kann als das Fenster (also ich würde in meinem Fall einfach doppelte Höhe nehmen). Dann wird der sichtbare Teil der BitMap immer im Fenster dargestellt, im restlichen Teil kann man dann die Aktualisierung vorbereiten, anschließend kann man den sichtbaren Teil in einem Rutsch aktualisieren. Das Bsp. sollte zeigen, wie das funktioniert und man somit eine Doublebuffering-Methode mit Fenster hinbekommt! Wie gesagt, muss ich mir erst näher ansehen! Ein Update noch in eigener Sache: Habe gestern noch etwas optimiert und so das Flackern wegbekommen (EraseRect wird nun nur noch in den Bounds der ClippingRegion durchgeführt - sobald diese aber wieder groß genug ist wird das Problem natürlich wieder auftauchen!). Also kein wirklicher Durchbruch. Nächster Versuch wird wohl das SuperBitMap-Window! Allerdings muss ich dessen Arbeitsweise erst einmal verstehen! [ - Antworten - Zitieren - Direktlink - ] |
|
05.08.2011, 12:02 Uhr Holger Posts: 8116 Nutzer |
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:Ich dachte, das wäre sowieso der Fall? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
05.08.2011, 12:39 Uhr Reth Posts: 1858 Nutzer |
[quote] Original von Holger: Zitat:Aber das kann ich doch auch mit nem normalen Fenster ohne SuperBitMap, oder versteh ich da was falsch? Der "Nachteil" dieser Methode ist dann aber ein zusätzlicher Blit im Vgl. zum Umbiegen von Zeigern (wie von Thore auch vorgeschlagen) oder dem Scrollen im SuperBitMap Fenster. Hab mir mal ein Bsp. zum SuperBitMap-Fenster ausm Aminet gesucht, aber noch nicht reingesehen! Zitat:Jetzt schon.  Hatte zuerst die grobe Kelle geschwungen und immer den ganzen Spielbereich gelöscht.[ - Antworten - Zitieren - Direktlink - ] |
|
05.08.2011, 17:25 Uhr Holger Posts: 8116 Nutzer |
Zitat: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:SuperBitMap Fenster sind keine Screens. Dein Scrollen einer SuperBitMap ist nichts anderes, als ein Blit von der SuperBitMap in die Screen-BitMap. Wenn Du Fenster verwendest, kannst Du keine Pointer-Updates oder ähnlich gelagerte Buffer-Techniken einsetzen. Zitat:Aber unter Verwendung der ClipRects? Theoretisch sollte die Größe der sowieso nicht geblitteten Bereiche überhaupt keine Rolle spielen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
05.08.2011, 22:23 Uhr Reth Posts: 1858 Nutzer |
Zitat:Nach dem bisher gelesenen muss man bei SuperBitMap-Fenstern doch immer die BitMap selbst angeben, oder hab ich was übersehen? Von Hand auch bei SmartRefresh? Wird dort nicht auch vom System der "systemeigene Schaden" repariert? Zitat:Heisst das, dass eine BitMap in Fenstergröße reicht und ich dann eine zusätzliche BitMap in Fenstergröße im Speicher halte, in der ich immer das gesamte Bild aufbaue, welches ich dann in einem Blit ins Fenster blitte? Wenn ich das bei nem "normalen" Fenster auch so mache, ist das doch genauso, oder nicht? Zitat:Hm, was würde denn passieren, wenn ich dem Fenster einen Zeiger auf eine andere, von mir angelegte BitMap unterjuble? Zitat:Ja, unter Verwendung der ClipRects! Das hat mich auch gewundert. In meinem hier verlinkten Bsp.-Programm hab ich mal ne Schleife um das Clippen und Blitten gebaut und ein EraseRect auf den ganzen Fensterbereich eingefügt. Das flackert sehr stark. Nach Reduktion des EraseRect auf die Bounds der ClippingRegion ist kein Flackern mehr erkennbar! [ - Antworten - Zitieren - Direktlink - ] |
|
08.08.2011, 00:43 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ich dachte, wenn man keine angibt, erstellt das System eine, aber da habe ich mich wohl geirrt. Zitat:Ja, aber z.B. nicht, wenn das Fenster größer wird. Außerdem ging es ja um den Zusammenhang mit dem Double-Buffering. Smart-Refresh mit einem eigenen Buffer zu kombinieren, wäre Ressourcenverschwendung. Die SuperBitMap als Buffer zu verwenden war eine Idee, aber nach allem, was ich jetzt gelesen und gesehen habe, scheint das doch nicht so brauchbar zu sein. Bleibt nur SimpleRefresh + eigene BitMap. Zitat:Ja, das ist dasselbe. Der wesentliche Unterschied liegt darin, wie das System mit einem Refresh umgeht, vor allem, wenn das Fenster in der Größe geändert werden kann. Zitat:Das geht nicht. Bitte vor lauter kompliziertem Denken nicht die Grundlagen vergessen: alle Fenster liegen auf einem Screen und benutzen eine gemeinsame BitMap, nämlich die des Screens. Zitat:Klingt für mich nach einem Fehler. Welche OS-Version? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
15.08.2011, 00:05 Uhr Reth Posts: 1858 Nutzer |
Hi Holger,Zitat:Dann werd ich das mal probieren (und muss mir wohl doch noch ne BitMap-Klasse schreiben! Hab derzeit "nur" ne RastPort-Wrapper-Klasse nebst den anderen Verdächtigen wie Window, Screen etc. - vielleicht sollte ich auf qt umschwenken von wegen High-Level-API usw)! Macht in diesem Fall Clipping dann auch noch Sinn, v.a., wen mit zunehmender Zeitdauer zu erwarten ist, dass sich viele Regionen an unterschiedlichen Stellen innerhalb der BitMap im Rahmen einer Aktualiesierung ändern? Zitat:Compiliert und getestet unter AOS4.1(beta). [ Dieser Beitrag wurde von Reth am 15.08.2011 um 00:20 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
15.08.2011, 13:30 Uhr Thore Posts: 2266 Nutzer |
> Compiliert und getestet unter AOS4.1(beta). Hast Du die Möglichkeit das unter 3.x oder MorphOS zu compilieren und zu schauen obs hier genauso reagiert? [ - 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. |
|