Hallo!

Ich hab ein interessantes Phänomen entdeckt im Zusammenhang mit
ScrollVPOrt() und WritePixelArray8() und kann es mir nicht wirklich
erklären. Vielleicht kann mir hier jemand sagen, was da passiert?

Also:

Ganz normale Schleife zum Zeichnen des in einem Puffer vorbereiteten Bilds:


void swapscreens(void)
{
WritePixelArray8(&gb_screen->RastPort, 0, (ULONG)gb_screennr * gb_resy, (ULONG)gb_resx -1,
(ULONG)gb_screennr * gb_resy + gb_resy -1, (UBYTE *)gb_chunkybuffer,
&gb_wpa8rastport);
gb_screen->ViewPort.RasInfo->RyOffset = gb_screennr * gb_resy;
WaitTOF();
ScrollVPort(&gb_screen->ViewPort);
}

gb_screennr wird extern zwischen 1 und 0 getoggelt. Normalerweise sollte
diese Art des Doublebufering ja seinen Dienst tun und ein ruhiges
flackerfreies Bild gewährleisten, in dem man bei bewegten Objekten
keine "Geisterbilder" oder "Schatten" der Bewegung sieht.

Leider ists nicht ganz so einfach, denn ausgerechnet mit dieser Methode
bekomme ich bei meinen Software-Sprites Geisterbilder zu sehen, also
das Bild _vor_ der aktuellen Bewegung erscheint noch teilweise im
sichtbaren Bereich.

Nun hab ich ein bißchen rumprobiert, um zu ergründen, warum es nicht
so geht, wie es soll und hab dabei entdeckt, daß ich _ohne_ ScrollVPort()
auf GraKa ein absolut ruhiges Bild _ohne_ Geisterbilder bekomme.

Bin zugegebenermaßen jetzt etwas verwirrt, vor allem, weil die Doku
zu WritePixelArray8() äußerst spärlich ist. Gibts da u.U. Seiteneffekte?

Kann einer von Euch erklären, was hier verkehrt läuft? Wäre für _jede_
Hilfe dankbar.

Grüße


whose

P.S.: Bitte, keine Hinweise auf das Problem der Busgeschwindigkeit zur
GraKa, die ist nämlich _nicht_ das Problem, da die Geisterbilder auch
auf Amithlon und WinUAE auftauchen, die mit Sicherheit genug Bandbreite
zur GraKa bieten

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:

code:

---

gb_screen->ViewPort.RasInfo->RyOffset = gb_screennr * gb_resy;
    WaitTOF();
    ScrollVPort(&gb_screen->ViewPort);

---

---

code:

---

WaitBOVP(&gb_screen->ViewPort);
  gb_screen->ViewPort.RasInfo->RyOffset = gb_screennr * gb_resy;
  ScrollVPort(&gb_screen->ViewPort);

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Hallo Holger!

Danke für die Erläuterungen, sie waren sehr hilfreich. ScrollVPort() scheint doch nicht die wahre Lösung zu sein

Naja, die Spur, die das Softsprite hinter sich herzieht, wird zwar dank Deiner Tips deutlich kürzer, verschwindet aber leider nicht.

Hab noch ein wenig weiter experimentiert und in ScrollRast eine deutlich schnellere Alternative gefunden. Dummerweise flackert das Bild jetzt dafür Scheint also, als gäbe es für GraKa nur noch die Lösung, daß ich auf WritePixelArray8() verzichte und direkt ins VRAM schreibe. Wenn ich die Ergebnisse meiner Experimente korrekt deute, ist WritePixelArray8() einen Hauch zu langsam um syncron mit dem Bildaufbau bleiben zu können

Danke Dir ganz gehörig!

Grüße

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Hallo Thilo!

Ja, Du hattest mir die Sourcen der älteren AsteroidsTR-Version mal geschickt, erinnerst Dich?

Normalerweise würde ich das auch exakt so machen, wie Du es beschrieben hast, aber ging mir ja gerade darum, vollständig _ohne_ Blitter zu arbeiten, um die Funktionsweise bewegter Grafik besser darstellen zu können. Doof war und ist halt nur, daß sich die Grafik so schwer synchronisieren läßt auf GraKa.

Ich brauche keine Wahnsinns-Frameraten dafür, aber ruhig sollte das Bild schon sein, wenn möglich. Mal sehen, wie weit ich mit ScrollRast und direktem Zugriff aufs VRAM komme. Blöderweise scheint WaitTOF() auf GraKa in nahezu allen Fällen einfach durchzurauschen, das machts ziemlich schwierig. WaitBOVP() scheint zwar zu wirken, ist wohl aber auch nicht wirklich synchron zum Rasterstrahl, oder täusche ich mich da?

Aber trotzdem danke für die Tips, immerhin bin ich dadurch schon mal einige Schritte weiter als vorher

Grüße


Wolfgang

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]