kleine Probleme mit Retrace und VGA unter Pascal

Diskussion zum Thema Programmierung unter DOS (Intel x86)
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von wobo »

Ich habe aktuell ein paar kleinere Probleme mit dem Setzen der Bildschirmadresse und der Synchronisation mit dem Strahlenrücklauf (VRetrace):

Ausgangspunkt ist, dass ich das bekannte Doublepaging betreibe, also 2 Bildschirmseiten im ständigen Wechsel anzeige: Es wird immer die bereits fertig aufgebaute Seite angezeigt, während die andere gerade bearbeitet wird.


1. Problem: DisplayAdress und VRetrace

Die DisplayAdress der VGA setze ich, indem ich den Registern $C und $D des CRT-Controllers den high- und low- Anteil der Strtadresse meiner Bildschirmseite übergebe. Im Anschluss hieran warte ich noch darauf, dass bit3 des Input-Status-Registers ($3DA) auf 1 gesetzt ist, also der Strahlenrücklauf stattfindet. Ansonsten nämlich könnte die Situation eintreten, dass ich eine immer noch angezeigte Bildschirmseite bearbeite, weil mangels Strahlenrücklauf die VGA die neue DisplayAdress noch nicht aktualisiert hat.

Der Pascal-Code:

PortW[$3D4] := hi( pageAdr ) shl 8 + $C;
PortW[$3D4] := lo( pageAdr ) shl 8 + $D;
Repeat Until (port[$3DA] and 8) = 8;

Das klappt auch meistens recht gut. Nur hin und wieder wird - für eine einzige Frame - ein komplett falscher Bildschirmausschnitt angezeigt.

Ich kann mir das nur so erklären, dass ich gerade den High-Anteil der neuen Bildschirmadresse an die VGA gesendet habe und zufällig gerade ein VRetrace abgeschlossen wird. Angezeigt wird dann ein Bildschirmausschnitt, der dem Highanteil der neuen und dem Lowanteil der alten Adresse entspricht.

Die Systemliteratur empfiehlt daher noch abzufragen, dass gerade kein VRetrace stattfindet (bit3=0), damit genügend Zeit bleibt, die Bildschirmadresse komplett zu setzen. Allerdings verortet meine Systemliteratur (Zeitschriften, PC-Intern 3.0, u.a.) diese Abfrage nach dem Setzen der DisplayAdress:


Der Pascal-Code (Literatur):

PortW[$3D4] := hi( pageAdr ) shl 8 + $C;
PortW[$3D4] := lo( pageAdr ) shl 8 + $D;
Repeat Until (port[$3DA] and 8) <> 8;
Repeat Until (port[$3DA] and 8) = 8;


Ich halte dieses Vorgehen für unlogisch, weil die oben beschriebene Situation ja genauso auftreten kann. Auch in der Praxis habe ich den oben beschriebenen Effekt genauso oft!

Ich frage daher ab, ob gerade kein VRetrace stattfindet, bevor ich die DisplayAdresse setze:

Repeat Until (port[$3DA] and 8) <> 8;
PortW[$3D4] := hi( pageAdr ) shl 8 + $C;
PortW[$3D4] := lo( pageAdr ) shl 8 + $D;
Repeat Until (port[$3DA] and 8) = 8;

Jetzt müßte eigentlich sichergestellt sein, dass immer genügend Zeit bleibt, beide Register der DisplayAdress zu setzen, bis der nächste VRetrace beendet ist.

In der Praxis sieht es auch viel besser aus: Der oben beschriebene Effekt tritt sehr viel seltener auf. Hin und wieder aber dann doch: die einzige Erklärung, die ich hierfür habe, ist, dass ein Interrupt auftritt und deswegen doch wieder nicht genug Zeit ist, beide Register bis zum nächsten VRetrace zu setzen.

Einzig das Sperren der Interrupts bringt dauerhafte Abhilfe:

inline($FA);
Repeat Until (port[$3DA] and 8) <> 8;
PortW[$3D4] := hi( pageAdr ) shl 8 + $C;
PortW[$3D4] := lo( pageAdr ) shl 8 + $D;
Repeat Until (port[$3DA] and 8) = 8;
inline($FB);

Auch wenn ich meine Game-Engine (Euphemismus!) stundenlang laufenlasse, gibt es keine Störungen.

Allerdings bin ich mit der Lösung nicht ganz zufrieden. Meine "Soundengine" (Euphemismus!) hat nämlich etwas dagegen, wenn allzu lange die Interrupts gesperrt sind.



2. Problem: Funkt. $83, Int $15

Auf meinem 386sx16 bin ich eigentlich recht froh, wenn ich es schaffe, den Screen jeden 2. oder 3. VRetrace zu "updaten". Ich habe dann eine effektive Framerate von 23 bzw. 35 Hz, die auch durchgehalten werden soll, wenn der Rechner das ganze ohne weiteres in 70 Hz erledigen könnte.

Bisher habe ich das immer so gemacht, dass ich über die Funktion $83 des Int $15 eine globale Variable setzen lasse, sobald eine bestimmte Anzahl an Microsekunden vorübergegangen ist.

Für eine konstante Framerate von 23 Hz mache ich es beispielsweise so:

Var timeflag : word;
regs : registers;
begin
timeflag := 1;
....

Repeat Until timeflag <> 0;
inline($FA);
Repeat Until (port[$3DA] and 8) <> 8;
PortW[$3D4] := hi( pageAdr ) shl 8 + $C;
PortW[$3D4] := lo( pageAdr ) shl 8 + $D;
Repeat Until (port[$3DA] and 8) = 8;
inline($FB);
timeflag := 0;
regs.ax := $8300;
regs.bx := Ofs(timeflag);
regs.cx := 0;
regs.dx := 30000;
regs.es := Seg(timeflag);
intr($15, regs);

Anm.: in cx kommt das hiWord, in dx das Loword der Zeitdauer in Microsekunden. Da ein Retrace alle 1/70 sec (=0.0142857sec) stattfindet, dauern 2 Retraces 1/35 sec (=0.0285714 sec). Nach 0.0300000 sec sollte also sichergestellt sein, dass gerade 2 Retraces vergangen sind und ich mit 23 Hz arbeiten kann, egal wie schnell der PC ist.

Das klappt unter nativem Dos (MS-Dos 6.20, MS-Dos 5.0) auf allen Dos-PCs (386sx16, 486sx25, p75) ohne Probleme. Starte ich das Dos-Programm dagegen unter Win2k wird das Timeflag niemals gesetzt. Liegt das an Win2k (dann Off-Topic) oder ist meine Routine fehlerhaft?

grüsse!
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von freecrac »

wobo hat geschrieben:Ich habe aktuell ein paar kleinere Probleme mit dem Setzen der Bildschirmadresse und der Synchronisation mit dem Strahlenrücklauf (VRetrace):

Ausgangspunkt ist, dass ich das bekannte Doublepaging betreibe, also 2 Bildschirmseiten im ständigen Wechsel anzeige: Es wird immer die bereits fertig aufgebaute Seite angezeigt, während die andere gerade bearbeitet wird.


1. Problem: DisplayAdress und VRetrace
Ich kenne es so:
Zuerst wartet man darauf das kein Retrace erfolgt und wartet unmittelbar danach darauf das ein Retrace erfolgt. So wird sichergestellt das wir nicht irgendwann während des Retrace abfragen, sondern den Beginn des Retrace abfangen.
Unmittelbar danach sollte der Bildwechsel erfolgen. Das würde dann in etwa so ausschauen:

Repeat Until (port[$3DA] and 8) <> 8;
Repeat Until (port[$3DA] and 8) = 8;
inline($FA);
PortW[$3D4] := hi( pageAdr ) shl 8 + $C;
PortW[$3D4] := lo( pageAdr ) shl 8 + $D;
inline($FB);

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von wobo »

@freecrac: [3* editierter Beitrag, wobo]

Klingt eigentlich logisch. Bei Deiner Lösung wird auf den Beginn des Retraces gewartet, und im unmittelbaren Anschluss die Display-Adresse gesetzt. Das müßte ausreichen, weil die VGA meines Wissens die neue DisplayAdr mit Beendigung des Retraces aktualisiert. Auch ein langsamer PC müßte das Setzen der beiden DisplayAdr.-Register innerhalb eines VRetraces hinbekommen.

Allerdings funktioniert bei mir Deine Lösung überhaupt nicht. Deine Methode flimmert bei mir (386sx16 mit wd90c11, 386dx25 mit cl5402) komplett und ununterbrochen. Es ist ein klassisches Flimmern. Dies gilt auch, wenn ich Deine Methode in Assembler umsetze.

Ich habe Deine Methode jetzt noch auf einem 486dx-local-bus getestet. Auch dort funktioniert sie nicht. Es flimmert zwar nicht, aber die ersten 30 Zeilen werden nicht korrekt angezeigt. Das heißt für mich, die alten PCs sind einfach zu langsam, um die Display-Register innerhalb eines Retraces zu setzen.

Das einzige, was bei mir ohne jegliches Flimmern und Flackern funktioniert, ist die von mir zuletzt gepostete Routine unter Problem 1, und zwar unbhängig davon, ob ich sie in pascal oder asm umsetze.

Ich werde sie vorerst beibehalten.

Grüsse wobo
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von freecrac »

wobo hat geschrieben:@freecrac: [3* editierter Beitrag, wobo]

Klingt eigentlich logisch. Bei Deiner Lösung wird auf den Beginn des Retraces gewartet, und im unmittelbaren Anschluss die Display-Adresse gesetzt. Das müßte ausreichen, weil die VGA meines Wissens die neue DisplayAdr mit Beendigung des Retraces aktualisiert. Auch ein langsamer PC müßte das Setzen der beiden DisplayAdr.-Register innerhalb eines VRetraces hinbekommen.

Allerdings funktioniert bei mir Deine Lösung überhaupt nicht. Deine Methode flimmert bei mir (386sx16 mit wd90c11, 386dx25 mit cl5402) komplett und ununterbrochen. Es ist ein klassisches Flimmern. Dies gilt auch, wenn ich Deine Methode in Assembler umsetze.

Ich habe Deine Methode jetzt noch auf einem 486dx-local-bus getestet. Auch dort funktioniert sie nicht. Es flimmert zwar nicht, aber die ersten 30 Zeilen werden nicht korrekt angezeigt. Das heißt für mich, die alten PCs sind einfach zu langsam, um die Display-Register innerhalb eines Retraces zu setzen.

Das einzige, was bei mir ohne jegliches Flimmern und Flackern funktioniert, ist die von mir zuletzt gepostete Routine unter Problem 1, und zwar unbhängig davon, ob ich sie in pascal oder asm umsetze.

Ich werde sie vorerst beibehalten.

Grüsse wobo
Das ist schon merkwürdig.

Ich vermute mal eine VBE3-Karte für 386/486 gibt es wohl nicht, denn dort gibt es das vesa hardware-triple-buffering welches vom Bios selber mit dem Retrace synchronisiert wird.
Denn auch auf schnelleren Rechners stößt man mit dem alleinigen Warten auf den Beginn des Retrace schnell an die Grenzen beim Befüllen einer einzigen Bildschirmseite.
Das Befüllen des Bildrams sollte in einem Rutsch möglichst schnell erfolgen, da der Zugriff auf das Bildram langsamer ist als auf den Arbeitsspeicher.
Ob es hier Geschwindigkeits-Unterschiede gibt zwischen gerade nicht angezeigten Bildram und angezeigten Bildram weiss ich auch nicht.
Wenn Lesezugriffe und Schreibzugriffe auf die Bilddaten erfolgen sollen, (z.B. beim farblichen Überblenden von einem Bild zu einem anderen Bild,)
dann macht man das bestenfalls im Arbeitsspeicher und kopiert den fertigen Inhalt(Überblendstufe) dann in den Bildram, weil Lesezugriffe im Bildram noch sehr viel langsamer sind als Schreibzugriffe.

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von wobo »

Ich habe das ganze noch an einem p75 mit s3 trio ausprobiert. Auch dort ist die Situation wie auf dem 486dx40. Die obersten 30 zeilen des Bildschirms enthalten die "falsche" Bildschirmseite.

So ganz kann ich das ganze aber nicht verstehen. Meine Info, dass die VGA die Display-Register bei Beendigung des VRetraces aktualisiert, scheint nicht ganz richtig zu sein: Anders kann ich mir nicht erklären, dass bei Deiner Methode auf alten PC oben noch die falsche Bildschirmeite zu sehen ist.

Naja, egal. Ich habe eine Methode, die vom 386sx16 bis zu meinen schnellsten PCs mit Floppylaufwerk (amd duron) und unter DOSbox läuft. Wenn mal wieder Zeit ist, müßte ich mir halt überlegen, was ich mit meiner Interrupt-gesteuerten Soundroutine mache, der "meine" Methode zum Pageflipping wegen des langen Sperrens der Interrupts nicht bekommt ....


Ansonsten war ich schon erstaunt, dass Du p4 - rechner unter DOS programmierst. Sobald ich mehr als 6 MB Ram habe, weiss ich gar nicht mehr, was ich damit machen soll. Aber irgendwo habe ich gelesen, dass Du so hohe Auflösungen wie 1024x768x32bit (oder noch mehr) nutzt. Dann hast Du ja auch locker das 50-fache Datenvolumen wie ich unter 320x200x8bit. Dann dürfen Deine Rechner ja auch ruhig 50x so schnell sein ;->>

Ich starte hier mal 'nen Zwischenaufruf an etwaig mitlesende Dos-Programmierer: Wer von Euch benutzt noch mehr als 4-6 MB Speicher unter DOS und - um alles in der Welt - was tut Ihr da hinein???

wobo
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von freecrac »

wobo hat geschrieben:Ich habe das ganze noch an einem p75 mit s3 trio ausprobiert. Auch dort ist die Situation wie auf dem 486dx40. Die obersten 30 zeilen des Bildschirms enthalten die "falsche" Bildschirmseite.

So ganz kann ich das ganze aber nicht verstehen. Meine Info, dass die VGA die Display-Register bei Beendigung des VRetraces aktualisiert, scheint nicht ganz richtig zu sein: Anders kann ich mir nicht erklären, dass bei Deiner Methode auf alten PC oben noch die falsche Bildschirmeite zu sehen ist.

Naja, egal. Ich habe eine Methode, die vom 386sx16 bis zu meinen schnellsten PCs mit Floppylaufwerk (amd duron) und unter DOSbox läuft. Wenn mal wieder Zeit ist, müßte ich mir halt überlegen, was ich mit meiner Interrupt-gesteuerten Soundroutine mache, der "meine" Methode zum Pageflipping wegen des langen Sperrens der Interrupts nicht bekommt ....


Ansonsten war ich schon erstaunt, dass Du p4 - rechner unter DOS programmierst. Sobald ich mehr als 6 MB Ram habe, weiss ich gar nicht mehr, was ich damit machen soll. Aber irgendwo habe ich gelesen, dass Du so hohe Auflösungen wie 1024x768x32bit (oder noch mehr) nutzt. Dann hast Du ja auch locker das 50-fache Datenvolumen wie ich unter 320x200x8bit. Dann dürfen Deine Rechner ja auch ruhig 50x so schnell sein ;->>

Ich starte hier mal 'nen Zwischenaufruf an etwaig mitlesende Dos-Programmierer: Wer von Euch benutzt noch mehr als 4-6 MB Speicher unter DOS und - um alles in der Welt - was tut Ihr da hinein???

wobo
Mein derzeitiger Rechner ist ein Intel Core2quad@2,8ghz mit 4GB RAM und einer PCIe Nvidia GTX295 die ich im Vesamode mit 1920x1200x32@60hz auf meinen HansG 28"LCD betreibe. DOS boote ich von 2GB-USB-Stick.
Vorher habe ich ein AMD TBred@2,7ghz und 1GB RAM mit einer AGPx4 GF4TI4200(64MB) auf Samsung 19"CRT[96khz] z.B. in 1024x768x32@100hz, oder 800x600x32@140hz verwendet.

Mit Bilddaten sind 1GB Ram schnell gefüllt. Eine Anwendung für 800x600 benutzt Kartenmaterial in sehr hohen Auflösungen, vergleichsweise wie hier zu sehen(das von mir verwendete Bild finde ich im Moment nicht mehr im Internet):
http://www.friedhof-hamburg.de/fileadmi ... lsdorf.pdf
Im Hauptfenster(rechte Seite des Bildschirms) meiner DOS-Anwendung sieht man ein verkleinertes/zusammengestauchtes Bild davon(aber gedreht, ost ist oben).
Mit dem Mousecursor kann man sich nur im Hauptfester bewegen und wenn man die rechte Mousetaste gedrück hält, dann wird In der linken oberen Ecke ein kleiner Bildauschnitt des original grossen Bildes(ca. 2400x1500) angezeigt.
Auf dem Bild im Hauptfenster frage ich die Mouseposition ab und an bestimmten Punkten(Kapellen, Feierhallen) wird ein Bild davon in der oberen Ecke eingeblendet (also wenn rechte Moustaste nicht gedrückt wird).
An so einer Stelle kann man mit dem Klick auf die linke Moustaste das Hauptfenster verlassen und ein Kapellenbild(ganzer Bildschirm; Innenansicht) erscheint. Unten am Bildrand gibt es Buttons für "Zurück" und "Edit". Diese Anwendung verwendet fast 1 GB an Speicher.

Eine andere Anwendung benutzt kleine Filmauschnitte die mit einer TV-Karte aufgenommen wurden. Für nur wenige Sekunden Film kommen hier schon schnell 100MB an Daten zusammen.

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von wobo »

Wow! - kann ich da nur sagen. Sowohl was die Hardware angeht, als auch und vor allem Deine Software-Projekte!

Ich selbst bin da intellektuell und technisch in den 80ern/90ern verblieben. Mein technisches Know-How beschränkt sich tatsächlich meistens auf das Verschieben von Sprites - was mal in den 80ern als hohe Kunst galt und von mir heute noch immer nicht so souverän beherrscht wird.

6 MB Ram brauche ich auch nur bei wenigen Anwendungen. 2 MB benötigt TP 7.0; den Rest (frei meist 2.5 - 2.8 MB XMS) benutze ich dann z.B. für´s Hochladen "größerer" PCX-Bilder oder Fli-Animationen, ansonsten allenfalls noch für mein Game. Momentan vertrödele ich meine Zeit ohnehin immer damit, aus dem onboard-VideoChip meines 386sx16 irgendwelche verqueren Videomodi herauszuholen, die auf einem 31.5khZ-Festfrequenzmonitor laufen. Ist natürlich super-produktiv, aber irgendwie fasziniert mich zu sehen, was auf so ´nem alten Rechner noch alles geht. In den 80ern gab es für mich sklavisch nur 320x200/256 und 640x350/16.


Noch ´ne Anmerkung: Ich habe jetzt im Internet noch mal rumrecherchiert. Es machen anscheinend mittlerweile alle wie Du, d.h. auf den Beginn des Vertical Retraces warten und dann schnellst möglich die Display-Register setzen. Vielleicht begehe ich ja auch anderswo einen gedanklichen Fehler. Bei Gelegenheit werde ich Mal ein Beispielsource posten, vielleicht fällt Dir/Euch ja irgendwas auf.

wobo
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von freecrac »

wobo hat geschrieben:Wow! - kann ich da nur sagen. Sowohl was die Hardware angeht, als auch und vor allem Deine Software-Projekte!

Ich selbst bin da intellektuell und technisch in den 80ern/90ern verblieben. Mein technisches Know-How beschränkt sich tatsächlich meistens auf das Verschieben von Sprites - was mal in den 80ern als hohe Kunst galt und von mir heute noch immer nicht so souverän beherrscht wird.

6 MB Ram brauche ich auch nur bei wenigen Anwendungen. 2 MB benötigt TP 7.0; den Rest (frei meist 2.5 - 2.8 MB XMS) benutze ich dann z.B. für´s Hochladen "größerer" PCX-Bilder oder Fli-Animationen, ansonsten allenfalls noch für mein Game. Momentan vertrödele ich meine Zeit ohnehin immer damit, aus dem onboard-VideoChip meines 386sx16 irgendwelche verqueren Videomodi herauszuholen, die auf einem 31.5khZ-Festfrequenzmonitor laufen. Ist natürlich super-produktiv, aber irgendwie fasziniert mich zu sehen, was auf so ´nem alten Rechner noch alles geht. In den 80ern gab es für mich sklavisch nur 320x200/256 und 640x350/16.
Seitdem ich auf meiner ISA-ET4000(1MB) True Color kennengelernt habe versuche ich solche Modi auch zu verwenden. Erst mit 640x480x24 und dann mit 800x600x24 auf der nachfolgenden VLB-ET4000(2MB).
Danach folgte schnell eine PCI-MGA MIL II(4MB) so das ich die Hardware-Sprites der ET4000 noch nie selber ausprobiert habe. Abgesehen von ersten Sprites beim C64er habe ich bis heute es nicht gelernt die Hardware für Sprites zu benutzen.
Mit der Matrox bekam man auch Blitting(BitBLT) doch es gibt kleine Unterschiede:
http://en.wikipedia.org/wiki/Bitblt

Code: Alles auswählen

Blitting vs hardware sprites

Blitting is similar to hardware-sprite drawing, in that both systems reproduce a pattern, typically a square area, at different locations on the screen. Hardware sprites have the advantage of being stored in separate memory, and therefore don't disturb the main display memory. This allows them to be moved about the display, covering the "background", with no effect on it.

Blitting moves the same types of patterns about the screen, but does so by writing into the same memory as the rest of the display. This means every time the pattern is placed on the screen, the display "under" it is overwritten, or "damaged". It is up to the software to clean this damage up by blitting twice, once to remove the damage, and then again to place the bit in its new location. However, there are several ways to optimize this. If large areas of the screen are taken over by the patterns, it may be more efficient to blit the background to the screen instead of erasing each pattern individually. A variation involves dividing the screen into segments and erasing only the segments where patterns have been drawn on. This technique is known as dirty rectangles.

As one might imagine, this makes blitting significantly slower than sprite manipulation. However blitting has one very big advantage: there's no physical limit to the number of patterns you can blit, or to the size of the patterns. Thus you can use blitting to display anything on the screen, including simulating sprites (through the double-write pattern noted above), or even text.
Wie man dieses Hardware-Blitting selber benutzen kann habe ich auch noch nicht gelernt.

Da man aber hiermit den Bildhintergrund selber restaurieren muss und man eh nur rechteckige Sprites benutzen kann, deswegen habe ich mich für eine andere Form von Software-Sprites entschieden die sich über den gesamten Bildbereich erstrecken können und nicht an eine Form gebunden sind. Ich starte dafür auf einem leeren Bildschirm und zeichne dort in der linken oberen Ecke beginnend ein Objekt, oder lade dorthin ein freigestelltes Objekt aus einem Truecolorbild. Dann überprüfe ich den gesamten Bildschirm, ob an einer Adresse eine Farbe enthalten ist. Mit dieser linearen Bild-Adresse und dem Trucolor-Farbwert lege ich eine Sprite-Tabelle an dessen Länge ich mir merke. Adresse,Inhalt, Adresse, Inhalt,... Wenn man es nicht so genau nimmt und auch nicht mit der Lupe nachschaut, dann kann der jeweilige Inhalt auch gleich aus zwei benachbarten Pixeln nebeneinander bestehen, so das wir 8 Bytes für diese beiden Pixel erhalten bei Modi mit 32Bit. Wir gehen mal davon mal aus das wir keine Pixelwolke aus einzelnen Pixels über den Bildschirm bewegen wollen und es daher sehr oft vorkommt das zwei Pixel nebeneinander liegen. Mit einem 64Bit grossen MMX-Register können wir so das Kopieren des Sprites(und auch das vorherige Restaurieren vor dem Setzen) an eine sinnvolle Adresse im Bildbereich schon etwas beschleunigen.
Noch ´ne Anmerkung: Ich habe jetzt im Internet noch mal rumrecherchiert. Es machen anscheinend mittlerweile alle wie Du, d.h. auf den Beginn des Vertical Retraces warten und dann schnellst möglich die Display-Register setzen. Vielleicht begehe ich ja auch anderswo einen gedanklichen Fehler. Bei Gelegenheit werde ich Mal ein Beispielsource posten, vielleicht fällt Dir/Euch ja irgendwas auf.

wobo
Ist es vieleicht besser zuerst die Low-Adresse zu übertagen noch vor der High-Adresse, hast du das schon mal ausprobiert?

Dirk
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von wobo »

zu Hardware-Sprites und Hardware-Blitting: Uuups. Ich verwende den Begriff Sprites als reine Software-Sprites (nach Wikipedia ist das falsch. Software-Sprites seien "Shapes"...). Jedenfalls sind meine Sprites reine Software-Bitmaps, bei denen letztlich jeder Pixel vor dem Setzen - per Software - darauf geprüft wird, ob er transparent ist. That´s it!

Noch ein Uuups: Das Vertauschen von Low und High-Register beim Setzen der Display-Adresse scheint bei mir erhebliche Besserung zu bewirken. D.h., wenn ich zuerst den Low-Anteil, dann den High-Anteil setze, habe ich seltener das Zucken, auch wenn ich die Interrupts nicht so lange sperre (d.h. einschließlich der Warteschleifen für den Retrace). Technisch kann ich mir das zwar nicht erklären, aber Danke für den Tipp!

wobo
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von freecrac »

wobo hat geschrieben:zu Hardware-Sprites und Hardware-Blitting: Uuups. Ich verwende den Begriff Sprites als reine Software-Sprites (nach Wikipedia ist das falsch. Software-Sprites seien "Shapes"...). Jedenfalls sind meine Sprites reine Software-Bitmaps, bei denen letztlich jeder Pixel vor dem Setzen - per Software - darauf geprüft wird, ob er transparent ist. That´s it!

Noch ein Uuups: Das Vertauschen von Low und High-Register beim Setzen der Display-Adresse scheint bei mir erhebliche Besserung zu bewirken. D.h., wenn ich zuerst den Low-Anteil, dann den High-Anteil setze, habe ich seltener das Zucken, auch wenn ich die Interrupts nicht so lange sperre (d.h. einschließlich der Warteschleifen für den Retrace). Technisch kann ich mir das zwar nicht erklären, aber Danke für den Tipp!

wobo
Es gibt Ports bei den man in einer bestimmten Reihenfolge die Daten übertragen muss. So könnte es sein das wenn man versucht zunächst das Highbyte zu übertragen, das dieses Byte beim ersten Mal verschluckt wird und danach das Low-Byte erfolgreich übertragen wird und erst in der darauf folgenden Runde auch das Highbyte übertragen wird.

Dirk
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von DOSferatu »

Kleiner Tip meinerseits, wenn man z.B. den ModeX in 320x200 benutzt:
Jede Seite braucht dannzwar nur 16000 Bytes (*4 halt), aber wenn man z.B. die Seiten an glatten 16384er Adressen (genau 16 kB) starten lassen würde, hätte man trotzdem noch 4 Seiten, müßte aber NUR das Higbyte umschalten und hätte das Problem mit dem "IRQ zwischen Low- und Highbyte" nicht mehr...
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von wobo »

@freecrac:

Nochmals Danke für Deinen Tip mit dem Vertauschen der Reihenfolge von High- und Low-Anteil der Display-Adresse. Ich hatte das jetzt im 6-monatigen Dauergebrauch und ich habe keinen Bildschirmfehler mehr feststellen müssen! Wow! Problem - nachhaltig - gelöst!


@DosFeratu:
DOSferatu hat geschrieben:Kleiner Tip meinerseits, wenn man z.B. den ModeX in 320x200 benutzt:
Jede Seite braucht dannzwar nur 16000 Bytes (*4 halt), aber wenn man z.B. die Seiten an glatten 16384er Adressen (genau 16 kB) starten lassen würde, hätte man trotzdem noch 4 Seiten, müßte aber NUR das Higbyte umschalten und hätte das Problem mit dem "IRQ zwischen Low- und Highbyte" nicht mehr...
danke auch Dir für Deinen Tip. Auf die Idee, nur den High-Anteil setzen zu müssen bin ich auch schon gekommen. Allerdings kann ich nicht mit statischen Bildschirmadressen arbeiten. Das ist so, wenn man scrollen will und hat keinen 486dx133...

Wie machst Du es denn mit XPYDERZ. Dein Game hat nämich auf meinem PC genau eben dieses (sporadische) Zucken, obwohl Du eigentlich statische Page-Adressen haben solltest.
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von DOSferatu »

wobo hat geschrieben: @DosFeratu:
danke auch Dir für Deinen Tip. Auf die Idee, nur den High-Anteil setzen zu müssen bin ich auch schon gekommen. Allerdings kann ich nicht mit statischen Bildschirmadressen arbeiten. Das ist so, wenn man scrollen will und hat keinen 486dx133...

Wie machst Du es denn mit XPYDERZ. Dein Game hat nämich auf meinem PC genau eben dieses (sporadische) Zucken, obwohl Du eigentlich statische Page-Adressen haben solltest.
Ja, ich setze Low und High (meine Mode-X Routinen sind generalisiert für verschiedene Auflösungen). Außerdem mache ich - je nach Einstellung - gar keine Retrace-Abfrage.
Ich benutze Quadruple Buffering (4 Bildschirmseiten).
Ich zeichne immer eine Seite, schalte um, dann arbeite ich alle "Steps" ab, die bisher angefallen sind und dann zeichne ich wieder eine Seite, usw...
Das ganze Timing von XPYDERZ ist unheimlich müllig gemacht. Das Problem ist halt, daß ich nicht hardware-scrolle, sondern wirklich jedes Frame komplett neu zeichne. Auf Rechnern, die nicht gerade wahnsinnig schnell sind, erreiche ich nie die volle Framerate, ich habe in keinem Fall jemals ein weiches Scrolling bei XPYDERZ. Grund ist auch, daß der 320x200 Mode normalerweise mit Bildfrequenz von 70 Hz läuft (auf manchen Laptops mit 60 Hz oder wasweißich). Das Game selber läuft mit 50 Hz (wird intern aber mit 400 Hz getickert). Der ganze Krempel ist so dermaßen unsynchron, daß es mich wundert, daß es überhaupt funktioniert.
Im "OPTIONEN-Menü" kann man unter PERFORMANCE den Vertical Retrace Wert einstellen auf OFF, ON oder AUTO. OFF bedeutet, daß überhaupt kein VR berücksichtigt wird - dies ist für langsame Rechner gedacht, die sowieso nie 70 FPS schaffen würden. ON ist für schnelle Rechner gedacht, die so schnell sind, daß sie mind. 3 Frames plus Berechnung der Game-Steps so schnell hinkriegen, daß der Wechsel zwischen den 4 Bildschirmseiten quasi "überläuft". AUTO versucht anhand der gemessenen FPS zu ermitteln, ob VR-Abfrage nötig ist oder nicht und stellt sich selbst ein (das ist auch die Grundeinstellung).
Wundere mich sowieso, wieso bisher noch keiner dieses crappy Scrolling von XPYDERZ angemosert hat. Das Game (die erste Version) ist schon 10 Jahre alt, bzw einige der Routinen. Bei meinen nächsten Spielen würde ich sowieso vieles anders machen - wenn ich überhaupt noch mal ein Spiel schreibe.
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von wobo »

DOSferatu hat geschrieben:
[...XPYDERZ...]

Ja, ich setze Low und High (meine Mode-X Routinen sind generalisiert für verschiedene Auflösungen). Außerdem mache ich - je nach Einstellung - gar keine Retrace-Abfrage.
Ich benutze Quadruple Buffering (4 Bildschirmseiten).
Ich zeichne immer eine Seite, schalte um, dann arbeite ich alle "Steps" ab, die bisher angefallen sind und dann zeichne ich wieder eine Seite, usw...
Das ganze Timing von XPYDERZ ist unheimlich müllig gemacht. Das Problem ist halt, daß ich nicht hardware-scrolle, sondern wirklich jedes Frame komplett neu zeichne. Auf Rechnern, die nicht gerade wahnsinnig schnell sind, erreiche ich nie die volle Framerate, ich habe in keinem Fall jemals ein weiches Scrolling bei XPYDERZ. Grund ist auch, daß der 320x200 Mode normalerweise mit Bildfrequenz von 70 Hz läuft (auf manchen Laptops mit 60 Hz oder wasweißich). Das Game selber läuft mit 50 Hz (wird intern aber mit 400 Hz getickert). Der ganze Krempel ist so dermaßen unsynchron, daß es mich wundert, daß es überhaupt funktioniert.
Im "OPTIONEN-Menü" kann man unter PERFORMANCE den Vertical Retrace Wert einstellen auf OFF, ON oder AUTO. OFF bedeutet, daß überhaupt kein VR berücksichtigt wird - dies ist für langsame Rechner gedacht, die sowieso nie 70 FPS schaffen würden. ON ist für schnelle Rechner gedacht, die so schnell sind, daß sie mind. 3 Frames plus Berechnung der Game-Steps so schnell hinkriegen, daß der Wechsel zwischen den 4 Bildschirmseiten quasi "überläuft". AUTO versucht anhand der gemessenen FPS zu ermitteln, ob VR-Abfrage nötig ist oder nicht und stellt sich selbst ein (das ist auch die Grundeinstellung).
Wundere mich sowieso, wieso bisher noch keiner dieses crappy Scrolling von XPYDERZ angemosert hat. Das Game (die erste Version) ist schon 10 Jahre alt, bzw einige der Routinen. Bei meinen nächsten Spielen würde ich sowieso vieles anders machen - wenn ich überhaupt noch mal ein Spiel schreibe.
1.
XPYDERZ habe ich immer mit Vertical Retrace OFF gespielt, was das von mir (sporadisch) erlebte Bildschirmzucken erklärt. Hatte daran aber nicht mehr gedacht, als ich mein obiges Posting postete...

2.
Mir gefällt das Scrolling von XPYDERZ sehr gut. Es hat mir schon imponiert, dass auf schnellen PCs das Scrolling sehr weich ist, auf langsameren dagegen trotzdem die absolute Geschwindigkeit gleich bleibt (auch wenn das Scrolling dann halt zwangsläufig etwas härter ist).

3.
Übrigens ist mir bei all Deinen Programmen (d.h. nicht nur bei XPYDERZ) aufgefallen, dass sie anscheinend keine Fehler, insb. keine Abstürze haben und fehlerfrei das machen, was Du in der Beschreibung angibst. Bei meinen Programmen ist das immer anders. Meistens funktionieren Sie auf dem Programmier-PC und vielleicht noch unter DosBox. Auf anderen PCs gibt es aber immer wieder Mal einen satten Absturz - jüngst gerade erlebt.
Bei Deinen Programmen (z.B. auch FAQreader, Wandler, hex-Editor) ist das nie der Fall gewesen. Kompliment!
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: kleine Probleme mit Retrace und VGA unter Pascal

Beitrag von DOSferatu »

Naja, das liegt wohl daran, daß ich eher ein Lamer bin, der selten bis nie irgendwelche wirklich "krassen" Dinge tut - ich benutze Turbo Pascal und RealMode Assembler. Aber ich benutze ja nicht mal so crazy Dinge wie den 4G-Mode (Flat Mode) oder ähnliche "Hacks". Mein Problem ist eher, daß ich gelegentlich Programme fabriziere, die recht viel Heap-Speicher fressen.

Aber trotzdem: Danke für die Blumen.

Leider programmiere ich in letzter Zeit nur noch so Tools für einen Kumpel und gelegentlich mal ein kleines eigenes Tool, wenn ich mal eins brauche. Ich finde einfach nicht mehr die Energie, um ein Spiel zu machen - obwohl ich quasi (fast) alles habe, was man dazu bräuchte. Es mag vielleicht auch daran liegen, daß es heutzutage kaum noch Leute gibt, die a) Lust hätten, so altmodisches Zeug zu spielen und vor allem b) überhaupt noch Rechner und Betriebssysteme haben, auf denen der Kram überhaupt laufen würde. Spiele schreibt man ja normalerweise nicht nur für sich selbst.
Antworten