VESA Graphikroutinen in Assembler

Diskussion zum Thema Programmierung unter DOS (Intel x86)
Schlowski
Solitärspieler
Beiträge: 13
Registriert: Do 2. Jul 2015, 19:40

VESA Graphikroutinen in Assembler

Beitrag von Schlowski »

Bin inzwischen von Pascal zu Assembler gewechselt - wenn schon Retro dann richtig und was könnte schöner als Assembler sein 8-) und hab mir ein kleines Repertoire an Routinen erstellt (ca. 50 bisher für VESA, XMS, DOS und Initialisierung sowie meine kleine Graphik-Lib) und ein Programmgerüst zum Testen. Das Ganze läuft im FlatRM und unterstützt sowohl direkte Bildschirmmanipulation über den LinearFrameBuffer als auch Memory-Backbuffer mit anschließendem Kopieren des BackBuffers in den Videospeicher.
Pixel setzen und Lesen, gefüllte Rechtecke und Textausgabe (mit oder ohne Hintergrund setzen) läuft mit verschiedenen Bitmap-Fonts, alles mit oder ohne Clipping. Jetzt sind erstmal Linien und Kreise angesagt, Bresenham und Co. sozusagen.

Funktioniert mit allen 8-bit-Farbtiefe VESA-Auflösungen sowohl in der DosBox als auch an meiner realen Hardware (Core2Duo 2.1 GHz und ATI Radeon HD6570), getestet von 640x400 bis 1280x1024.

Ach ja, ich benutze den FASM als Assembler, sowohl auf meinem Win-PC zum Crossdevelopen (ist das ein Wort!?) als auch auf dem DOS-Rechner, um schnell ein paar kleine Änderungen "vor Ort" zu testen, das geht richtig prima.

Am längsten hab ich gebraucht, bis ich endlich das leere Programmgerüst hatte, das in den FlatRM schaltet und heil wieder rauskommt - unglaublich, wie viele Code-Snippets da rumfliegen, die alle irgendwie nicht wollten. Ab dann ging es doch relativ zügig.

(Mal eine kleine Warnung an alle Hobby-Programmierer - die DosBox verzeiht fast alles, was man in Assembler falsch machen kann, ich bin derweil dazu übergegangen, doch relativ häufig auf realer Hardware zu testen. Illegale Opcodes, falsche push/pop Kombinationen und andere Dinge sind mir erst unter echtem DOS um die Ohren geflogen...)
Dateianhänge
Na wer erkennt den Zeichensatz? (Ok, ist nicht sooo schwer)
Na wer erkennt den Zeichensatz? (Ok, ist nicht sooo schwer)
FontUndPalette.png (56.06 KiB) 10932 mal betrachtet
Text allüberall und in bunt!
Text allüberall und in bunt!
Textausgabe.png (91.74 KiB) 10932 mal betrachtet
S+M
DOS-Übermensch
Beiträge: 1059
Registriert: Mo 10. Jun 2013, 17:04
Wohnort: BW

Re: VESA Graphikroutinen in Assembler

Beitrag von S+M »

Also optisch siehts schon mal gut aus :mrgreen: (ja, 256 Farben haben doch was?!)

Für nen kleinen Benchmark reichts ja quasi schon?! ;-)
Schlowski
Solitärspieler
Beiträge: 13
Registriert: Do 2. Jul 2015, 19:40

Re: VESA Graphikroutinen in Assembler

Beitrag von Schlowski »

256 Farben ist der einzig wahre Modus ;-)

Naja, Benchmarken auf 'nem 2GHz Rechner ist etwas witzlos, so langsame Routinen kann man gar nicht programmieren, dass man da was merkt. Obwohl ich durchaus von der ersten zur aktuellen Version an einigen Routinen 50% rausgeholt habe.

Momentan versuche ich gerade, mir den PCEm als 486er so einzurichten, dass ich damit testen kann, nach zwei Tagen fluchen und grübeln und Tools zusammensuchen hab ich ihn jetzt soweit, dass er mein Programm startet - und sich dann bei der ersten Anzeige aufhängt :oops: Aber zumindest das Initialisieren von FlatRM, VESA Graphikmodus und Laden der benötigten Dateien schafft er. Mal schauen...

Edit: Mist, keine der emulierten Graphikkarten unterstützt LFB :-( Da müsste ich mich dann mal mit VESA Banked-Modus beschäftigen... Eine Baustelle jagt die nächste :shock:
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: VESA Graphikroutinen in Assembler

Beitrag von wobo »

Super - sieht großartig aus. Bitte weiter so! Irgendwann, wenn ich mal viel zeit habe (im Rentenalter?) lerne ich auch so richtig Assembler und entwerfe Routinen für 640x480x256 und höher :-)! Assembler macht richtig Spass, finde ich. Es hat mir großes Verständnis dafür gebracht, wie eine CPU funktioniert und was und warum der Turbo Pascal Compiler in bestimmten situationen macht. (ASM war für mich bisher fast nur der tp interne BASM von Turbo Pascal).


Der Zeichensatz ist der Atari ST - zeichensatz? Sieht wesentlich sinniger aus als der ibm - Zeichensatz!
Schlowski
Solitärspieler
Beiträge: 13
Registriert: Do 2. Jul 2015, 19:40

Re: VESA Graphikroutinen in Assembler

Beitrag von Schlowski »

Danke, ich bleibe am Ball. Im Moment habe ich einen Lauf, das muss ich nutzen ;-)

Gut erkannt, ist der ST-Zeichensatz, ich finde, das ist der schönste Standard-Zeichensatz, den es gibt. Der frühe Mac-Zeichensatz ist auch schön, aber mit Proportionalschrift wollte ich mich jetzt (noch) nicht rumärgern.

Assembler macht Riesenspaß, auch wenn ich immer wieder feststelle, das x86 das komplizierteste und mit den meisten Ausnahmen und Sonderfällen gespickte Assembler-Derivat ist. Bin aufgewachsen mit 6502-Assembler, dann 68k und dann x86 - das ist wie Englisch - Deutsch - Chinesisch von der Komplexität :cheesygrin: Aber bietet auch die meisten Möglichkeiten, man kann das ja immer von zwei Seiten sehen.
Schlowski
Solitärspieler
Beiträge: 13
Registriert: Do 2. Jul 2015, 19:40

Re: VESA Graphikroutinen in Assembler

Beitrag von Schlowski »

Hab dann mal versucht, mit UniVBE in PCEm den LFB zu aktivieren - theoretisch geht das, mein Testprogramm gibt mir einen LCB <> 0 aus, aber praktisch bekomme ich immer noch keinen Output :-( Sieht so aus, als ob der UniVBE nicht mit dem FlatRM zurechtkommt - was mich auch nicht allzu sehr überrascht, ich frage mich ohnehin, wie der UniVBE das intern macht.
Bevor ich mich jetzt total verrenne (ist ja alles doch schon ein paar Jährchen her), aber LFB und 486er sollte doch zusammen gehen, oder?

Bin jetzt etwas gefrustet, hätte gern auch eine Testumgebung auf "unterem Niveau" gehabt. So kann ich das nur mit 320x200 Auflösung testen, aber ehrlich gesagt interessiert mich die nicht, das ist mir einfach von der Bildfläche zu wenig, 640x400/480 wäre schon meine gewünschte Minimalauflösung.

Oder sollte ich mich ohnehin von der Vorstellung verabschieden, auf einem 486DX2/66 mit dieser Auflösung was reißen zu können? Wäre dafür dann doch ein Pentium-System sinnvoller?

Fragen über Fragen, vielleicht hat ja jemand von Euch ein paar Einsichten für mich :geek:
Benutzeravatar
matze79
DOS-Gott
Beiträge: 7910
Registriert: So 9. Sep 2012, 20:48

Re: VESA Graphikroutinen in Assembler

Beitrag von matze79 »

Ist LFB nicht eine Protect Mode Sache ?

VBE 2.0 und 3.0 brauchst du glaube ich um LFB zu nutzen.
UniVBE ist nur VBE 1.2.

https://en.wikipedia.org/wiki/VESA_BIOS_Extensions
https://www.shadowcircuit.de - Die kleine Community rund um Retro Computing
https://www.retroianer.de
idspispopd
Norton Commander
Beiträge: 108
Registriert: Fr 8. Mai 2015, 22:28
Wohnort: Hamburg

Re: VESA Graphikroutinen in Assembler

Beitrag von idspispopd »

Sehr schön. Mit FlatRM habe ich es mir damals etwas einfacher gemacht, soweit ich mich erinnere reichte es, himem.sys geladen zu haben und kein EMM386, dann konnte ich mit dem 67h-Präfix die 32-bit-Adressmodi nutzen und beliebig auf den Speicher zugreifen. Ist natürlich eleganter das selbst zu machen, ich kann mir aber gut vorstellen dass sich das trotzdem mit dem V86-Modus beißt (vielleicht ist Dir das schon bekannt, Du hast dazu nichts geschrieben).
Ich habe damals aber nichts so aufwendiges gemacht wie Du, etwas mit HiColor/TruColor rumgespielt (Farbverläufe sind damit natürlich einfach), und Apfelmännchen gerendert.

Wie Du schon festgestellt hast ist der LFB eine Frage der Software bzw. des Video-BIOS. Spätestens die von PCem unterstützten S3-Chips können das in Hardware. Ich habe das damals mit einer ISA-Paradise-Karte und einem 386 gemacht (WD90C31). (Bei einer ISA-Karte muss man ggf. darauf achten dass der LFB innerhalb der ersten 16MB liegen muss, ggf. braucht man dann die BIOS-Option "15-16MB memory hole".) Damit dürfte hoffentlich Deine Frage LFB/486er beantwortet sein?
Als Alternative zu UniVBE könntest Du auch S3VBE20 für die S3-Chips probieren. Oder Du suchst Dir die Hardware-Doku raus und löst das chip-spezifisch.

Ob man x86 jetzt als kompliziert ansieht ist Ansichtssache, ich habe das halt als ersten (und im Prinzip einzigen) Assembler gelernt. Ab dem 386 im 32-bit-Modus wird es einfacher, da orthogonaler (wenn man sich nicht mit dem Protected Mode rumschlagen muss).

Ob der 486DX2/66 mit dieser Auflösung etwas hinbekommt? Das kommt sicherlich auf Deine Erwartungen bzgl. der Performance an. 3D-Spiele in 640x480x256 brauchten typischerweise schon einen schnelleren Pentium für vernünftige Performance. Wenn Du nur 2D animieren möchtest könnte es reichen.
Schlowski
Solitärspieler
Beiträge: 13
Registriert: Do 2. Jul 2015, 19:40

Re: VESA Graphikroutinen in Assembler

Beitrag von Schlowski »

matze79 hat geschrieben:Ist LFB nicht eine Protect Mode Sache ?

VBE 2.0 und 3.0 brauchst du glaube ich um LFB zu nutzen.
UniVBE ist nur VBE 1.2.

https://en.wikipedia.org/wiki/VESA_BIOS_Extensions
Gedacht ist das für den Protected Mode, aber man kann den LFB auch aus dem FlatRM benutzen - hab ich ja schon ganz prima auf meinem Celeron hinbekommen. Mit neueren UniVBE/Scitech Display Doctor -Versionen gibt es VBE 2.0, er zeigt mir auch einen LFB<>0 an, allein, er weigert sich, in Zusammenhang mit meiner Software was anzuzeigen :oops:
Wie Du schon festgestellt hast ist der LFB eine Frage der Software bzw. des Video-BIOS. Spätestens die von PCem unterstützten S3-Chips können das in Hardware.
Tja, hatte ich ja auch gedacht, aber da gibt es bei der VESA-konformen Abfrage der Modi immer eine 0 als LFB.

Gerade nochmal getestet, alle PCEm Graphikkarten liefern nur Vesa 1.2 zurück - da gibt es dann natürlich keinen LFB.

Vielleicht suche und teste ich nochmal den S3VBE20, danke für den Tip! Edit: probiert, funzt auch nicht, grml. Könnte mir vorstellen, dass das eh nur mit schmutzigen Tricks funktioniert, die sich entweder mit dem FlatRM oder der Emulation oder beidem nicht vertragen.

Blöde das alles - so langsam liebäugele ich mit dem Pentium1 - 233 Mhz aus dem Suche/Biete Thread als reale Testmaschine...
Mit FlatRM habe ich es mir damals etwas einfacher gemacht, soweit ich mich erinnere reichte es, himem.sys geladen zu haben und kein EMM386
Das ist sogar zwingende Voraussetzung, weil der FlatRM nur in echtem RealMode funktioniert und sich mit dem VirtualRM von EMM ganz und gar nicht verträgt...

Danke für die Antworten und Anmerkungen, macht Spaß hier was zu posten, hier fühle ich mich jedenfalls verstanden, das ist nicht immer und überall so :like:
Schlowski
Solitärspieler
Beiträge: 13
Registriert: Do 2. Jul 2015, 19:40

Re: VESA Graphikroutinen in Assembler

Beitrag von Schlowski »

Hab gestern nochmal ein wenig an den bestehenden Routinen optimiert und ein paar "convenience"-Funktionen eingebaut. Kann jetzt aus einer Text-Datei die Auflösung lesen, ob DirectMode oder DoubleBuffering und ob als Zeitmessungs-Methode der BIOS-Tick oder RDTSC benutzt werden soll. Damit muss ich nicht immer für alle verschiedenen Testsysteme (mit/ohne Vesa, 486 oder Pentium+) neu assemblieren.

Meine geclippten Textausgabe-Routinen haben nochmal einen Schub von ca. 20% bekommen und die Rechteck-Füll-Routine hab ich auch nochmal um eine intelligentere Linien-Füll-Routine erweitert.

Jetzt muss ich wohl langsam mal an die allgemeinen Linien ran, gibt keine Ausreden mehr ;-)

Nachtrag: Nach diversen Umbau- und Optimierungsmaßnahmen hab ich jetzt auch die Linien-Routine fertig, inkl. Sonderfälle für horizontale und vertikale Linien und (nicht gefüllte) Rechtecke. Wird langsam 8-)
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: VESA Graphikroutinen in Assembler

Beitrag von DOSferatu »

Cool, ein richtiger Programmierer hier - sogar ein Grafikprogrammierer. Und einer, der nicht nur "fertiges Zeug nutzt", sondern sich selbst die die Assembler-Abgründe wagt!
Ich bin immer froh, hier mal "Programmierer-Kollegen" zu treffen - weil in letzter Zeit im DOSforum mehr die Hardware-Threads überwiegel (biete/suche und Fragen zu Einstellungen usw, um Spiele damit zum Laufen zu bekommen).
Schönes Zeug, was Du da schon alles so machst - hast Du vor, das in irgendwelche Projekte einzubauen?
(Tools? Spiele?)
Und ja, ich mag auch den 256-Farb-Mode. Ich programmiere zwar auch in VESA-Modes, aber auch (und noch mehr) in VGA-Modes wie MCGA (320x200x256) und in diesen "Mode-X" genannten Tweaks.

- - - - - - - - - - - - - - - - - - - -
Hier etwas über mich (vielleicht kann man sich ja über manche Themen austauschen) :

Meine Grafikroutinen "wachsen" immer mit der Zeit und den Anforderungen - anfangs 100% in Pascal (habe aber nie die Pascal-eigenen Sachen da benutzt aus dieser Graph-Unit), später wurden diese immer so ein Pascal-Assembler-Hybrid... - so ist es oft bis heute noch, obwohl ich auch einige "reine ASM" Sachen hier habe (Subroutinen von Pascal, aber selbst in Assembler, in 386er Code, mit dem bekannten "Byte-code-Gefrickel, das ich dann einbaue, wenn ich Befehle/Adressierungen brauche, die über 286er hinausgehen).

Leider habe ich nicht mehr so viel Zeit und Energie wie früher, da dieser Job mir eine Menge davon nimmt. Wenn ich nach der Arbeit nach Hause komme, schaffe ich es einfach nicht mehr, mich auf etwas Komplexes zu konzentrieren - meist bin ich da so erledigt, daß ich gar nichts mehr am Rechner mache. Und selbst an Wochenenden bringe ich kaum noch die Energie auf.
Ich muß dabei immer an die Zeit vor 20 Jahren und länger denken, in der ich quasi jede freie Minute am Computer - und das fast ausschließlich mit Programmieren verbracht habe. Hätte ich damals schon das Wissen gehabt, das ich heute habe, hätte ich da ziemlich "coolen Kram" machen können...
Vom "Machen coolen Krams" habe ich mich aber jetzt bereits vor Jahren verabschiedet. Ich kann inzwischen auf dem Computer Dinge tun, die vor 25 Jahren "cooler Kram" gewesen wären. Aber die Zeit schreitet voran und ich mag (und mache) immer noch die Dinge von vor 25 Jahren... (So daß der einzige, der das vielleicht noch "ein wenig cool" findet, wohl nur ich selbst bin...)

Obwohl ich selbst gern Spiele entwickle und auch froh bin, wenn mal wieder eins fertig bzw "fertig" ist, macht mir das Programmieren der "internen Dinge" immer am meisten Spaß, also: Grafikroutinen, die z.B. Levels und Sprites ausgeben, komische Textausgaberoutinen, die Figurensteuerungs-"VM", die ich vor einer Weile gebaut habe oder die Soundausgabe-"Engine", an der ich gerade feile (inkl. des Entwicklungs-Tools, das bei mir irgendwie nicht ganz so "Tracker" ist wie gewöhnlich - werde da aber vielleicht noch eine "Tracker" Bedienung einbauen).

Irgendwie komme ich nur noch sehr langsam voran. Ich habe Spielideen, die hier schon weit über 10 Jahre vor sich hin schimmeln. Das Zeug, das ich so mache, hätte ich vor 15 Jahren vielleicht noch "jemandem anbieten" können, weil mein DOS-Zeug ja auch noch bis Windows XP lauffähig ist, ohne zusätzliche Emulatoren bemühen zu müssen. Heutzutage kann man den Kram, den ich mache, ja nur noch per DOSbox auf aktuellen Maschinen laufen lassen. Und ob jemand, der ein Spiel spielen will (und ein Nur-Spieler ist) sich extra DOSbox drauftun und konfigurieren will, steht zu bezweifeln. (Viele jüngere Leute wissen gar nicht mehr, was DOS ist/war.) Das "Retro-Look&Feel" ist zwar momentan wieder gefragt - aber die Leute wollen das dann wohl doch eher auf aktueller Hardware haben
- - - - - - - - - - - - - - - - - - -
@Schlowski:
Wie kommst Du eigentlich damit klar - das Programmieren und "das restliche Leben" irgendwie in Einklang zu bringen?
Schlowski
Solitärspieler
Beiträge: 13
Registriert: Do 2. Jul 2015, 19:40

Re: VESA Graphikroutinen in Assembler

Beitrag von Schlowski »

Na dann hole ich auch mal etwas aus - leicht Off-Topic, aber ich denke mal, der Thread-Ersteller wird sich nicht beschweren :cheesygrin:

Seit ich 1981 das erste mal an einem PET 2001 gesessen habe und das obligatorische

Code: Alles auswählen

10 PRINT "HALLO"
20 GOTO 10
zum Laufen gebracht habe, bin ich dem Programmier-Virus verfallen. Im Laufe der Jahre hab ich mich von einem VC-20 über einen C-64, Apple-II (Clone), Atari ST, Amiga 500, Acorn Archimedes schließlich zum PC hin entwickelt. Mein erster war ein 286er mit 10Mhz, 1MB RAM, Hercules-Graphikkarte und 20MB Festplatte, danach hatte ich alles vom 386er über 486er und die diversen Pentiums bis zum heute aktuellen Core-i7. Und immer, wirklich auf jeder Kiste, hab ich mich mit Assembler und Graphikroutinen beschäftigt, hab sogar ein paar Spiele fertiggestellt, aber immer nur für den privaten Bereich. Ich liebe es einfach, sowas wie eine Textausgaberoutine in Assembler zu erstellen. Das Erfolgserlebnis, wenn sie zum ersten Mal nach etlichen Fehlversuchen endlich das gewünschte Ergebnis auswirft. Und dann geht es erst richtig los - Optimierungen! Hier noch ein paar Zyklen, da noch etwas optimieren, einfach herrlich. Für mich ist das so entspannend wie für andere Leute im Garten zu puscheln oder Kreuzworträtsel zu lösen.
Assembler für den X86 ist (nach dem RISC-Assembler für den Archimedes) wirklich immer wieder eine Herausforderung - welcher Befehl geht mit welchen Registern, welche sind implizit, welche Kombi braucht wie lange, und das alles noch ohne MMX, SSE und wie sie alle heißen, die hab ich bisher noch nie angefasst. Das ist wirklich ein endloses Feld von Optimierungsmöglichkeiten. Etwas erschwert durch Auswirkungen wie Cache-Hits/Misses, Alignments von Daten und Routinen, Wait-States von RAM und Graphikkarte etc. Daher bin ich sehr froh, dass ich jetzt einen echten P90 zu Hause habe, mit dem ich testen kann (Danke nochmal an Matze97). Emulatoren sind immer nur soweit zu gebrauchen, dass man auf erste Lauffähigkeit testen kann, aber wenn es dann ans Eingemachte geht, geht nichts über echte Hardware.
Apropos Hardware: Ich bin mit Leib und Seele eine Software-Mensch, zur Not könnte ich wohl noch einen PC von Grund auf zusammenbauen, hab das früher mit meinen ersten PCs auch gemacht, aber ich kann mich nicht wirklich für die Schrauberei und Bastelei begeistern. Zum Glück gibt es genügend andere Leute, die das anders sehen und keine Angst vor einem Schraubendreher haben.
Zum Thema "Programmieren und das restliche Leben": Ich habe meine Leidenschaft zu meinem Beruf gemacht, bin Software-Entwickler und verdiene damit schon seit 25 Jahren mein Geld. War zwischenzeitlich mal selbständig, aber das war nichts für mich, bin seit ein paar Jahren wieder Angestellter und sehr glücklich und zufrieden damit.
Meine Lebensgefährtin weiß, dass ich ein Computer-Verrückter bin und durchaus eine erkleckliche Anzahl von Stunden auch zu Hause am PC verbringen möchte und akzeptiert das. Wir haben ein wie ich finde schönes Gleichgewicht gefunden zwischen gemeinsamen Aktivitäten (na, na, na, wer grinst da so ;-) ) und Zeiten, in denen man für sich was macht, das klappt ganz gut. Aber genügend Zeit hat man eh nie, könnte noch viel mehr Zeit am PC verbringen - andererseits sind Dinge ja häufig deswegen um so schöner, weil man eben nicht beliebig viel Zeit dafür hat, sondern sich die Zeit irgendwo abknapsen muss.
Wieder zurück zum Thema VESA-Graphikroutinen: Ich hab mich bewusst gegen die 320x200 Auflösung entschieden, weil ich die für eher textlastige Spiele als einfach zu gering empfinde. Ich spiele gern Rollenspiele, vor allem so schöne Oldschool-Spiele mit runden basierten Kämpfen und tilebased (kachelbasiert klingt einfach nicht...) Welten. Da geht es dann im allgemeinen immer darum, noch bessere Waffen und Rüstungen zu bekommen mit immer tolleren Extras und Werten - und sowas lässt sich bei 320x200 nicht so gut darstellen, bei 640x480 schon eher. Bis dahin habe ich noch einen weiten Weg mit meinen Routinen zu gehen, aber ein Anfang ist gemacht. Meine Spiele werden definitiv auch immer bestenfalls "fertig", aber nie fertig. Die restlichen 10 oder 20% machen meist keinen Spaß mehr sondern fühlen sich eher wie Arbeit, zumindest aber wie Hausaufgaben an, da verlässt mich die Motivation für private Projekte doch recht schnell. Und was immer fehlt ist Sound - da habe ich einfach keinen Zugang zu. Ok, meine Graphiken sind auch nie hübsch und meistens nur irgendwo anders her geholt (ich habe im Laufe der Jahre diverse RPG-Maker angesammelt, die alle hübsche Tilesets mitbringen), aber die könnte ich notfalls und mit viel Geduld noch irgendwie mit Bordmitteln hinbringen, aber bei Sound und Musik verlässt es mich total, da habe ich einfach kein Ohr und kein Gefühl für.
Und was die Zielgruppe angeht, da habe ich schon vor einiger Zeit aufgehört, mir Gedanken drum zu machen. Ich bringe es bei mir zum Laufen, ob es dann woanders auch läuft, ist mir relativ egal, einfach weil ich weiß, dass das Programm zu 99,9% meinen PC nie verlassen wird. So wie jetzt, wo ich für DOS und VESA 2.0 im Flat Real Mode programmiere - das wird außer einer handvoll Enthusiasten eh keiner mehr bei sich auf richtiger Hardware so zum Laufen bringen. Bliebe noch die DOSBox, aber seien wir mal ehrlich, da kann man dann auch zu einer Riesenauswahl an kommerzieller Software für wenig Geld greifen, dank GoG und Humble wird man ja geradezu dicht geworfen damit - da sind die Chancen, dass mein kleines Heimprojekt irgend wen anspricht auch eher gering. Aber das stört mich auch nicht, dafür kann mich hier mit ein paar Gleichgesinnten auszutauschen, das macht für mich den Reiz des Retro-Computing aus.
Ich kann inzwischen auf dem Computer Dinge tun, die vor 25 Jahren "cooler Kram" gewesen wären. Aber die Zeit schreitet voran und ich mag (und mache) immer noch die Dinge von vor 25 Jahren... (So dass der einzige, der das vielleicht noch "ein wenig cool" findet, wohl nur ich selbst bin...)
Aber nicht doch, mir geht es genauso und damit sind wir schon 2 :peanutbutterjellytime:
Du siehst, bei dem Thema gerate ich auch ins Schwärmen und Schwafeln, ich breche das hier lieber erstmal ab, sonst komme ich noch vom Hundertsten ins Tausendste...
Benutzeravatar
matze79
DOS-Gott
Beiträge: 7910
Registriert: So 9. Sep 2012, 20:48

Re: VESA Graphikroutinen in Assembler

Beitrag von matze79 »

Ich würde dir wenn du dennoch mal einen Emulator benutzt zu qemu raten mit DOS.

Der ist sehr akurat wenn du 100% Emulation wählst, aber eben langsam also keine Virtual QEMU CPU wählen sondern z.B. -cpu 486 / pentium oder was auch immer.
https://www.shadowcircuit.de - Die kleine Community rund um Retro Computing
https://www.retroianer.de
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: VESA Graphikroutinen in Assembler

Beitrag von DOSferatu »

Schlowski hat geschrieben:Na dann hole ich auch mal etwas aus - leicht Off-Topic, aber ich denke mal, der Thread-Ersteller wird sich nicht beschweren
Ja, ich denke, das wird schon in Ordnung gehen.
Schlowski hat geschrieben:Seit ich 1981 das erste mal an einem PET 2001 gesessen habe und das obligatorische

Code: Alles auswählen

10 PRINT "HALLO"
20 GOTO 10
zum Laufen gebracht habe, bin ich dem Programmier-Virus verfallen.
Bei mir war es erst ein Buch über Computer und BASIC-Programmierung.
Schlowski hat geschrieben:Im Laufe der Jahre hab ich mich von einem VC-20 über einen C-64, Apple-II (Clone), Atari ST, Amiga 500, Acorn Archimedes schließlich zum PC hin entwickelt.
Ich stamme aus dem Ostteil. Zuerst war ich 3 Jahre lang in einer AG Computer, einmal die Woche (Donnerstags) bin ich nach der Schule da extra mit dem Zug hingefahren. Ich habe immer zu Hause schon Programme auf Papier vorgeschrieben, damit ich sie vor Ort nur noch einzugeben brauchte.
Das waren KC85/1, monochrom, an diesen "Junost" Fernsehern, mit Kassettenrekordern zum Speichern/Laden.
Einen ersten eigenen Computer (KC85/4, 24 Farben (eigentlich 23)) bekam ich dann 3 Jahre später geschenkt. Computer waren so wahnsinnig teuer.
Schon ein Jahr später wurde es dann ein C64 (die "Wende" war schon durch), inklusive Monitor, Drucker, Floppydisklaufwerk.
Am PC programmiert habe ich dann erstmal auf dem Gymnasium, in dem, was man da so hochtrabend als das Fach "Informatik" bezeichnet hatte. (Ich und 2 andere Leute hatten mehr Ahnung als der Lehrer - die anderen Schüler konnten nicht mal tippen...) Das waren 286er, monochrom, an Bernsteinfarbe-Monitoren. Da habe ich mein erstes PC-Spiel (als "Projekt") gemacht... Raumschiffshooter in Textmode.... Mann war das eine Grütze. Ich habe aber eine 1+ bekommen...
Schlowski hat geschrieben: Mein erster war ein 286er mit 10Mhz, 1MB RAM, Hercules-Graphikkarte und 20MB Festplatte, danach hatte ich alles vom 386er über 486er und die diversen Pentiums bis zum heute aktuellen Core-i7.
Zu Hause habe ich weiterhin auf C64 programmiert, bis Ende 1996 mein erster eigener PC dazukam. Ein Kumpel hat mir den aus alten Ersatzteilen zusammengebastelt (ich wollte meine am C64 selbst programmierte RS232-Schnittstelle mti 38400 Baud mal "gegentesten"). Es war ein 286er, glaub 10 MHz (weiß nicht mehr), mit 40 MB Festplatte, Original VGA-Grafikkarte (0,5 MB/s Datendurchsatz...) und ohne Soundkarte. Ich habe auf dem Ding sogar Monkey Island 1+2 durchgespielt - mit Tastatur und PC-Speaker! Maus kannte ich nicht. Bin auch heute noch nicht SO der Maus-Typ, weil mit Tastatur großgeworden.
Das wurde dann irgendwann ein 486er, erst 66, dann 100, jetzt aktuell 133 MHz und ein sehr schnelles Board. Grafikkarte ist jetzt eine bessere VGA+VESA Karte (Horizon64, mit einem ET4000 Chip). Soundkarte ist aktuell SB AWE64. Abgesehen von ein paar "Kleinteilen" habe ich noch nie irgendeinen PC irgendwo gekauft - meine ganzen Rechner sind Gebrauchtware, aus Ersatzteilen zusammengebaut. Inzwischen habe ich einen Kumpel, bei dem auf Arbeit öfter mal sowas abfällt und der baut mir daraus dann sowas zusammen.
Selbst mein Windows-Rechner ist nicht gerade ein aktuelles Modell.
Ich benutze da auch immer noch Windows XP (32bit). Wieso? Weil bei allem darüber keine 16bit-DOS-Programme mehr laufen. Sowas ist nicht verhandelbar.
Schlowski hat geschrieben: Und immer, wirklich auf jeder Kiste, hab ich mich mit Assembler und Graphikroutinen beschäftigt, hab sogar ein paar Spiele fertiggestellt, aber immer nur für den privaten Bereich. Ich liebe es einfach, sowas wie eine Textausgaberoutine in Assembler zu erstellen. Das Erfolgserlebnis, wenn sie zum ersten Mal nach etlichen Fehlversuchen endlich das gewünschte Ergebnis auswirft. Und dann geht es erst richtig los - Optimierungen! Hier noch ein paar Zyklen, da noch etwas optimieren, einfach herrlich. Für mich ist das so entspannend wie für andere Leute im Garten zu puscheln oder Kreuzworträtsel zu lösen.
So geht es mir auch. Textausgaben in Grafikmode, Patterngrafik (also diese "tilebased"), Sprites...
Ich habe auch ein Format für Proportionalschrift entwickelt. Später auch erweitert um "4farbig" (also 3 Farben plus Hintergrund), hauptsächtlich, damit man die Schrift "weichzeichnen" kann (runde Stellen an Buchstaben wie O). Und natürlich die dazugehörigen Ausgaberoutinen gebaut (sonst würde es ja keinen Sinn machen).
Auf meine Sprites (obwohl in Pascal+ASM hybrid gemacht und die Routinen von 2004 sind und ich die eigentlich auch mal "neu machen" könnte) bin ich ein bißchen stolz:
Spritegrößen 1x1 bis 255x255, in jeder Kombination (also auch 74x113 oder so).
Entweder 16 (aus 256) oder 256 Farben (16-farbige brauchen nur halb soviel Speicher, klar)
Nutzen alternativer Paletten für die Farben.
Spiegeln in X- und Y-Richtung
Verkleinern/Vergrößern in 65536 Stufen (Beispiel: 256 = 1:1, somit 32 = 1/8, 1024 = 4x, ...)
"Zerren", um bei "kummen Auflösungen" (also die keine 1:1 Ratio haben) auszugleichen.
(Kann aber auch allgemein zum Zerren benutzt werden.)
Drehen in 256 Stufen (also 64 = 90°, 128 = 180")
Möglichkeit halbtransparenter Pixel in (theoretisch) 256 Stufen.
Optional 16-stufiges Dithern, um (gerade bei Vergrößerung) keine Quadratpixel zu haben, sondern geditherte Farbverläufe.
Optional Sprites "hinter" einer der Hintergrundebenen legen, so daß sie teilweise verdeckt werden.
(Das alles immer noch im 256-Farb-Mode.)
Eigentlich fällt mir, außer den Dingen, die meine Sprites sowieso schon können, kaum noch etwas ein, was man sonst noch mit Sprites anstellen könnte.
Passend zu den Sprites habe ich auch noch "Level-Routinen" gemacht, mit bis zu 4 hintereinanderliegenden (tilebased) Ebenen, die unabhängig voneinander bewegt werden können (eigentlich für Parallaxing gedacht, was die "Grundeinstellung" ist), ebenfalls mit der Option "halbtransparenter" Pixel.
Schlowski hat geschrieben: Assembler für den X86 ist (nach dem RISC-Assembler für den Archimedes) wirklich immer wieder eine Herausforderung - welcher Befehl geht mit welchen Registern, welche sind implizit, welche Kombi braucht wie lange, und das alles noch ohne MMX, SSE und wie sie alle heißen, die hab ich bisher noch nie angefasst. Das ist wirklich ein endloses Feld von Optimierungsmöglichkeiten. Etwas erschwert durch Auswirkungen wie Cache-Hits/Misses, Alignments von Daten und Routinen, Wait-States von RAM und Graphikkarte etc.
Ja, mit so Kram murks ich auch rum. Die bekannte "ASM86FAQ.TXT" ist mir dabei eine große Hilfe - da kann man öfter mal Zyklen nachschlagen oder, wenn man mal wieder 386er-Befehle braucht, die Byte-Opcodes dafür ermitteln.
Schlowski hat geschrieben: Daher bin ich sehr froh, dass ich jetzt einen echten P90 zu Hause habe, mit dem ich testen kann (Danke nochmal an Matze97). Emulatoren sind immer nur soweit zu gebrauchen, dass man auf erste Lauffähigkeit testen kann, aber wenn es dann ans Eingemachte geht, geht nichts über echte Hardware.
Genauso ist es. Ich programmiere ja auch immer noch direkt auf meinem 486er.
Schlowski hat geschrieben: Apropos Hardware: Ich bin mit Leib und Seele eine Software-Mensch, zur Not könnte ich wohl noch einen PC von Grund auf zusammenbauen, hab das früher mit meinen ersten PCs auch gemacht, aber ich kann mich nicht wirklich für die Schrauberei und Bastelei begeistern. Zum Glück gibt es genügend andere Leute, die das anders sehen und keine Angst vor einem Schraubendreher haben.
So geht's mir auch. Ich finde es derzeit ein wenig schade, daß das DOSforum in letzter Zeit sehr "hardwarelastig" geworden ist. Nicht, daß ich etwas gegen Hardware hätte - die wird ja gebraucht. Aber mein Interessenbereich konzentiert sich doch mehr auf Software (und da auch mit Schwerpunkt Programmierung) und im Softwarefeld geht es hier auch mehr um Benutzen (Spielen/Anwenden) als um Selbermachen. Das macht es etwas schwerer, "Gleichgesinnte" zu finden, die wirklich noch auf der originalen Hardware originale Software bauen.
Schlowski hat geschrieben: Zum Thema "Programmieren und das restliche Leben": Ich habe meine Leidenschaft zu meinem Beruf gemacht, bin Software-Entwickler und verdiene damit schon seit 25 Jahren mein Geld. War zwischenzeitlich mal selbständig, aber das war nichts für mich, bin seit ein paar Jahren wieder Angestellter und sehr glücklich und zufrieden damit.
Naja - beruflich könnte ich das nicht machen. Beim Programmieren bin ich nur dann wirklich gut, wenn mich das, was ich mache, auch interessiert. Im beruflichen Bereich müßte ich ja unter Windows & Co arbeiten und mit neuen komischen Methoden. Und nach Vorgaben zu programmieren würde mich auch in meiner Kreativität beschneiden. Und weil Programmieren zu den wenigen Dingen gehört, die mir noch Spaß machen, will ich bewußt vermeiden, etwas zu machen, was mir das auch noch verleidet.
Das einzige, was mich heute noch an aktueller Programmierung interessieren könnte, wäre so "Systemprogrammierung", also wenn für irgendwelche Geräte, die mit kleinen Chips mit wenig Speicher oder so auskommen sollen, in Assembler so Microcontroller o.ä. zu programmieren wäre.
Schlowski hat geschrieben: Meine Lebensgefährtin weiß, dass ich ein Computer-Verrückter bin und durchaus eine erkleckliche Anzahl von Stunden auch zu Hause am PC verbringen möchte und akzeptiert das. Wir haben ein wie ich finde schönes Gleichgewicht gefunden zwischen gemeinsamen Aktivitäten (na, na, na, wer grinst da so ;-) ) und Zeiten, in denen man für sich was macht, das klappt ganz gut.
Ich habe keine Lebensgefährtin. Ich kann mir überhaupt nicht vorstellen, mit einem anderen Menschen zusammenzuleben. Ich kann mit den meisten anderen Menschen irgendwie überhaupt nichts anfangen.
Schlowski hat geschrieben: Aber genügend Zeit hat man eh nie, könnte noch viel mehr Zeit am PC verbringen - andererseits sind Dinge ja häufig deswegen um so schöner, weil man eben nicht beliebig viel Zeit dafür hat, sondern sich die Zeit irgendwo abknapsen muss.
Das mag ja sein - aber wenn ich zwar Zeit habe, dann aber müde und unkonzentriert bin und trotzdem versuche, etwas Sinnvolles zu programmieren, schleichen sich da Fehler ein, die mir im "wachen" Zustand nie passiert wären. Und wenn ich dann wirklich mal Zeit UND Kraft habe, kann ich nichts neue programmieren, sondern bin damit beschäftigt, Zeug zu debuggen, das ich im o.g. halbkomatösen Zustand fabriziert habe - eine sinnlose Zeitverschwendung, die ich mir sparen will.
Allerdings trifft der Zustand Zeit UND Kraft bei mir immer seltener zusammen. Meine ganze Kraft wird von meinem derzeitigen Job aufgefressen, so daß ich selbst an Wochenenden meist zu müde und fertig bin und "Rücken habe".
Schlowski hat geschrieben: Wieder zurück zum Thema VESA-Graphikroutinen: Ich hab mich bewusst gegen die 320x200 Auflösung entschieden, weil ich die für eher textlastige Spiele als einfach zu gering empfinde.
Ich liebe diese geringen Auflösungen aus mehreren Gründen. Einmal, weil natürlich die MODE-X Sachen einiges an Geschwindigkeit rausholen können durch spezielle Fummelei. Dann natürlich, weil man weniger Pixel braucht, um "eine Fläche zu füllen". Und dann auch, weil ich Spiele im Stil der späteren C64-Spiele und der SNES-Ära mag, auch wegen ihres Designs.
Schlowski hat geschrieben: Ich spiele gern Rollenspiele, vor allem so schöne Oldschool-Spiele mit runden basierten Kämpfen und tilebased (kachelbasiert klingt einfach nicht...) Welten. Da geht es dann im allgemeinen immer darum, noch bessere Waffen und Rüstungen zu bekommen mit immer tolleren Extras und Werten - und sowas lässt sich bei 320x200 nicht so gut darstellen, bei 640x480 schon eher.
Darin unterscheiden wir uns. Mit Rollenspielen konnte ich noch nie irgend etwas anfangen, für mich eher langweilig. Ich mag "Action"lastige Spiele wie Jump'n'runs (Mario, Giana), Shoot'em'ups (R-Type, Katakis) , dann so Kombinationen aus beidem (Turrican, Earthworm Jim) - und dann natürlich noch Adventures (die einzige Art von Spiel, wo ich eine Maus als Eingabeeinheit akzeptiere, da wären natürlich alle Sachen von Lucas Arts/Lucasfilm Games zu nennen).[/quote]
Schlowski hat geschrieben: Bis dahin habe ich noch einen weiten Weg mit meinen Routinen zu gehen, aber ein Anfang ist gemacht. Meine Spiele werden definitiv auch immer bestenfalls "fertig", aber nie fertig. Die restlichen 10 oder 20% machen meist keinen Spaß mehr sondern fühlen sich eher wie Arbeit, zumindest aber wie Hausaufgaben an, da verlässt mich die Motivation für private Projekte doch recht schnell.
Erstaunlich, wie ähnlich wir uns in vielen Dingen sind.
Es ist einfach so: Wenn die "schweren Sachen" gemacht sind und der Rest nur noch "Handwerkszeug" (von dem man sowieso weiß, daß man's kann), ist die Herausforderung weg - kein Rumfrickeln, keine Kreativität mehr, nur noch "fertig machen". Da hätte man dann gern einen Assi, der den Kram einfach noch "zusammenbaut und n Schleifchen drum macht".
Schlowski hat geschrieben:Und was immer fehlt ist Sound - da habe ich einfach keinen Zugang zu.
Ja, das ist haargenau wie bei mir! Fast alle meine PC-Games sind total still, habe nur 2 gemacht, die (SPEAKER!) Sound haben (mehrstimming, mit demselben "Trick", der bei XENON 2 benutzt wird, nur bei mir etwas "flüssiger" umgesetzt).
Ich habe mich immer eher als Programmierer gesehen und in Grafikprogrammierung bin ich einfach irgendwie besser.
Aber weil ich dies immer als störendes Problem angesehen habe, habe ich mich vor einigen Monaten (ja, leider MONATEN schon wieder) durchgerungen, eine Sound-Engine zu bauen. Sie ist zu 99,9% fertig in der ersten Version (Mono, ohne Filter). Ich will nur den einen Befehl noch irgendwann fertigmachen.
Der dazugehörige "Tracker" (so richtig "trackermäßig" ist er leider nicht, weil meine Musiken eher aussehen wie eine Art Assemblersprache) ist auch schon recht brauchbar, aber noch lange nicht fertig. Und ich werde mich wohl irgendwann breitschlagen lassen, auch noch einen alternativen Eingabemodus zu bauen, der dann (nach außen) wie ein Tracker wirkt (die internen Daten bleiben gleich), damit VIELLEICHT Leute, die etwas mehr Ahnung von Musik haben als ich auch bereit wären, mit dem Ding mal Musiken für meine Spiele zu machen. Meine eigenen "Kunstwerke" sind auch eher so "formelhaft", ich mache Musik wie ein Mathematiker...
Die Soundengine ist direkt für die Nutzung in Spielen konzipiert, z.B. mit einem "Interface", um Musiken und Soundeffekte zu starten/mischen. Insgesamt 16 Stimmen, ich denke, das reicht. Eine Besonderheit ist, daß es sowohl digitale Klangsynthese als auch Samples gleichzeitig nutzen kann - bei ersterem habe ich mich etwas an den Fähigkeiten des SID (C64-Soundchip, falls das WIRKLICH jemand nicht weiß...) orientiert - das heißt: Ja, es gibt programmierbare Hüllkurven.
Schlowski hat geschrieben: Ok, meine Graphiken sind auch nie hübsch und meistens nur irgendwo anders her geholt (ich habe im Laufe der Jahre diverse RPG-Maker angesammelt, die alle hübsche Tilesets mitbringen), aber die könnte ich notfalls und mit viel Geduld noch irgendwie mit Bordmitteln hinbringen,
Zum TESTEN meiner gebauten Grafikprogramme (Malprogramme, Level-/Spritebuilder) nehme ich schonmal irgendwelche Grafiken aus irgendwelchen Bildern. Aber ich kam noch nie auf die Idee, fremde Grafiken in eigenen Projekten zu verwenden. Meine Grafikfähigkeiten sind, naja. eher so "mittel". Auf einer Skala von 0 bis 15 (mit 0 = Strichmännchen und 15 = DaVinci oder wasweißich) würde ich mich bei 5-6 sehen, kommt drauf an, wie ich in Form bin und WAS gezeichnet werden soll. Bei TIEREN bin ich z.B. total schlecht, habs noch nie in meinem Leben geschafft, ein Pferd zu zeichnen. Gegenstände und Menschen (oder irgendwelche Monster) krieg ich inzwischen recht brauchbar hin.
Schlowski hat geschrieben: aber bei Sound und Musik verlässt es mich total, da habe ich einfach kein Ohr und kein Gefühl für.
Naja, bei Sound lasse ich mich manchmal inspirieren von Sachen, die ich gern höre - obwohl ich zu den (wenigen) Menschen gehöre, die so gut wie nie Musik hören. In meiner Bude ist nie irgend ein musikerzeugendes Ding an, während ich etwas anderes mache. Und wenn ich WIRKLICH mal Musik höre, dann höre ich NUR Musik - ohne etwas anderes zu machen. Ich bin wie DOS: Alt und kein Multitasking.
Schlowski hat geschrieben: Und was die Zielgruppe angeht, da habe ich schon vor einiger Zeit aufgehört, mir Gedanken drum zu machen. Ich bringe es bei mir zum Laufen, ob es dann woanders auch läuft, ist mir relativ egal, einfach weil ich weiß, dass das Programm zu 99,9% meinen PC nie verlassen wird.
Naja, ich programmiere immer so, daß es auch auf anderen (DOS)-Rechnern mit anderen Grafikkarten noch läuft. Lauffähigkeit unter Windows (XP32bit)... ja, wenn es keine Umstände macht.
Die ET4000 hat teilweise so coole Tweaked Modes, daß ich es schade finde, daß diese nicht "allgemein" auf VGA-Karten funktionieren. Ich habe da mal einen 256-farbigen Textmode gefunden, den fand ich dermaßen geil, daß ich ihn am liebsten für ein Spiel benutzt hätte. Leider funktioniert er wohl nur auf der ET4000 (oder vielleicht auch anderen ETx000) so, auf anderen Grafikkarten sieht es komisch aus oder geht gar nicht.
Erklärung: Irgendwie so ÄHNLICH wie der "Multicolor" Mode beim C64:
zwei nebeneinanderliegenede Bits des Zeichens ergeben eine von 4 möglichen Farben. Die 4 Farben werden aus dem Farbbyte genommen. Wenn das Farbbyte den Code $4C enthält (also normal Hintergrund=$4, Schrift=$C), wird daraus in diesem Mode das:
Bitkombi Farbe
00 $CC
01 $C4
10 $4C
11 $44
D.h. es sind die Farben $CC, $C4, $4C und $44 aus der gesetzten 256-Farbpalette möglich! Diese kann man in diesem Mode auch setzen, so als wäre man im Grafikmode.
Wenn man die Palette geschickt verwendet, könnte man damit ein total schickes Spiel IM TEXTMODE machen (die meisten C64-Spiele sind ja auch im Textmode, fällt mit modifiziertem Zeichensatz und Multicolor nur nicht mehr so auf). Da auch die VGA-Karte, genau wie VIC (C64-Grafikchip) diese "Softscroll"-Register hat, mit denen man das Bild pixelweise verschieben kann, könnte man.... Ach ja, was man nicht alles könnte...
Schlowski hat geschrieben: So wie jetzt, wo ich für DOS und VESA 2.0 im Flat Real Mode programmiere - das wird außer einer handvoll Enthusiasten eh keiner mehr bei sich auf richtiger Hardware so zum Laufen bringen.
Also bei mir würde es wohl mit an Sicherheit grenzender Wahrscheinlichkeit laufen. Meine Kiste ist ja quasi geradezu ideal dafür.
Schlowski hat geschrieben: Bliebe noch die DOSBox, aber seien wir mal ehrlich, da kann man dann auch zu einer Riesenauswahl an kommerzieller Software für wenig Geld greifen, dank GoG und Humble wird man ja geradezu dicht geworfen damit - da sind die Chancen, dass mein kleines Heimprojekt irgend wen anspricht auch eher gering.
Ja, genau das finde ich auch. Und den Leuten, für die das nur "Retro" und eine Modeerscheinung ist (und die sowieso jede Modeerscheinung mitmachen) ist es ja der Mühe nicht wert, das RICHTIGE Zeug zu haben, sondern es reicht denen, wenn es auf ihrer ultra-überkandidelten Hardware so AUSSIEHT - also daß ein 2D-Jump'n'Run zwar so aussieht wie anno 1988, aber im Gegensatz zu 1988 dafür heute 3 GHz Quadcore CPU und 8 GB RAM braucht... - (also wenn ich SO "Coden" würde, würd ich mich schämen, mich Programmierer zu nennen...)
Schlowski hat geschrieben: Aber das stört mich auch nicht, dafür kann mich hier mit ein paar Gleichgesinnten auszutauschen, das macht für mich den Reiz des Retro-Computing aus.
Naja, mir geht's nicht um "Retro". Retro wäre es für mich, wenn ich es früher mal gemacht, dann aufgehört und jetzt aus nostalgischen Gründen wieder damit angefangen hätte mit einem "guck mal wie komisch das damals alles war" Gefühl. Aber ICH habe ja nie wirklich damit aufgehört - bin all die Jahre ja dabeigeblieben (bei meinem alten Sch...-- Kram).
Schlowski hat geschrieben:
Ich kann inzwischen auf dem Computer Dinge tun, die vor 25 Jahren "cooler Kram" gewesen wären. Aber die Zeit schreitet voran und ich mag (und mache) immer noch die Dinge von vor 25 Jahren... (So dass der einzige, der das vielleicht noch "ein wenig cool" findet, wohl nur ich selbst bin...)
Aber nicht doch, mir geht es genauso und damit sind wir schon 2
Ja, es gibt bestimmt auch noch mehr. Wir unterscheiden uns zwar in einigen wenigen Dingen, aber im Allgemeinen sind wir uns in vielen Dingen recht ähnlich. Sogar in den verwendeten Sprachen: Pascal und Assembler.
Gibt es eigentlich irgendeine Stelle, wo man von Dir programmiertes "Zeug" (Spiele, Tools, Testprogramme) herunterladen kann? Ich interessiere mich immer für die Arbeit meiner "Programmiererkollegen", vor allem natürlich im DOS-Bereich.
Schlowski hat geschrieben:Du siehst, bei dem Thema gerate ich auch ins Schwärmen und Schwafeln, ich breche das hier lieber erstmal ab, sonst komme ich noch vom Hundertsten ins Tausendste...
Ja, auch das haben wir gemeinsam...
Schlowski
Solitärspieler
Beiträge: 13
Registriert: Do 2. Jul 2015, 19:40

Re: VESA Graphikroutinen in Assembler

Beitrag von Schlowski »

Auf meine Sprites (obwohl in Pascal+ASM hybrid gemacht und die Routinen von 2004 sind und ich die eigentlich auch mal "neu machen" könnte) bin ich ein bißchen stolz:
Spritegrößen 1x1 bis 255x255, in jeder Kombination (also auch 74x113 oder so).
Entweder 16 (aus 256) oder 256 Farben (16-farbige brauchen nur halb soviel Speicher, klar)
Nutzen alternativer Paletten für die Farben.
Spiegeln in X- und Y-Richtung
Verkleinern/Vergrößern in 65536 Stufen (Beispiel: 256 = 1:1, somit 32 = 1/8, 1024 = 4x, ...)
"Zerren", um bei "kummen Auflösungen" (also die keine 1:1 Ratio haben) auszugleichen.
(Kann aber auch allgemein zum Zerren benutzt werden.)
Drehen in 256 Stufen (also 64 = 90°, 128 = 180")
Möglichkeit halbtransparenter Pixel in (theoretisch) 256 Stufen.
Optional 16-stufiges Dithern, um (gerade bei Vergrößerung) keine Quadratpixel zu haben, sondern geditherte Farbverläufe.
Optional Sprites "hinter" einer der Hintergrundebenen legen, so daß sie teilweise verdeckt werden.
(Das alles immer noch im 256-Farb-Mode.)
Eigentlich fällt mir, außer den Dingen, die meine Sprites sowieso schon können, kaum noch etwas ein, was man sonst noch mit Sprites anstellen könnte.
Passend zu den Sprites habe ich auch noch "Level-Routinen" gemacht, mit bis zu 4 hintereinanderliegenden (tilebased) Ebenen, die unabhängig voneinander bewegt werden können (eigentlich für Parallaxing gedacht, was die "Grundeinstellung" ist), ebenfalls mit der Option "halbtransparenter" Pixel.
Mmh, lecker :-) Da könnte ich auch noch ein paar Sachen von bei mir umsetzen... Ich befürchte nur, dass das bei meiner "Wunschauflösung" nicht mehr für ein Echtzeit-Rendering reicht, hab jetzt schon das Problem, dass ich für das Rendern eines kompletten Bildschirms 2 VBLs brauche. Ich bin momentan echt hin- und hergerissen, ob ich nicht doch Abstriche bei der Auflösung machen muss, aber vielleicht fällt mir ja noch was Geniales ein. Es ändert sich ja fast nie der gesamte Bildschirm auf einmal, da könnte man sicherlich noch was mit dirty rectangles oder so lösen. Da bin ich nur gerade nicht motiviert, das hab ich schon mal gemacht und es hat mir schon damals nicht wirklich Spaß gemacht.
Allerdings trifft der Zustand Zeit UND Kraft bei mir immer seltener zusammen. Meine ganze Kraft wird von meinem derzeitigen Job aufgefressen, so daß ich selbst an Wochenenden meist zu müde und fertig bin und "Rücken habe".
Solche Phasen kenne ich, da wünsche ich Dir einfach mal, dass das in Zukunft wieder besser wird. Ist schon so, dass man zum Programmieren wach und aufmerksam sein sollte, die Fälle von abendlichem, stundenlangen und erfolglosen Suchen nach Fehlern, die am nächsten Morgen durch einen Blick gefunden werden, kenne ich auch zur Genüge.
Darin unterscheiden wir uns. Mit Rollenspielen konnte ich noch nie irgend etwas anfangen, für mich eher langweilig. Ich mag "Action"lastige Spiele wie Jump'n'runs (Mario, Giana), Shoot'em'ups (R-Type, Katakis) , dann so Kombinationen aus beidem (Turrican, Earthworm Jim)...
Shoot'em Ups mag ich auch, hab auch mal welche programmiert für den Atari ST und den PC (unter Windows), aber die haben einfach keine Langzeitmotivation für mich. Ebenso wie die ganzen Platformer, ich mag das Herumlaufen und Springen und Rätsel lösen, aber nur bis zu einem gewissen Grad, wenn ich zum x-ten Mal an einer dreifach Kombi von pixelgenau abzustimmenden Sprüngen unter Umgehung von gefühlten drei Dutzend Gegnern gescheitert bin, ist das Spiel bei mir gescheitert und landet im Papierkorb. Da stehe ich dann doch eher auf Aufbau- und Strategiespiele, liegt vielleicht auch am Alter, ich bin einfach nicht mehr so reaktionsschnell wie früher :ugeek:
Meine Grafikfähigkeiten sind, naja. eher so "mittel". Auf einer Skala von 0 bis 15 (mit 0 = Strichmännchen und 15 = DaVinci oder wasweißich) würde ich mich bei 5-6 sehen
Und ich liege da eher zwischen 1 und 2. Ein Schwert bekomme ich noch hin, aber schon bei Kleidung verlässt es mich. Von Menschen, Monstern und Mutationen mal ganz zu schweigen. (Mutationen sind das auf alle Fälle immer, egal, was es eigentlich darstellen sollte :lol: ) Da nehme ich dann doch lieber Sachen von Leuten, die etwas darüber liegen, dann kann ich mich, statt Stunden mit dem Pixeln unkenntlicher Sachen zu verbringen, lieber mit meinem Programm beschäftigen. Zeit ist kostbar und man muss einfach auch mal akzeptieren, wo die eigenen Grenzen liegen.
Naja, ich programmiere immer so, daß es auch auf anderen (DOS)-Rechnern mit anderen Grafikkarten noch läuft. Lauffähigkeit unter Windows (XP32bit)... ja, wenn es keine Umstände macht.
So ist es bei prinzipiell mir auch, ich lass das ja auf zwei DOS-Rechnern, in der DOSBox und im PCEm laufen, um zumindest eine etwas größere Abdeckung an Hardware zu erreichen. Aber letztendlich ist es mir nur wichtig, dass es bei mir läuft. Ich hab aber im Laufe der Jahre festgestellt, dass ich selten so schmutzige Tricks anwende, dass irgendetwas nur auf einer ganz bestimmten Hardware(-Kombination) läuft, das ist mir grundsätzlich zuwider. andererseits gibt es gerade bei PCs so unendlich viele Kombinationen von Hard- und Software, dass es schon garantiert ist, dass es irgendwo nicht läuft. Das ist uns selbst mit einfachster Windows-Anwendungs-Software passiert, die wir geschrieben haben, da gibt es die unglaublichsten Seiteneffekte.
Gibt es eigentlich irgendeine Stelle, wo man von Dir programmiertes "Zeug" (Spiele, Tools, Testprogramme) herunterladen kann? Ich interessiere mich immer für die Arbeit meiner "Programmiererkollegen", vor allem natürlich im DOS-Bereich.
Ist alles im Laufe der Zeit verlorengegangen, das einzige, was übriggeblieben ist, ist mein BasEdit.Net, das Cross-Editier-Tool für Commodore Basic Programme - aber das ist auch mehr ein Hack als eine Software-Perle, da würde ich heute einige Dinge anders machen, das war noch zu meiner Lernphase von .Net-Programmierung. An manchen Stellen gruselt es mich heute, wenn ich das im Source sehe.
Wenn ich meine Routinen hier "fertig" habe, kann ich die aber gern mal zur Verfügung stellen - Du kannst dann sicherlich noch viele Optimierungs-Tipps geben, die mir entgangen sind, bin ja doch auch schon etwas eingerostet, was das angeht. Zwischendrin fällt mir immer mal das eine oder andere wieder ein, aber das ist noch ordentlich Potential drin, da bin ich sicher :-)
Antworten