Mode X und EGA Parrallax

  • Ich habe nach langem mal wieder angefangen unter DOS mich mit Programmiersprachen zu beschäftigen.


    Damals vor 20 Jahren hatte ich viel mit Basic und ab und an Pascal / C++ gearbeitet.

    Leider vergisst man doch sehr viel.


    Ich würde gerne erstmal ein Grundgerüst für Grafik zusammenstellen, worauf man dann Spiele aufbauen kann. Also brauche ich "schnelle" Grafik.

    Basic kann ich zwar am besten, aber es ist unter DOS halt zu langsam und es ist sehr eingeschränkt.



    Ich habe mich jetzt dazu durch gerungen Borland C++ 3.1 zu verwenden, da ich mit DOS arbeiten möchte.

    Zielplattform 386-DX 33-40 / VGA / 4MB RAM

    Der Compiler kann 386 optimierten Code schreiben, ich denke das passt so.


    Fürs erste würde ich mich gerne mit der Grafik beschäftigen.


    -VGA MODE X 320x200 256 4 Bildschirmseiten

    -EGA 320x200 16Farben 8 Bildschirmseiten Parallax Scrolling würde ich mir gerne anschauen.


    Im Netzt finde ich nicht mehr wirklich viel brauchbares hierzu.

    zu Mode X habe ich jetzt was halbes zusammen geschrieben es fehlt aber noch an allem.


    das Programm setzt die Grafikkarte auf MODE X mit 320x200 Auflösung und es werden Pixel rein geschrieben.

    Danach kann man das ganze mit den tasten asdw verschieben mit q beendet man das Programm.

    Es ist noch nicht strukturiert und auch wild beschriftet.


    hat wer Mustercode oder gute Dokumentationen, ich nehme alles was mir weiter hilft.


  • sehe ich das richtig das ich für den EGA Modus für jeden Pixel immer in 4 Planes schreiben muss und dann noch das lustige puzzle um die richtige Farbe zu treffen?

    hat wer zufällig einen fertigen Codeschnipsel hierzu?


    Ich habe das zwar in Assembler händisch hin bekommen, aber meine Assembler Kentnisse sind zu schlecht um das auf die schnelle so um zu bauen das es efficient die Punkte setzt.

  • Markus Zu beiden Themen kann ich dir PC Intern 4 ans Herz legen, da steht sehr viel zu EGA aber auch VGA Programmierung drin. Von mir gibt es drei Let's Code Videos speziell zu Mode X und Scrolling (pures C):


    Bei EGA musst du um einzelne Pixel zu setzen vier Planes bearbeiten, ja. Daher solltest du es vermeiden einzelne Pixel zu setzen, da man ja pro Byte immer acht Pixel bearbeitet... Die EGA Karte hat aber einige Tricks auf Lager, wie z.B. die Latches um mehrere Pixel parallel zu verarbeiten. Schau mal in das PDF hier bei Jim L. rein:


    ftp://ftp.oldskool.org/pub/dri…987-01-Inside_The_EGA.pdf


    Auch nicht verkehrt als Buch ist PC Underground, das beschränkt sich hauptsächlich auf VGA und Mode X. Dazu noch Protected Mode und so...

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • die Videos kannte ich schon.

    mode X scrollen geht richtig schnell, wobei ich das wohl eher nicht in Software gebrauchen kann, man braucht die anderen Bildschirmseiten ja fast immer für den Backbuffer oder als "Ablage".


    das 3. Video verstehe ich nicht so ganz, kopierst du die bilder im speicher hin und her oder was wird da genau gemacht?

    Mein Englisch ist zu bescheiden ich verstehe leider immer nur die hälfte.


    der FTP Link funktionier leider nicht bei mir.


    ich kann jetzt schonmal irgendwie in alle planes gleichzeitig bits schreiben, was aber nicht immer funktioniert, es gibt da grafik murks aber nur stellenweise. für heute qualmt mir der kopf...

    Einmal editiert, zuletzt von Markus ()

  • Irgendwie komme ich mit dem Code nicht so recht weiter.


    folgendes soll der Code machen:

    -Grafik auf Mode X 320x200x4 setzen (funktioniert überall)

    -einen "Würfel" 16x16 Pixel zeichnen oben links (funktioniert überall)


    -den Würfel kopieren auf eine andere position mit Hilfe von Latch copy

    auf einem Rechner mit DOSbox funktioniert das einwandfrei

    auf einem anderen mit Dosbox wird der Würfel nicht kopiert

    auf einem 386 und einem 486 wird nicht richtig kopiert die Farben sind einfach falsch.


    hat wer eine Idee? Compiler Borland C++ 3.1 Speicher Modell large.

    Der Compiler ist auf allen 3 Rechnern exakt der selbe wurde immer nur hin und her kopiert oder von USB gestartet.




  • Ich bin gerade im Urlaub und kann daher nix testen. Aber hast du sichergestellt dass die Dosbox Config auf EGA als Maschine steht? Alternativ mit 86box eine EGA Maschine zusammenstellen. Default Dosbox emuliert VGA und EGA Register sehr schwammig.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • Hi,

    der Code ist für Mode X VGA

    Was mir mehr Kopfzerbrechen bereitet ist das es auf den richtigen PC's unter DOS nicht funktioniert

    Testsysteme waren 386DX40 mit ET4000 / AMD486-133 mit S3 868 VLB. Die Karten sind ja jetzt keine so exotischen Modelle.


    auf dem Rechner hier läuft es unter Dosbox.

    Der linke Würfel wird direkt Pixel für Pixel über einen Pointer in den Speicher geschrieben und danach mit latch copy immer 4 Pixel gleichzeitig kopiert.

    Bei allen anderen Testplattformen wird nur der erste Würfel richtig dargestellt, latch copy mach entweder nichts oder der Würfel ist ein bunter Pixelbrei.


    Ich habe mit C++ unter DOs noch keine Erfahrungen, daher ist die Fehlersuche etwas komplizierter.

  • Du hast recht 8 Bit 256Farben meine ich.


    ich bin noch am vergleichen zwischen EGA und VGA und wenn der Rechner es schnell genug schafft, würde ich 256Farben den 16Farben vorziehen.

    Aber der 386er hat schon ordentlich Arbeit mit dem ganzen.

  • ...Borland c++ ist das böse!!!

    ich habe mir jetzt die Arbeit gemacht den Compiler auf der Arbeit in ein zip zu packen und bei mir zuhause jetzt auf den Rechner zu kopieren.

    Der Code lief mit dem kopierten compiler dann auch merkwürdigerweise.


    Ich habe dann mal gründlich die Einstellungen durchsucht und wurde fündig.

    es gibt einen Menüpunkt im Compiler dead Code elimination dieser war aktiviert, anscheinend eliminierte er mehr wie dead Code...


    Da habe ich jetzt bestimmt 4 Stunden nach fehler gesucht und der Code war richtig.

    C++ ist das böse.


  • Ahja. Dann dich besser Assembler Code in eigene Dateien auslagern und bei Bedarf dazu linken.

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • Mode X

    Wenn der Rechner wirklich den kompletten Bildschirmbereich neu zeichnen muss indem er eine Kachel 16x16 oder 32x32 Pixel vom nicht sichtbaren Bereich in den Sichtbearen kopiert mit latch copy, dann kommt der 386dx40 auf ganz 3FPS. schnell ist anders.

    Mit scrollen kann man "Bilder" schneller bewegen, aber wenn jetzt viel im Vordergrund sich verändert, wird es vermutlich wieder sehr langsam.

    Darüber hinaus kommt er beim scrollen je nach Grafikkarte auch gerne zu Grafikfehlern.

    Scrollt man bei der S3 zu hoch ist das gesamte Bild schwarz, bei der ISA Karte entstehen in der ersten Zeile und teils zwischendurch Grafikfehler, je nach Position.

    Ich werde hier nochmal mit der recht verbreiteten Trident / CL und ET4000 Tests machen.


    Ich habe einen open Source Code als vergleich wie schnell Mode X sein kann, dieser ist einiges schneller wie meine eigener Code, dieser hat jedoch noch mehr Grafikfehler wie mein Code.

  • ein wenig vom gelernten umsetzen.

    Das Kachel Raster soll "Blockweise" verschoben werden, texturen sind gerade in der Mache.

    Der 386er schafft das Raster noch ziemlich schnell mit ordentlich FPS.

    Später wird der Code soweit erweitert das geprüft wird welche Kacheln sich grafisch verändern bei einer verschiebung um unnötiges laden zu verhindern.

    ein 386er mit ISA ist halt kein Rechenwunder, abr es ist interressant den Code an zu passen und kompromisse zu finden.

    Wenn es garnicht geht weiche ich auf 486 aus :P


    Borland C++, ist zum Anfangen wohl ein zoiemlich guter Compiler. Der Debugger ist ziemlich brauchbar.

    Er meckert imer wenn ich das >;< am ende der Zeile vergesse.

    Wenn man sonst nur Code schreibt der das nicht verlangt ist das echt eine umstellung

    Und C++ meckert bei Gross/Kleinschreibung der Horror.

  • Wenn ich mich richtig ans Doom developers Setup erinnere hatten die einen 486er zum Testen über Netzwerk an einer Next(?) Workstation zum Prigrammieren. So ein Setup ließe sich ja heute recht einfach aufbauen und würde den Entwicklungsaufwand deutlich reduzieren...

    386SX- 20 Mhz "Erster eigener Rechner!2" NoName Komponenten

    486DX -30 "Industrie PC" auf Steckkarte

    Super Sockel 7 Gigabyte GA-5AA 3Dfx Voodoo 3500 TV

    AMD "Geode" ebenfalls Steckkarte für Backplane

    3x IBM Netvista 8364 "ThinRetroSystem" 1-2 von denen würde ich tauschen...


    "und noch so einiges mehr... "

  • Wird langsam.

    Eine "Landschaft" wird dargestellt aus frei wählbaren Texturen.

    Es gibt 3 Kamera Modie.

    1=Kamera springt wenn der Spieler sich 1 feld vor Bildschirm ende befindet um fast eine Bildschirmseite weiter "Ressourcensparenste Variante"

    2=Kamera bewegt sich erst mit wenn der Spieler 1 feld vom Rand weg ist.

    3=spieler permanent im Mittelpunkt Landschaft muss nach jeder bewegung um 1 Feld neu berechnet werden.


    Bei der neuberechnung der Landschaft wird geprüft wie das aktuelle Feld ausschaut, wenn sich gleiche Kacheln an neuen positionen befinden sollen wie bereits geladene, dann wird die Kachel nicht neu geladen.

    Später wird die neu Zeichnung über 2 Seiten wechselnde Buffer generiert, hierzu speichert das Programm schon die letzten 2 Positionen um den richtigen Buffer zum auswerten zu erwischen.


    oben Links wird eine komplette MAP mit Spieler Position angezeigt, wird aktuell bei jedem neu zeichnen komplett neu geueichnet... später wird der spieler Punkt lediglich neu errechnet wenn er sich ändert.


    Spirites kommen noch hinzu, hier muss ich testen was und wie das System in der praxis am schnellsten Daten verarbeiten kann.

    Sprites und texturen möchte ich immer je nach MAP in den RAM laden, nicht benötigtes wird nicht geladen.


    mal schauen wie weit ich mit dem 386er komme bis er in die Knie geht, aktuell kann ich aber auch noch einiges optimieren. Rechenroutinen sind schnell, schnell geschrieben und nicht CPU optimal.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!