|
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 - ] |
|
02.01.2011, 20:42 Uhr Reth Posts: 1858 Nutzer |
Hallo zusammen und ein gutes Neues Jahr wünsche ich! Da ich den Thread hier nicht aufwärmen wollte, weil die neue Frage nicht direkt was damit zu tun hat kommt hier ein neuer Thread. Aktuell funktionieren die Überdeckungen und das entsprechende Neuzeichnen bei mir, wie ich es mir vorgestellt hatte - bis auf ein Problem (das hätte ich bei noch reiflicherer Überlegung auch schon vorher erkennen können): Mein Spielfeld bestehend aus Hextiles wird mittels Maske direkt auf den grauen Hintergrund geblittet. Dieser befindet sich allerdings in keinem meiner Grafikobjekte, so dass Teile von Objekten, die über den Rand der äußeren Hextiles ragen als Fragmente stehen bleiben, auch wenn sie auf dem Spielfeld verschwunden sind! Das Neuzeichnen auf dem Spielfeld erfolgt durch Ermittlung der "beschädigten" Grafikobjekte (Überdeckungsermittlung innerhalb von Schleifen), dabei bilden einer gemeinsamen Clipregion und anschließendem Neuzeichnen aller so betroffenen Grafikobjekte "von unten nach oben" (bezogen auf die Tiefe innerhalb der Darstellung). Gibt es für dieses Problem denn eine einfache Lösung, oder muss ich nun den Spielfeldrand "aktiv" gestalten (also z.B. in Form von Hintergrundgrafik)? Dank euch schon mal! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2011, 14:12 Uhr AGSzabo Posts: 1663 Nutzer |
@Reth: ausführlich beschrieben aber für mich dennoch nicht ausreichend verständlich. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2011, 14:16 Uhr Thore Posts: 2266 Nutzer |
Ja ich dachte auch erst, du hast beschrieben wie dus machst, dann kam obs ne einfachere Lösung gibt. Du musst bei Bewegungen wo ein Objekt über Nachbar-Hextiles ragen, auch die umliegenden Hextiles refreshen. Screenshots wären hier nicht schlecht, so daß wir sehen wie das Spielfeld auf dem grauen Hintergrund sichtbar ist und wo die Fragmente bestehen bleiben. [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2011, 15:59 Uhr Reth Posts: 1858 Nutzer |
Hallo zusammen, bei diesem Problem geht es nicht um die Nachbar-Hextiles. Diese, sowie alle anderen Objekte, die mit zum Spiel gehören werden korrekt verarbeitet. Was bleibt ist der graue Rand, der das Spielfeld umgibt und der der normale Fensterhintergrund ist. Dieser wird nicht aktualisiert, wenn er mal von einem Spielobjekt überdeckt wurde, das später wieder entfernt wird. Wie kann ich diesen grauen Rand denn möglichst einfach wieder herstellen? Er gehört zu keinem der grafischen Objekte, die ich verwende, daher kann ich ihn nicht einfach wieder "zurück blitten". Wenn es immer noch Verständnisprobleme gibt, mach ich mal ein paar Screenshots und such nen Server im Web, auf dem man die ablegen kann! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2011, 17:16 Uhr Thore Posts: 2266 Nutzer |
Wieso können die Objekte denn überhaupt so weit rauslaufen? Grenzen die Hextiles nicht an diesen Rand? Kannst Du beide Fragen so beantworten, daß das eben so ist, muss der Rand separat refresht werden, oder die Tiles angepasst werden, daß der Rand verdeckt wird. [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2011, 18:54 Uhr Reth Posts: 1858 Nutzer |
@Thore: Naja, weil z.B. Gebäude so stehen können, dass sie seitlich über die Hex-Tiles am Rand hinaus ragen können (isometrisch). Die Hex-Tiles am Rand grenzen natürlich an diesen grauen Rand. Wie kann ich denn den Rand refreshen, wenn er nicht Teil meiner grafischen Objekte ist (ist einfach nur die Hintergrundfarbe)? OT: Kennt jmd. einen guten Bildbereitstellungsdienst im Web und fürs Web, bei dem man seine Bilder ablegen kann? Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
03.01.2011, 19:33 Uhr Thore Posts: 2266 Nutzer |
Photobucket wär sowas Ja zeig mal Screenies, dann wirds anschaulicher. [ - Antworten - Zitieren - Direktlink - ] |
|
04.01.2011, 15:48 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ist das denn gewollt, dass Objekte über den Rand gezeichnet werden? Nach meinem Verständnis ist ein Rand ein Rand und somit etwas, an dem alles abgeschnitten werden soll. Und das sollte kein Problem sein, wenn Du eh eine Clip-Region verwendest. Und wenn Du nicht in den Rand zeichnest, muss Du ihn auch nicht wiederherstellen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
09.01.2011, 12:28 Uhr Reth Posts: 1858 Nutzer |
Zitat: Ja, das ist gewollt (wird auf Screenshots deutlicher). Das mit den Screenshots wird noch ein bisschen dauern, da ich den Code erst wieder lauffähig bekommen muss (hatte schon weiter daran gewerkelt). [ - Antworten - Zitieren - Direktlink - ] |
|
09.01.2011, 13:11 Uhr thomas Posts: 7718 Nutzer |
@Reth: Die Frage ist, was du unter "refreshen" verstehst und warum du den Rand nicht refreshen kannst. Du gibst als Grund nur an, daß er grau ist. Was spricht denn dagegen, den grauen Rand mit grauer Farbe zu füllen, bevor du die darüberragenden Objekte neu zeichnest? -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
09.01.2011, 14:30 Uhr Reth Posts: 1858 Nutzer |
@thomas: Vom genannten Rand habe ich keine Informationen (Größen, wieder zu befüllende Flächen usw.). Er ist das "Überbleibsel" des Fensterhintergrundes. Um diesen nur in den entsprechenden Bereichen wieder mit grauer Farbe zu füllen müsste ich erst einmal feststellen können, ob der Rand überhaupt betroffen war. Schwierig zu erklären, daher wie gesagt, am besten auf Screenshots warten! [ - Antworten - Zitieren - Direktlink - ] |
|
09.01.2011, 15:07 Uhr Thore Posts: 2266 Nutzer |
> müsste ich erst einmal feststellen können, ob der Rand überhaupt betroffen war. Wenn das Refreshen des Randes schnell geht, kannst Du es vor jedem Refresh-Zyklus machen (also bevor Gebäude etc gemalt werden). Mit Double Buffer Technik flackert dann auch nichts. Musst eben schauen wie das vom Speed her ist. Aber ich denk die Berechnung was nun betroffen ist, könnte unter Umständen noch länger dauern als den dicken Rahmen außen jedesmal zu zeichnen. [ - Antworten - Zitieren - Direktlink - ] |
|
05.02.2011, 20:15 Uhr Reth Posts: 1858 Nutzer |
So hier nun endlich die versprochenen Screenshots! Auf dem ersten Bild ist das Spielfeld im Initialzustand zu sehen: Bild: http://amiga.freeunix.net/wizardgrounds/Anderes/WG_Anfang.png Hat man genug Ressourcen und klickt auf den Button mit dem Turm erscheint eine Animation am Mauszeiger. Diese wird später noch auf das Spielfeld begrenzt, aber die gebauten Türme können durchaus über den Spielfeldrand hinaus ragen. Wird solch ein Turm im Spielverlauf zerstört, kann der Rand nicht aktualisiert werden, da er, genau so wie die Bedien- und Statusfelder nicht zu den geblitteten Objekten gehört, die mit im Refresh-Algo stecken! Zu sehen ist das Ganze auf dem 2. Bild. Dort ist das Spielfeld völlig intakt, obwohl ich mehrmals mit dem Cursor und dem animierten Turm darüber gefahren bin. Der Refresh-Algo hat dort prima funktioniert! Bild: http://amiga.freeunix.net/wizardgrounds/Anderes/WG_Spielfeld.png Vielleicht sollte ich zu meinem Ursprungs-Algo zurück kehren! Darin hatte sich jedes Objekt in einer eigenen Bitmap den Hintergrund gemerkt, den es überdeckt hat (mit Ausnahme der Objekte, die "ganz unten" liegen). Dadurch wurde automatisch auch der graue Rand mit "gerettet". Der Fehler dort war nur noch, wenn sich z.B. ein Objekt in der 2. Ebene bewegt hatte, hätten alle darüber liegenden ihren Hintergrund nacheinander erneuern müssen. Das gibt dann noch mehr Blitoperationen! Von der Geschwindigkeit bin ich jetzt schon nicht angetan. Auf nem 060 mit CVPPC war es damals nach einer Weile viel zu lahm! Habt ihr noch nen guten Vorschlag? Auch hinsichtlich Performance, da doch ziemlich viel geblittet wird (wenn auch über alle in einem Zyklus zu machenden Blit-Operationen die gemeinsame ClipRegion ermittelt und gesetzt wird)! [ Dieser Beitrag wurde von Reth am 06.02.2011 um 10:24 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
06.02.2011, 13:08 Uhr inq Posts: 445 Nutzer |
@Reth: wenn ich davon ausgehe, daß deine Maus-Objekte in etwa gleich groß sind, würde ich eher nur EINEN Buffer, und zwar für die Maus-Objekte, einrichten. dann bräuchtest du auch nicht die Hex-tiles neu blitten (außer du hast dafür dann Markings für den Zielpunkt etc. eingebaut). gruß inq [ - Antworten - Zitieren - Direktlink - ] |
|
06.02.2011, 14:35 Uhr Reth Posts: 1858 Nutzer |
@inq: Versteh nicht ganz, was Du genau meinst. Hab aber ne Ahnung. Allerdings sind die Mausobjekte nicht gleich groß. Zusätzlich kann sich im Laufe des Spiels ergeben, dass auf dem Spielfeld noch andere Grafiken/Animationen zu sehen sind, die dann auch von den Objekten am Mauszeiger überdeckt werden können. Dabei laufen aber beide Animationen weiter. [ - Antworten - Zitieren - Direktlink - ] |
|
06.02.2011, 19:46 Uhr Holger Posts: 8116 Nutzer |
@Reth: Mein erster Ratschlag lautet: lass das mit dem "Merken des Hintergrundes" bleiben. Merken des Hintergrundes bedeutet letztendlich einen komplett überflüssigen Transfer von Grafikdaten, schließlich hast Du diesen Hintergrund vorher selbst erzeugt und kannst ihn also auch ohne Bandbreitenverschwendung wiederherstellen. Was daran so schwer sein soll, einen einfarbigen Hintergrund wiederherzustellen, erschließt sich mir immer noch nicht... Und das Objekt am Mauszeiger sollte doch wohl auch kein Problem sein. Wenn es verändert, bewegt oder entfernt werden soll, einfach die Bounding Box des Objekts der Damage-List hinzufügen und einen ganz normalen Refresh-Zyklus starten. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
06.02.2011, 21:11 Uhr Reth Posts: 1858 Nutzer |
Zitat:Das wäre auch meine bevorzugte Variante Zitat:Relativ einfach. Mein Refresh-Algo arbeitet mit den von mir für das Blitten des Spielfeldes und der restlichen dargestellten Objekte genutzten BitMaps (es werden nur Blitoperationen und Clipping verwendet). Die Status- und Bedienfelder gehören nicht dazu, diese werden mit drawimage usw. angezeigt. Der graue Hintergrund ebenfalls nicht, dieser gehört zum Fenster direkt. Den Statusbereich kann ich in den Griff bekommen, den grauen Hintergrund allerdings nicht so einfach. Keine Ahnung, wie ich den in meinen komplett selbst gebauten Algo technisch einbinde!? Zitat:Kannst Du das noch ein bisschen näher erläutern? Nach meinem aktuellen Refresh-Algo ist das Objekt am Mauszeiger über dem Spielfeld auch kein Problem. Es wird pro Refreshzyklus ermittelt, was alles neu gezeichnet werden muss, dies wird dann in eine Clipregion zusammengefasst und von unten nach oben neu geblittet. Daher wird das Objekt am Mauszeiger auch immer wieder hergestellt, ebenso der Bereich, der vor einer Mausbewegung durch das Objekt am Mauszeiger überdeckt war. Das gilt allerdings nicht für den grauen Hintergrund (der wie gesagt nicht als Bitmap vorliegt). [ - Antworten - Zitieren - Direktlink - ] |
|
06.02.2011, 22:36 Uhr inq Posts: 445 Nutzer |
@Reth: Bin zwar nicht Holger, aber: Nur, weil du den "grauen" Bereich nicht ausdrücklich in die Bearbeitung durch deine Engine einschließt, heißt ja nicht, du wüßtest nicht darüber Bescheid. Du hast den Bildschirm (und dessen Speicher/Rastport usw.) und du weißt (intern) ob du den Mauszeiger bewegt hast und noch oder nicht mehr im "grauen" Bereich bist. Der Mauszeiger kann programmintern seinen eigenen Buffer (Bitmap basiert) haben, so wie früher die BOBs auf Classic Systemen. Möglicherweise solltest du deine "alte" Engine auf Verwendbarkeit einiger Codeteile diesbezüglich checken. inq [ - Antworten - Zitieren - Direktlink - ] |
|
06.02.2011, 23:37 Uhr Reth Posts: 1858 Nutzer |
Zitat: Das hieße dann aber doch, den Hintergrund zu sichern, zumindest, wenn man sich über dem grauen Hintergrund befindet. Das müsste dann extra noch abgeprüft werden. Dann wäre es einfacher, ich merke mir ein Stück grauen Hintergrund, groß genug für alle Objekte und nehme dies immer als "Unterstes" in meiner Wiederherstellungsreihenfolge beim Blitten. Dann passts auch. Ist meiner Meinung nach aber auch noch nicht das ganz Gelbe vom Ei! [ - Antworten - Zitieren - Direktlink - ] |
|
07.02.2011, 12:22 Uhr Holger Posts: 8116 Nutzer |
@Reth: Wie zeichnest Du denn Dein Fenster, wenn das System einen Refresh verlangt? Normalerweise läuft das doch so ab: Jetzt ist es nicht schwer, exakt dasselbe für eigene Bedürfnisse zu tun. Wenn Dir das zu kompliziert ist, kannst Du auch einfach das Mausobjekt in ein eigenes (Pseudo)transparentes Fenster packen. Du musst nur daran denken, wenn Du keine echte Transparenz, sondern den No-Op Backfill-Hook Trick benutzt, dass man das Fenster nicht verschieben, sondern nur schließen und an neuer Position wieder öffnen darf. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
07.02.2011, 17:55 Uhr Reth Posts: 1858 Nutzer |
Zitat: Derzeit läuft es so, dass ich auf INTUITICKS reagiere und nach jedem Eintreffen eines solchen meinen Refresh-Algo laufen lasse. In diesem werden alle notwendigen Aktualisierungen meiner Objekte (mit eigener Bitmap) durchgeführt. Der Fensterhintergrund gehört dazu allerdings nicht! Zitat: Derzeit arbeite ich ohne Layer und dessen Damagelist. Nutze nur Clipping und Blitting. Wenn ich Dich richtig verstehe, dann mache ich alles wie bisher (d.h. ermitteln aller zu aktualisierenden Objekte, bestimmen der gemeinsamen Clipping-Region, Blitten dieser Objekte von unten nach oben), dazu gebe ich aber noch der Damagelist des Layers meines aktuellen Fensters mit, welche Bereiche sich ändern. Wäre es hier nicht sinnvoll dem Layer gleich die gesamte ermittelte Clipping-Region als beschädigt mit zu geben? Wir denn dafür gesorgt, dass sich der Hintergrund des Layers vor meinen eigenen Blits aktualisiert? Und wird der Statusbereich rechts dann auch verschont? [ Dieser Beitrag wurde von Reth am 07.02.2011 um 18:55 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
07.02.2011, 18:41 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das war jetzt keine Antwort auf meine Frage. Gefragt hatte ich, ob, bzw. wie Du auf Refresh-Anforderungen des Systems reagierst. Deine Gadgets und Dein Hintergrund werden ja schließlich auch irgendwann gezeichnet. Zitat:Musst Du dann machen, da ja BeginRefresh die Damage-Liste in die aktuelle ClipRegion umwandelt. Zitat:Ich glaube, das passiert nicht automatisch, wenn der Refresh nicht von Intuition getriggert wird. Allerdings kannst Du einfach EraseRect aufrufen, das benutzt den Backfill-Hook und respektiert die von BeginRefresh gesetzte ClipRegion. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
07.02.2011, 20:07 Uhr Reth Posts: 1858 Nutzer |
Zitat:Gar nicht. Hab das Fenster mit WFLG_NOCAREREFREH versorgt und kümmere mich nicht um Refreshzyklen, werte auch die entsprechenden Intuition-Messages nicht aus! Wie gesagt agiere derzeit nur beim Eintreffen von INTUITICKS und Mouse-Messages. Dann läuft meine Aktualisierung (nur Hintergrund und andere Bildobjekte. Bei den Gadget mach ich nichts). Zitat:Kann ich denn das Ganze mit meinem jetzigen Ansatz kombinieren, sprich reicht es bei den Refresh-Messages des Systems BeginRefresh zu rufen, die ClipRegion wie bisher zu ermitteln, das Rechteck dazu mit EraseRect zu löschen, dann meine ganzen Blits zu machen, dann EndRefresh zu rufen? Oder muss ich mich dann zusätzlich um die Aktualisierung meiner Gadgets kümmern? [ - Antworten - Zitieren - Direktlink - ] |
|
08.02.2011, 10:23 Uhr Holger Posts: 8116 Nutzer |
@Reth: Was für ein Gadget-Toolkit benutzt Du denn? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
08.02.2011, 11:56 Uhr Reth Posts: 1858 Nutzer |
@Holger: Gar keines nutze struct Gadget, baue mir damit meine Bild-Buttons und positioniere sie absolut in dem von mir erzeugten Fenster. Und noch eine konkrete Frage: Wenn ich NOCAREREFRESH nicht nutze, hab ich dann den Teil von Dir Zitat:wie folgt richtig verstanden?
Kommt das ungefähr hin? Allerdings frage ich mich, wie performant das ist. Wenn man sich mal das Spielfeld ansieht und sich ein paar animierte Gebäude an verschiedenen Stellen vorstellt, wird die Clipping-Region doch fast immer so groß wie das ganze Spielfeld sein, oder? Zudem hab ich noch nicht verstanden, wie bei diesem Vorgehen der graue Hintergrund wieder hergestellt werden soll? [ Dieser Beitrag wurde von Reth am 09.02.2011 um 17:46 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
11.02.2011, 13:22 Uhr Holger Posts: 8116 Nutzer |
Zitat:Eine Region ist nicht das umschließende Rechteck, sondern eine Liste von Rechtecken. Das können also auch mehrere kleine sein. Zitat:Der ursprüngliche Gedanke war, für den Refresh eben exakt den Prozess zu durchlaufen, der immer für den Refresh des gesamten Fensters durchlaufen wird, die Clip-Regionen sagen ja, was dann tatsächlich gezeichnet werden soll. Dabei ist jetzt allerdings das Problem aufgetaucht, dass im Normalfall Intuition den Hintergrund und die Gadgets schon aktualisiert, bevor die Anwendung ihre Refresh-Message bekommt, und die Dokumentation sagt, dass man RefreshGadgets nach BeginRefresh nicht aufrufen darf (wobei ich nicht verstehen, warum). Über die Frage, wie man nun systemkonform einen kompletten Refresh erzwingen kann, denke ich gerade noch nach. Was auf jeden Fall funktioniert, ist eine SystemFunktion aufzurufen, die als Nebeneffekt einen Refresh nötig macht, aber das erscheint mir nicht so elegant. Man kann aber auch, wenn die Gadgets eh nur aus einer Handvoll Bilder besteht, den Prozess komplett selbst nachvollziehen, nach BeginRefresh einfach EraseRect für den gesamten inneren Fensterbereich aufrufen, danach alle Gadget-Bilder in den RastPort blitten, dann das Spielfeld zeichnen. Das Clipping sorgt dafür, dass das ganz nicht so teuer wird, wie es zuerst klingt. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
11.02.2011, 13:29 Uhr Holger Posts: 8116 Nutzer |
Der Vollständigkeit halber:Zitat:Nein. Im Idealfall:
-- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
11.02.2011, 23:42 Uhr Reth Posts: 1858 Nutzer |
@Holger: Ein paar Fragen noch dazu: Zitat:Hier ist meine eigene Damagelist gemeint, nicht die des Fensters oder? Und muss ich dazu beim Fenster das NOCAREREFRESH ausschalten? Was ich mich frage, wieso zeichnet Intuition in der derzeitigen Konstellation den Hintergrund nicht neu? Wenn ich die graue Fläche mal "überblittet" habe, dann bleibts auch so. Liegt das am NOCAREREFRESH? Wie gesagt stellt der Bereich rechts mit den Statusinformationen und den Buttons kein Problem dar. Den kann ich auch "schützen", in dem ich die animierten Mauszeiger in diesem Bereich abschalte. [ Dieser Beitrag wurde von Reth am 13.02.2011 um 14:37 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.02.2011, 14:45 Uhr Reth Posts: 1858 Nutzer |
Hab mir jetzt mal alles hier zu OpenWindow durchgelesen. Mir ist aber nicht ganz klar, was ich tun kann, um den Hintergrund wieder her zu stellen, ohne ihn vorher irgendwie zu sichern. Der einzige Punkt, der mir etwas in die Richtung zu gehen scheint ist das Thema mit dem BackfillHook. Allerdings verstehe ich das Vorgehen und die Interna von Intuition da kaum noch. Ich hab keine Ahnung, ob ich einen Backfill Hook brauche (habe derzeit keinen) oder ob Intuition den grauen Hintergrund um mein Spielfeld und um meine Status-/Bedienfelder selbst wieder herstellt? Was würde denn passieren, wenn ich EraseRect aufrufen würde, ohne dass ich einen BackfillHook habe? Zum Thema Backfill-Hook bin ich im Amiga Intern und Profi Know How auch nicht schlauer geworden (sprich wozu genau man ihn einsetzen kann, hab hier nur ne ungefähre Vorstellung!)! Und mache ich den Aufruf für meine ganze ClippingRegion, die ich mir durch meinen Überdeckungsalgo habe ermittlen lassen? Also die ganzen Beschreibungen auf innoidea helfen schon, aber ne Lösung hab ich noch nicht. Muss ich meinem Fenster noch Simple- oder Smart-Refresh mitgeben? 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? Fragen über Fragen. Muss wohl auch nochmal im Amiga Intern und im Profi KnowHow nachschlagen. [ Dieser Beitrag wurde von Reth am 13.02.2011 um 22:49 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.02.2011, 11:09 Uhr Holger Posts: 8116 Nutzer |
Zitat:Doch, die des Fensters. Der Sinn ist doch, den Refresh zu vereinheitlichen. Zitat:Wenn Du Refresh-Meldungen erhalten willst, musst Du das Ausschalten. Schließlich besagt dieses Flag ja, dass Du keine haben willst. Zitat: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. Zitat: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 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. Zitat:SimpleRefresh, nichts anderes. Zitat:Brauchst Du nicht. -- Good coders do not comment. What was hard to write should be hard to read too. [ - 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. |
|
