Grafikprogrammierung

Hallo, ich interessiere mich für die Spieleentwicklung in den 80er.
Da gab es ja kein Directx oder Opengl.
Ich frage mich, ob es möglich wäre ein Spiel ohne Directx oder Opengl zu programmieren?

Gruß

Tori

tori1117 schrieb:

Ich frage mich, ob es möglich wäre ein Spiel ohne Directx oder Opengl zu programmieren?

Zum Vergrößern anklicken....

Ja warum nicht
Es dafür gibt es Flash, HTML, Java, BASIC, C++ und was weiss ich noch für Script und Programiersprachen

DirectX und OpenGL sind nur Schnittstellen (API) zwischen der Grafikarte, Soundkarte, IO Geräte und der Software. Diese sind nicht essentiell, erleichtern aber System und Architekturübergreifende Anpassungen. Diese Sachen haben mit der eigentlichen Spielprogrammierung nichts zu tun.

Wurden die Spiele in den 80ern nicht hauptsächlich per Software Rendering berechnet? Grafikkarten dienten doch nur zur Darstellung der Bilder, nicht der berechnung. Ich würde an deiner stelle vielleicht für den Anfang HTML5+Javascript nutzen.

Zur Zeit der 8-bit Homecomputer wurden grafisch anspruchsvollere Spiele in Assembler programmiert - einfache Spiele auch manchmal in BASIC. Manche Computer hatten Video Controller, die bspw. ermöglichten mit sogenannten Sprites interessantes anzustellen oder generell - für damalige Verhältnisse außerordentlich anspruchsvolle - grafische Effekte umzusetzen (Stichwort: Demoszene). Für den Einstieg ist etwa die deutschsprachige Webseite retro-programming.de für C64 Assembler und Spieleprogrammierung sehr gut geeignet.

Infos über Video-Fähigkeiten der Commodore 8-bit Computer gibt es bspw. unter den Stichworten VIC bzw. VIC-II und C64.
Manche Homecomputer hatten andere Chips mit anderen Möglichkeiten (bessere Möglichkeiten boten etwa Amiga oder Atari ST).

Ich kann dir nur sagen, wie das unter MS-DOS im VGA-Modus aussah. Vom Prinzip her war es ganz einfach: Im Hauptspeicher gab es einen reservierten Bereich, 64000 Bytes groß - eins für jeden Pixel in der Auflösung von 320x200 bei 8 Bit Farbtiefe (256 Farben). Wenn man in diesen Speicherbereich hineinschrieb, dann erschienen die entsprechenden Pixel auf dem Schirm.

Der Nachteil an diesem System war, wie Bhaal3010 anmerkte, dass man auch alle Grafikberechnungen in Software auf der CPU ausführen musste. Lange Zeit war so nur einfache 2D-Grafik möglich. Erst Anfang der 90er wurden CPUs schnell genug für software-gerendertes 3D, und auch das zunächst nur mit extrem optimiertem Programmcode. Das (meines Wissens) erste Spiel, das diese Technik benutzte, war Wolfenstein 3D (1992).

tori1117 schrieb:

Ich frage mich, ob es möglich wäre ein Spiel ohne Directx oder Opengl zu programmieren?

Zum Vergrößern anklicken....

Bei den schon genannten 8-Bittern wurden veränderte Multicolor-Zeichensätze in den Bildspeicher geschrieben. Animiert wurden diese mit laufend Positionen überschreiben. Große bewegte Objekte wurden mit Sprites dargestellt. Dazu gab es Interrupt-Techniken, um dabei noch eine Hintergrundmusik etc zu ermöglichen.

Dies natürlich in Assembler. Nur eher gering animierte Spiele wie Kaiser und so konnten in BASIC erstellt werden. Allerdings wurde auch das Spiel 'Pirates' zu einem Teil in BASIC geschrieben, mit ergänzenden Assemblerroutinen.

Vielen Dank für die Antworten.
So wie es aussieht müsste ich z. B. auf einem C64 programmieren?
Mein Ziel ist es ein Pong Spiel zu schreiben, um zu verstehen die Grafikprogrammierung funktioniert.

Dadurch das du ein Pongspiel auf Hardware der 80er programmierst verstehst du nicht wie Grafikprogrammierung funktioniert. Das hat sich seit der Zeit komplett verändert. Wenn du von Grafikprogrammierung sprichst meinst du vermutlich Echtzeitgrafik. Zum Einstieg in das Thema würde ich empfehlen nach Bauchgefühl eine der zwei großen Renderpipelines zu wählen (OpenGL, DirectX) und dann mit einem Tutorial eine einfach Szene zu rendern, indem du schrittweise Shader hinzunimmst bzw. sie erweiterst. C/C++ wenigstens grundlegend zu können ist Voraussetzung.

Dadurch das du ein Pongspiel auf Hardware der 80er programmierst verstehst du nicht wie Grafikprogrammierung funktioniert. Das hat sich seit der Zeit komplett verändert.

Zum Vergrößern anklicken....

Mist hatte gedacht, dass wenn ich keine api benutze, ich ein Verständis bekomme wie die Grafikprogammierung funktioniert. Ich dachte die api wie OpenGL, DirectX nimmt einem die Arbeit ab und wollte dachinter schauen.

adebar17 schrieb:

Dadurch das du ein Pongspiel auf Hardware der 80er programmierst verstehst du nicht wie Grafikprogrammierung funktioniert. Das hat sich seit der Zeit komplett verändert. Wenn du von Grafikprogrammierung sprichst meinst du vermutlich Echtzeitgrafik. Zum Einstieg in das Thema würde ich empfehlen nach Bauchgefühl eine der zwei großen Renderpipelines zu wählen (OpenGL, DirectX) und dann mit einem Tutorial eine einfach Szene zu rendern, indem du schrittweise Shader hinzunimmst bzw. sie erweiterst.

Zum Vergrößern anklicken....

Das will er ja gerade nicht.

adebar17 schrieb:

C/C++ wenigstens grundlegend zu können ist Voraussetzung.

Zum Vergrößern anklicken....

Die Zeiten haben sich geändert. Du kannst OpenGL-Sachen machen, modellieren usw. ohne auch nir eine Zeile C++ anzuschauen. :-)

tori1117 schrieb:

Mist hatte gedacht, dass wenn ich keine api benutze, ich ein Verständis bekomme wie die Grafikprogammierung funktioniert. Ich dachte die api wie OpenGL, DirectX nimmt einem die Arbeit ab und wollte dachinter schauen.

Zum Vergrößern anklicken....

Ja. Nehmen sie auch in gewisserweise.
Wenn Du ganz grundlegende Mittel zur Grafikprogrammierung nehmen willst, darfst Du halt nur ne Funktion nutzen die ein Pixel setzt an die angegebene Bildschirmstelle und mit der angegebenen Farbe (ich weiß ja nicht, welche Programmiersprache Du nehmen willst; aber eigentlich bietet da jede solche Funktionalitäten irgendwie an).
Das erste, was man probieren kann ist dann eine gerade Linie zu ziehen. Man hat die Anfangskoordinanten und die Endkoordinaten und muss dann eben die Positionen der Pixel berechnen die dazwischen liegen, damit auf dem Bildschirm eine Linie erscheint.

Und so kann man sich eben weiter arbeiten und dann immer komplexere Objekte basteln. Und wenn sich ein Objekt (der Ball bei Pong) bewegt, heißt das ja im Klartext: Du musst den ursprünglichen Pong-Ball mit schwarzen Pixeln überschreiben, damit der nicht zu sehen ist und komplett an eine neue Position zeichnen.

Im Verlaufe dieses Lernprozesses werden wirst Du auf weitere Probleme stoßen. Zum Beispiel das die Bewegung Deines Pong-Balles sehr flackerig aussieht, weil er eben komplett gelöscht ist und dann wieder erscheint. Also wirst Du Dich damit beschäftigen müssen, wie Du das umgehst. Indem Du zum Beispiel nur den Teil des Bildschirm neu zeichnest, der sich auch tatsächlich geändert hat. Da sich der Ball zwischen zwei Positionen überlappt, kann ja im Prinzip ein Teil der Pixel stehen bleiben. Und welcher Teil und welcher nicht gilt es dann halt zu ermitteln.

Wie Du vielleicht schon merkst, über die Thematik kann man sich endlos auslassen.
Insofern ist das durchaus ne interessante Geschichte, wenn man Spaß daran hat sich damit auseinander zu setzen. Es wird aber nicht unbedingt trivial werden und man wird auf Probleme stoßen, die man lange Zeit nicht auf dem Radar hat.

Die Komplexität des Ganzen ist aber noch größer als hier angerissen. Gerade auf älterer Hardware wurde eben auch viel getrickst, um bestimmte Sachen hinzubekommen. Ein bewegender Ball wurde da eben nicht unbedingt Pixel für Pixel gezeichnet, sondern man hat einfach ne Speicherkopie der Bilddaten gemacht usw. weil das schneller ging.

Insofern hast Du eigentlich zwei Themenkomplexe. Wie setze ich bestimmte Dinge mathematisch um. Das heißt, wie berechne ich die Pixel einer Linie oder auch eines Kreises. Und Du hast die Hardwarekomponente. Wie setze ich das Ganze dann um auf Hardware die beispielsweise nur sehr begrenzte Funktionalität liefert (wobei man dort auch moderne Hardware nutzen kann und sich dann eben verbietet bestimmte Komfortfunktionen zu benutzen oder man besorgt sich ein Emulator von Hardware die es früher tatsächlich gab; zu dem angesprochen C64 gibts zum Beispiel durchaus reicht ausgereifte Emulatoren).

Wenn Du tatsächlich im Stil alter Homecomputer ( C64 und so, bei den 16-Bittern wird es wieder etwas schwieriger) programmieren willst, bieten sich zum Anfang tatsächlich Emulatoren an. Problem hierbei ist allerdings die Tastaturbelegung. Wenn Du zB alte Heft-Listings in BASIC abtippen willst, bist Du ständig auf der Suche, wo dieses Zeichen jetzt auf der PC-Tastatur liegt. Und in BASIC ist auch nicht viel zu reißen. Und Assembler lernen ist auch nicht ganz einfach, jedenfalls wenn es etwas komplexer werden soll.

Du kannst aber auch die Windows-Konsole dafür nehmen. Kannst ja dort die Größe anpassen, um die selben Dimensionen wie dem Bildspeicher eines C64 (40 Spalten * 25 Zeilen) zu bekommen. Der hochauflösende Hires-Modus (320 * 200) wurde nur recht selten für Spiele genutzt.

Musst halt nur auf veränderten Zeichensatz und auf Sprites verzichten Ansonsten ist es vom Prinzip das selbe. Animation durch laufendes Überschreiben von Positionen. Deshalb gibt es auch zig Variationen wie Spielen wie Pong, Snake, Vier gewinnt, Schiffe versenken etc in der Konsole.

Und wenn Du es wirklich wagen willst, kannst Du ja mit AMDs Virtual Super Resolution den Desktop auf 4K oder so aufblasen, die Skalierung aber auf 100% lassen und die Konsole maximieren. Dann müsste man schon an die 320 * 200 Spalten und Zeilen kommen

Dann kannst Du auch verschiedene Zeichensätze und Sprites erstellen, musst diese halt Pixel für Pixel (hier tatsächlich dann ein Feld in der Konsole) in der entsprechende Größe zusammenbasteln. Hat man früher auch nicht anders gemacht. Hat man sich natürlich Editoren für solche Aufgaben geschrieben. Diese dann in Arrays speichern, so das Du tatsächlich einen ganzen Satz von unterschiedlichen selbst erstellten Zeichen hast. Dito für Sprites.

Allerdings denke ich, das selbst die WinAPI-Funktionen bei solchen Konsole-Dimensionen in die Knie gehen werden

Aber stimmt schon, mit Grafikprogrammierung aktueller Art hat dies nichts zu tun. Selbst zu DOS-Zeiten ohne 3D-Beschleunigung hat man es anders gemacht.

Ich werfe noch mal das Canvas-API von HTML5 in den Raum. Das ist wahrscheinlich der simpelste Weg, heutzutage "low-level" - ohne komplexe Bibliotheken - Grafikprogrammierung zu betreiben. Für einfache 2D-Spiele a' la Pong mMn ideal.

Canvas wird in Javascript programmiert und läuft in jedem halbwegs aktuellen Browser. Du musst keine spezielle Software installieren und kannst sofort loslegen. Dokumentation gibt's z.B. hier: https://developer.mozilla.org/de/docs/Web/HTML/Canvas

Unter den Beispielen dort ist auch ein Raycaster - eine einfache (Pseudo-)3D-Engine von der Sorte, wie sie in den ersten Ego-Shootern zum Einsatz kam. Wenn du dich dafür interessiert, würde ich dir das empfehlen.

Aber wie andere schon schrieben: Mit 3D-Programmierung, wie sie heute im "GPU-Zeitalter" aussieht, dürfte das nicht mehr so viel gemeinsam haben. Da kämen noch so Dinge hinzu wie verschiedene Arten von Shadern, Anti-Aliasing, Tessellation und weiß der Geier was noch.

Da du lernen willst wie Grafikprogrammierung bzw. Rasterisierung, Software-Rendering funktioniert brauchst du nicht wirklich viel. Ich würde hier empfehlen, dass du es simulierst auf einem normalen PC mit x86 CPU.

Du nimmst eine moderne Programmiersprache: C++, Java, C#, Python was auch immer.
Du erzeugst ein pixel/int32 array mit der größe deiner Ziel-Bildschirm-Auflösung z.b. 320 * 240.
In diesem Array setzt du jeden einzelnen Pixel selbst.

Nun brauchst du von deiner Umgebung etwas, welches dieses Array/Pixel auf den Bildschirm in ein Fenster plottet - ohne filterung. In Win32 und C++ wäre das BitBlt oder StretchBlt. In Java würdest du das AWT machen. In C# mit System.Drawing.Graphics.

Wenn das klappt und du jeden Pixel manipulieren kannst und das Ergebnis auf deinem Bildschirm ist, dann kannst du anfangen dich mit der tatsächlichen Rasterisierung auseinandersetzten: Bresenham ist hier ein Schlüsselwort.

Falls es dich interessiert:
Ich habe vor einiger Zeit mal eine Java Spieleprogrammierung-Tutorial-Video-Serie gemacht, bei dem ich ausschließlich auf 2D Software-Rendering setzte: https://www.youtube.com/watch?v=k4lRWRgoyTY
Als Einstieg vielleicht gar nicht schlecht...

tori1117 schrieb:

Ich frage mich, ob es möglich wäre ein Spiel ohne Directx oder Opengl zu programmieren?

Zum Vergrößern anklicken....

Hier wird das alles ziemlich genau beschrieben, allerdings in "ausländisch":

=> http://www.jagregory.com/abrash-black-book/#chapter-23-bones-and-sinew

Für den Anfang insbesondere insbesondere interessant - Abschnitt: Mode 13H—320x200 with 256 Colors

Ich werfe da einfach mal sowas in den Raum:
https://www.youtube.com/watch?v=xGmXxpIj6vs

Mit p5.js (einer Lib für Grafikkram) habe ich dann mal aus Langeweile am Abend angeregt durch weiteres Youtube-Material das gebaut: https://www.38h.de

Ist zwar nicht 1:1 old shool und kann auch nicht für "größeres" verwendet werden aber für "Spaß am Programmieren" ist es genau richtig.