Wurde früher bei VGA DOS 3d Spielen für das Software Rendering ein SW Stencil Buffer verwendet?

Zum Amiga Blitter, für den, den es interessiert:
http://de.wikipedia.org/wiki/Amiga_Blitter

Und falls es solche Hardwarefunktionen im VGA Standard oder mit dem VESA Standard nicht gegeben haben sollte, warum wurden dann vor erscheinen von Windows 95, also noch zu Zeiten von Windows 3.0 die Spiele immer noch für DOS gechrieben?

Immerhin hätte man die Spiele doch auch für Windows 3.0 entwickeln können und dann von den 2d Beschleunigungsfunktionen, die damals aufkommende Grafikkarten extra für Windows booten, einheitlich nutzen können. Denn für Windows 3.0 gab es ja extra Grafikkartentreiber, die diese erweiterten Grafikfunktionen (wie z.B. Rechteck oder Linie zeichnen) nutzen konnten.

Warum hat das also so lange gedauert?
Selbst nachdem Windows 95 erschienen ist, kamen ja noch bis in die Jahre 1997 Spiele heraus, die nur für DOS und den dort verfügbaren VESA Modi geschrieben wurden.

rapso

VESA 2.0 schrieb:

Um damit nur die Pixel im Video-RAM der Grafikkarte upzudaten, die sich verändert haben oder war der Aufwand mit Stencil Buffer für die CPU zu groß und hat daher einfach jedes Bild einfach neu gezeichnet, also an die im Vergleich zu heute "dumme" Grafikkarte geschickt?

du musst schon sagen welche art von spiel
2d spiele wie dune2 oder c&c haben nur die teile geupdated die sich veraenderten.

3d spiele haben oft direkt in den video ram geschrieben, in zeiten von dos waren 64kb noch viel.

VESA 2.0 schrieb:

Und falls es solche Hardwarefunktionen im VGA Standard oder mit dem VESA Standard nicht gegeben haben sollte, warum wurden dann vor erscheinen von Windows 95, also noch zu Zeiten von Windows 3.0 die Spiele immer noch für DOS gechrieben?

Immerhin hätte man die Spiele doch auch für Windows 3.0 entwickeln können und dann von den 2d Beschleunigungsfunktionen, die damals aufkommende Grafikkarten extra für Windows booten, einheitlich nutzen können. Denn für Windows 3.0 gab es ja extra Grafikkartentreiber, die diese erweiterten Grafikfunktionen (wie z.B. Rechteck oder Linie zeichnen) nutzen konnten.

Warum hat das also so lange gedauert?
Selbst nachdem Windows 95 erschienen ist, kamen ja noch bis in die Jahre 1997 Spiele heraus, die nur für DOS und den dort verfügbaren VESA Modi geschrieben wurden.

da gibt es zwei einfache gruende
1. windows war nicht fuer spiele gemacht, aus diesem grund gab es von MS auch mehrere versuche eine spiele schnittstelle zu etablieren, aber das war halbgar (also vor directX). dabei geht es nicht nur um gfx, sonder speicherverwaltung, maus/tastatur input (das eventsystem ist nicht so optimal und wenn ein spiel 100% rechenleistung zieht, bewegt sicht der cursor nicht), sound output war problematisch (treiber waren ziemlich mies) und gfx output ging meistens ueber irgend einen windows layer, in zeiten in denen man memclear und copies noch in assembler schrieb. watcom dos 4gw war da um welten besser.
2. treiber und gfx hardware war langsam, ich konnte unter dos mit der cpu mehr linien zeichnen als meine graka (ich glaube s3 968 oder so). die tests damals in zeitschriften waren nicht um zu zeigen welche graka schneller ist, sondern welche weniger bugs beim zeichnen hat. normale windows dinge waren problematisch, z.b. scrollen oder buttons mit schatten rendern.
die idee der grakas damals war nicht schneller zu sein als die cpu, sondern dass die cpu waehrenddessen was anderes haette tun koennen. aber damals dachte niemand an physik oder ai oder..., 99% der zeit verbrachte die cpu damit zu rendern, sie also idle zu lassen damit die graka es langsammer macht -> unsinn aus damaliger sicht.
erst die voodoo waren nuetzlich.
zudem musst du noch bedenken, 'beschleuniger' bedeutete nur dass ein paar funktionen uebernommen wurden von der graka, oft nur sowas simples wie eine zeile daten kopieren, selbst wie erste voodoo hate kein eigene triangle setup, geschweige denn clipping und trotzdem war sie der durchbruch... stell dir vor wie schlecht die anderen waren zu der zeit

rapso schrieb:

VESA 2.0 schrieb:

Um damit nur die Pixel im Video-RAM der Grafikkarte upzudaten, die sich verändert haben oder war der Aufwand mit Stencil Buffer für die CPU zu groß und hat daher einfach jedes Bild einfach neu gezeichnet, also an die im Vergleich zu heute "dumme" Grafikkarte geschickt?

du musst schon sagen welche art von spiel
2d spiele wie dune2 oder c&c haben nur die teile geupdated die sich veraenderten.

3d spiele haben oft direkt in den video ram geschrieben, in zeiten von dos waren 64kb noch viel.

Naja, ich wollte das generell wissen, aber da ich nicht weiß, ob hier featuremäßig VESA einen Unterschied zu VGA macht, würde ich mal folgende Spiele meinen:

1. 3d Vektorgrafikspiel, das nur VGA nutzt (also ohne VESA Features, also aich die typische VGA Auflösung von 320*200 Bildpunkten bei 2^8 Farben)
2. 3d Voxelgrafikspiel, das nur VGA nutzt
3. 2d Sidescroller, der nur VGA nutzt

4. 3d Vektorgrafikspiel, das VESA 2.0 nutzt
5. 3d Voxelgrafikspiel, das VESA 2.0 nutzt
6. 2d Sidescroller, das VESA 2.0 nutzt

Dune 2 und C&C mußten ja auch scrollen können, wie hat man das da vom Bildaufbau gemacht?
Bei nem Standbild ist das mit dem "nur das updaten, was sich ändert" ja klar, aber sobald gescrollt werden muss, ist der gesamte Bildschirminhalt kein Standbild mehr.

Das mit den 64 KB leuchtet ein, du hast recht, würde man hier nen Stencil Buffer verwenden, dann bräuchte man bei VGA Auflösung (320*200*1 Byte) ja ca. 64 KB für das alte Bild und weitere 64 KByte für das neue Bild und der Stencil Buffer wäre wohl ineffizient, wenn man jeden Pixel Bitweise in 1 Byte abbildet, also 8 Pixel des Stencil Buffers zu 1 Byte zusammenfaßt.

Aber man könnte die upzudatenden Pixel ja auch ganz einfach on the fly aus dem ersten Bild und dem zweiten Bild Berechnen und dann nur diese upzudatenden Pixel einzeln an die Grafikkarte schicken. Also so ne Art Stencil Algorithmus, anstatt Buffer.
Dann braucht man zwar immer noch 128 KB und falls double buffering dazu kommt, nochmal etwas mehr, aber viele DOS Spiele nach 1990 benötigten dann ja ohnehin
schon oft 600 Kbyte RAM und mehr und für irgendwas muss man den doch sicher verwendet haben, oder?

da gibt es zwei einfache gruende
1. windows war nicht fuer spiele gemacht, aus diesem grund gab es von MS auch mehrere versuche eine spiele schnittstelle zu etablieren, aber das war halbgar (also vor directX).

Du meinst WinG, oder?

http://de.wikipedia.org/wiki/WinG

dabei geht es nicht nur um gfx, sonder speicherverwaltung, maus/tastatur input (das eventsystem ist nicht so optimal und wenn ein spiel 100% rechenleistung zieht, bewegt sicht der cursor nicht), sound output war problematisch (treiber waren ziemlich mies)

Das leuchtet ein.

und gfx output ging meistens ueber irgend einen windows layer, in zeiten in denen man memclear und copies noch in assembler schrieb. watcom dos 4gw war da um welten besser.

Aber genau wegen den Nachteilen der GDI bei GFX Output entwickelte MS ja WinG.
Damit wäre dieses Problem also eigentlich beseitigt gewesen, geblieben wären die anderen Probleme, die du oben nanntest.

2. treiber und gfx hardware war langsam, ich konnte unter dos mit der cpu mehr linien zeichnen als meine graka (ich glaube s3 968 oder so).

Hm, also ich kann mir das schwer vorstellen, das HW Blitting dass über WinG realisiert wird, langsamer sein soll, das SW Blitting in DOS.

Bei DOS gab's ja leider keine einheitliche Grafikschnittstelle, um diese Blitting 2d Beschleunigungsfunktionen der Grafikkarten nutzen zu können.
Wer das wollte, der musste für den 2d Beschleuniger das Spiel direkt programmieren.

Was uns zu der nächsten Frage führt, warum das niemand gemacht hat, denn bei Soundkarten hat man sich diesen Luxus ja auch geleistet.

die idee der grakas damals war nicht schneller zu sein als die cpu, sondern dass die cpu waehrenddessen was anderes haette tun koennen.

Dann waren die Blittingfunktionen aber ziemlich mies in der HW realisiert, wenn
selbst das langsamer war, als SW Blitting.

zudem musst du noch bedenken, 'beschleuniger' bedeutete nur dass ein paar funktionen uebernommen wurden von der graka, oft nur sowas simples wie eine zeile daten kopieren, selbst wie erste voodoo hate kein eigene triangle setup, geschweige denn clipping und trotzdem war sie der durchbruch... stell dir vor wie schlecht die anderen waren zu der zeit

Ja, aber HW Blitting, also das verschieben von 2d Bildausschnitten (wir sprechen hier ja noch nichtmal von 3d Funktionen) wie beim Amiga müßte doch schon ein wesentlicher Vorteil gewesen sein und dieses Feature ist so naheliegend, dass es eigentlich jede 2d Beschleunigerkarte schon integriert haben müßte.

Das hätte man überall nutzen können, vor allem in Jump&Runs, wo sich z.B. ja auch nur Sprites von der linken zur Rechten Seite des Bildschirms bewegen.

Bei meiner Recherche habe ich gerade folgendes entdeckt, der erste in großen mengen produzierte 2d Beschleuniger für den PC kam von IBM:

http://en.wikipedia.org/wiki/IBM_8514

Er konnte BitBlitting und einige weitere interessante Features und es gab von ihm Klone anderer Hersteller.
Desweiteren wurden seine Fähigkeiten im XGA Standard übernommen.

Allerspätestens hier fragt man sich dann aber, warum XGA kein Industriestandard wurde und von den DOS Spielen nicht verwendet wurde.
Immerhin hätte man mit den 2d Funktionen ne ganze Menge in einem Spiel beschleunigen können.
Da ist es nur seltsam, dass man auf diese Fähigkeiten verzichtet hat und weiterhin Jahre lang alles in Software gerendert hat.

hustbaer

Weil man wollte dass die Spiele überall laufen.

rapso

VESA 2.0 schrieb:

1. 3d Vektorgrafikspiel, das nur VGA nutzt (also ohne VESA Features, also aich die typische VGA Auflösung von 320*200 Bildpunkten bei 2^8 Farben)

da hast du den vram an addresse 0xa0000:0000 (das erste ist ein segment, ist keine 32bit addresse ), heisst mode 13h, dabei wurde mit sowas wie "rep movsd" reingeschrieben, sehr optimiert

2. 3d Voxelgrafikspiel, das nur VGA nutzt

siehe 1.

3. 2d Sidescroller, der nur VGA nutzt

side scroller haben oft tricks verwendet wie z.b.
1. einen graphikmodus nutzen der nicht den ganzen vram braucht, aber erlaubt den sichtbaren bereich dem DAC mitzuteilen, so dass man statt die daten zu kopieren, einfach nur den sichtbaren ausschnitt durch zwei/drei register writes umdefinierte.
manchmal konnte hardware auch mehrere 'layer', dann gab es einen hintergrund und vordergrund, aber das war bei dos eher nicht der fall, jedoch waren side scroller entsprechend auch eine domaene von video automaten und konsolen.

4. 3d Vektorgrafikspiel, das VESA 2.0 nutzt

da gab es mehrere wege, oft wurde pro zeile entschieden welche "page" man aus dem VRam braucht, dann musstest du ein register beschreiben entsprechend der granularitaet die du beim initialisieren bekammst, konnte zwischen 4kb und 64kb sein und manchmal bis 4 pages. anhand der dann gesetzten register konntest du auf der gemappten addresse eine zeile deines dreiecks direkt reinschreiben in den backbuffer.

5. 3d Voxelgrafikspiel, das VESA 2.0 nutzt

siehe 4.

6. 2d Sidescroller, das VESA 2.0 nutzt

aenlich wie bei VGA, uebrigens waren shumps verbreiteter als side scroller, weil das scrolling window selten supportet war auf PC/DOS (von hardware aus), man aber der HW oft sagen konnte an welcher addresse genau der frontbuffer beginnt, scrollen war also nur zeilenweise die addresse aendern, ich glaube es gab sogar ein 'wrap around' wodurch es nie noetig war das ganze bild neu zu setzen, man hat einfach nur die vorher nicht existierenden zeilen geaendert. (kann auch sein dass ich das mit den ganzen konsolen etwas vermische, ist fast 15+jahre her seitdem ich damit zuletzt gearbeitet habe )

einheiten hat man mit xor tricks gesetzt (aenlich wie man den software mouse cursor emulieren konnte).

Dune 2 und C&C mußten ja auch scrollen können, wie hat man das da vom Bildaufbau gemacht?
Bei nem Standbild ist das mit dem "nur das updaten, was sich ändert" ja klar, aber sobald gescrollt werden muss, ist der gesamte Bildschirminhalt kein Standbild mehr.

bei strategiespielen oft das umkopiert was noch sichtbar ist und den rand der neu war dann neu zeichnen, so lief das uebrigens auch unter windows wenn man in einem fenster scrollte.

Das mit den 64 KB leuchtet ein, du hast recht, würde man hier nen Stencil Buffer verwenden, dann bräuchte man bei VGA Auflösung (320*200*1 Byte) ja ca. 64 KB für das alte Bild und weitere 64 KByte für das neue Bild und der Stencil Buffer wäre wohl ineffizient, wenn man jeden Pixel Bitweise in 1 Byte abbildet, also 8 Pixel des Stencil Buffers zu 1 Byte zusammenfaßt.

damit wollte ich eher andeuten dass man den buffer eher nicht in den framebuffer kopiert hatte, sondern direkt im vram rummatschte. und dann beim vblank interrupt (oder wenn man selbst auf das register synchronisiert hat) die pages flipte indem man dem DAC sagte wo der neue frontbuffer ist.

Aber man könnte die upzudatenden Pixel ja auch ganz einfach on the fly aus dem ersten Bild und dem zweiten Bild Berechnen und dann nur diese upzudatenden Pixel einzeln an die Grafikkarte schicken. Also so ne Art Stencil Algorithmus, anstatt Buffer.

das sind glaube ich die xor tricks die du meinst, funzt natuerlich nur bei sowas wo viel der daten gleich bleibt, ala strategiespiel.

Dann braucht man zwar immer noch 128 KB und falls double buffering dazu kommt, nochmal etwas mehr, aber viele DOS Spiele nach 1990 benötigten dann ja ohnehin
schon oft 600 Kbyte RAM und mehr und für irgendwas muss man den doch sicher verwendet haben, oder?

man brauchte nicht wirklich 128kb, sondern nur fuer die einzelnen einheiten etwas speicher, alles baute stark auf der idee auf dass sich nicht viel aendert.

da gibt es zwei einfache gruende
1. windows war nicht fuer spiele gemacht, aus diesem grund gab es von MS auch mehrere versuche eine spiele schnittstelle zu etablieren, aber das war halbgar (also vor directX).

Du meinst WinG, oder?
http://de.wikipedia.org/wiki/WinG

stimmt, das war ein name von denen die mir entfielen.

dabei geht es nicht nur um gfx, sonder speicherverwaltung, maus/tastatur input (das eventsystem ist nicht so optimal und wenn ein spiel 100% rechenleistung zieht, bewegt sicht der cursor nicht), sound output war problematisch (treiber waren ziemlich mies)

Das leuchtet ein.

und gfx output ging meistens ueber irgend einen windows layer, in zeiten in denen man memclear und copies noch in assembler schrieb. watcom dos 4gw war da um welten besser.

Aber genau wegen den Nachteilen der GDI bei GFX Output entwickelte MS ja WinG.
Damit wäre dieses Problem also eigentlich beseitigt gewesen, geblieben wären die anderen Probleme, die du oben nanntest.

du kannst ein register in assembler per "out" pro zeile die du renderst beschreiben, oder du kannst API calls ans OS machen. dabei hatten manche APIs einfach nur versucht zu wrappen was man in HW eh hatte, andere hatten mehr abstraktion gebracht z.b. seperate buffer nutzen unter der premisse, dass 'bald hardware rauskommt die das direkt supportet" also dass z.b. mehrere fenster direkt per DAC geblendet und ausgegeben werden. aber es war viel overhead.
unter dos gab es ja auch fuer VGA bios funktionen die mehr kompatibilitaet bieten sollten, aber es war sehr viel schneller direkt auf HW zu schreiben, du konntest z.b. sogar hblank auslesen (also wenn der monitor rasterstrahl gerade die zeile zuruecklaeuft udn nichts anzeigt) und in dem moment einige farbregister veraendern um dann im 256farb modus, pro zeile eine neue palette zu setzen und so sehr viel mehr farben ausgeben (haben nur wenige gemacht, weil du ja nicht mit der cpu rendern und gleichzeitig den hblank abwarten kannst), wurde. es gab auch tricks wenn ich mich richtig erinnere, wie du einen 400zeilen modus machst, indem du den DAC austrickst, obwohl du nur speicher fuer 200zeilen hast.
das ist eine zeit in der es fuer die leute die welt bedeutete im inner loop einen cycle in assembler einzusparen, ein api call wo du nicht weisst wie langsam der ist? der vielleicht in einen treiber geht? der eventuel 20sicherheitschecks macht bevor der zurueckkommt und vielleicht sogar deine 'illegalen' aber gewollten tricks mit einem fehler quittiert auf irgend einer speziellen windows inkarnation?

das erste directX bestand auch nicht aus 'drawmesh', sondern zusammenstecken von commandbuffern (ich glaube die hiessen execute buffer oder so), quasi lowest level freakyness mit der niemand mehr heute arbeiten wollen wurde (zumindestens auf pc).

2. treiber und gfx hardware war langsam, ich konnte unter dos mit der cpu mehr linien zeichnen als meine graka (ich glaube s3 968 oder so).

Hm, also ich kann mir das schwer vorstellen, das HW Blitting dass über WinG realisiert wird, langsamer sein soll, das SW Blitting in DOS.

der blit laeuft in beiden faellen so schnell wie es der speicher hergibt, aber unter WinG hast du noch den API overhead, zudem ist blitting die minimalfunktion. sie versteckt oft informationen die du eventuell zum vorteil nutzen koenntest, z.b. die granularitaet in dem der framebuffer gemappt wird.
dann kannst du deine zeichen operationen zu anlegen dass du dieses page flippen minimierst und dabei dennoch direkt in den framebuffer schreibst und dir die temporaere kopie, die es vermutlich bei WinG gibt, ersparst. in deinem 800x600@8bit beispiel, sind es 1MB die ueber den bus gehen bei einer kopie, bei den ca 100MB/s-200MB/s die ein 80x486 schafft (je nach version), sind das 5ms bis 10ms pro frame.

Bei DOS gab's ja leider keine einheitliche Grafikschnittstelle, um diese Blitting 2d Beschleunigungsfunktionen der Grafikkarten nutzen zu können.
Wer das wollte, der musste für den 2d Beschleuniger das Spiel direkt programmieren.

1. unter dos musste man ja auch nicht blitten, framebuffer hatte doublebuffering bei den spielen die fullscreen updates hatten und die die partielle updates haetten hat man halt manchmal mit registern getrickst um scrolling zu machen. APIs limitieren dich immer auf das, was vorher definiert ist. sowas wie Mode7 rendering oder Mode X sind entstanden durch ideen die die leute mit der HW hatten, weil es keine API gab die das limitierte (bzw es gab eine API wie das bios, aber man konnte dennoch direkt die HW nutzen).
auch heute noch auf konsolen, dadurch dass wir direkt auf HW arbeiten koennen, gibt es tricks die genutzt werden, die du sonst garnicht probieren kannst, einfachstes ist z.b. eine textur als input und output zur gleichen zeit zu nutzen um z.b. einen eigenen blend modus zu implementieren.

Was uns zu der nächsten Frage führt, warum das niemand gemacht hat, denn bei Soundkarten hat man sich diesen Luxus ja auch geleistet.

auf soundkarten hat man eigentlich auch nur 'soundblaster' programmiert, wer eine soundkarte kaufen wollte, musste drauf achten dass sie 'soundblaster kompatibel' ist, sonst gab es viele spiele die damit nicht klarkamen.

die idee der grakas damals war nicht schneller zu sein als die cpu, sondern dass die cpu waehrenddessen was anderes haette tun koennen.

Dann waren die Blittingfunktionen aber ziemlich mies in der HW realisiert, wenn
selbst das langsamer war, als SW Blitting.

beim blitting bist du immer speicher limitiert. damals hatte die CPU den gleichen zugriff auf speicher die HW. zudem musstest du die daten immer von CPU auf GPU kriegen, ob das jetzt die CPU oder GPU macht war recht egal, die CPU hat nicht viel mehr gemacht ausser rendering, macht jemand anderes das rendering und laeuft es nicht schneller, hat man 0 gewonnen, also wozu der aufwand?

zudem musst du noch bedenken, 'beschleuniger' bedeutete nur dass ein paar funktionen uebernommen wurden von der graka, oft nur sowas simples wie eine zeile daten kopieren, selbst wie erste voodoo hate kein eigene triangle setup, geschweige denn clipping und trotzdem war sie der durchbruch... stell dir vor wie schlecht die anderen waren zu der zeit

Ja, aber HW Blitting, also das verschieben von 2d Bildausschnitten (wir sprechen hier ja noch nichtmal von 3d Funktionen) wie beim Amiga müßte doch schon ein wesentlicher Vorteil gewesen sein und dieses Feature ist so naheliegend, dass es eigentlich jede 2d Beschleunigerkarte schon integriert haben müßte.

amiga hat keine 3d funktionen, es hat eine sprite engine
und welcher vorteil waere es?
die cpu sagt der "gpu" was zu tun ist, hofft dass jede gpu jede eingabe richtig interpretiert und wartet dann bis die gpu fertig ist, die eigentlich auch nur dafuer da ist, damit die cpu was anderes machen koennte waehrend die gpu kopiert?

gpus waren damals eher fuer sowas wie CAD programme, die haben aus ihren representationen der daten zeichenbare daten gemacht, das war aufwendig und waehrend sie das machten, konnte die graka die linien zeichnen usw.

teure 3d beschleuniger wie die wildcat intense3D wenn ich mich recht entsinne, konnten zur voodoo2 zeiten noch garkeine texturen, nichtmal point filtered, auf der anderen seite hatten sie t&l (opengl kompatibel) und haben geround geshadete dreiecke gezeichnet, du hattest im linienmodus antialiasing. dafuer waren die ersten windows beschleuniger auch gedacht.
wenn du heute ein netbooks kaufst und mal einen 1920x1080 monitor anschliesst und ohne HW beschleunigung arbeitest, bekommst du in etwa das feeling wie langsam scrollen sein kann. die ganze hoffnung war, dass die beschleuniger nicht viel schneller werden, sondern die features unterstuetzen die microsoft will, z.b. eben mehrere buffer supporten mit HW scrolling. (auf dieser hoffnung baust du kein produkt/spiel )

rapso schrieb:

Ja, aber HW Blitting, also das verschieben von 2d Bildausschnitten (wir sprechen hier ja noch nichtmal von 3d Funktionen) wie beim Amiga müßte doch schon ein wesentlicher Vorteil gewesen sein und dieses Feature ist so naheliegend, dass es eigentlich jede 2d Beschleunigerkarte schon integriert haben müßte.

amiga hat keine 3d funktionen, es hat eine sprite engine

Das mußt du so lesen:

Ja, aber HW Blitting, also das verschieben von 2d Bildausschnitten ( ...) wie beim Amiga müßte doch schon ein wesentlicher Vorteil gewesen sein

Würde sich das 3d auf den Amiga beziehen, dann wäre der Amiga auch in der Klammer.

und welcher vorteil waere es?
die cpu sagt der "gpu" was zu tun ist, hofft dass jede gpu jede eingabe richtig interpretiert und wartet dann bis die gpu fertig ist, die eigentlich auch nur dafuer da ist, damit die cpu was anderes machen koennte waehrend die gpu kopiert?

Die CPU wird entlastet und kann in der Zwischenzeit anderes machen.

Ich kann mich erinnern, dass man sogar auf dem Amiga 500 schon 3D Spiele hatte.

Ist schon krass, bei der lahmen CPU (im Vergleich zu heute)

http://www.youtube.com/watch?v=NvpcGs-NJPw

MisterX schrieb:

Ich kann mich erinnern, dass man sogar auf dem Amiga 500 schon 3D Spiele hatte.

Ist schon krass, bei der lahmen CPU (im Vergleich zu heute)

http://www.youtube.com/watch?v=NvpcGs-NJPw

Nochmal:

raspo hat das falsch verstanden.
Es ging um 2d Grafikfunktionen in HW gegossen.

Und natürlich kannst du auch in SW 3d Grafik erzeugen, deswegen gab's ja auch schon für den Amiga 500 3d Spiele.
Für den C64 übrigens auch:
http://www.c64-wiki.de/index.php/Elite_(Spiel)