Wie können verschiedene Engines (Quake,Far Cry,Unreal,...) unterschiedliche Effekte bieten?
-
Vorweg: Ich kann programmieren, nur was 3D und Grafik Engines angeht, damit hab ich mich noch nie befasst. Was ich weiß ist, dass Windows das DirectX SDK anbietet. Dort stehen verschiedene Funktionen bereit, oder auch Strukturen wie VertexBuffer etc.
Wenn dieses DirectX SDK für alle Spiele die Basis darstellt (sonst müsste man ja nicht Direct X installieren), wie kann es dann sein, dass z.B. bei Far Cry das Wasser besser aussieht als bei Quake oder Unreal hübschere Schatten und Beleuchtungseffekte hat (fiktive Beispiele).
-
Zwei Beispiele:
- In heutiger Grafikprogrammierung hast du keine Fixed Pipeline mehr, mit Shadern kann man letztlich tiefgreifend in das Rendering eingreifen. Gerade bei Wassereffekten könnte ich mir vorstellen, dass Engine X gegenüber Engine Y eventuell die besseren Shader bietet.
- Engine X implementiert gegenüber Engine Y bessere Sichtbarkeitsalgorithmen und rendert deshalb schneller, kann somit mehr Rechenzeit für andere Dinge (teure Effektberechnungen) verbraten. Triviales Beispiel: Noname-Engine Z rendert Terrain ohne Octree, Engine X rendert mit Octree und ist somit viel performanter.
-
Das ist genauso wie "Wenn die meisten Spiele in C++ geschrieben werden, wie kommt es dann, dass sie unterschiedlich sind?".
DirectX oder OpenGL bieten vom Prinzip her einfach nur sehr gute und komplexe Funktionen um Pixel an einer bestimmten Position auf eine bestimmte Farbe zu setzen. Welche Pixel welche Farbe bekommen, entscheidet der Programmierer.
Funktionen wie "zeichne Wasser" sind da nicht, das macht der Programmierer über Shader und ähnliches.
-
Hem, das heißt also, das sich die Grafikchips dahingehend geändert haben, das sie eigentlich keine 3D-Grafik bereit stellen? Sondern letztendlich nur eine spezialisierte CPU sind und am Ende "zufällig" ein Bild ausgeben?
Damals waren die Grafikchips ja noch was anderes: ich will ein Sprite an Position X,Y und N Grad gedreht. Und dann erschien das Sprite, ohne das ich noch irgend etwas über Rotation, Bitmasking, Alphachannel oder so wissen musste.
Das typische Aussehen eines Spiels gab der Chip vor. Die Grafikeffekte-Engine war im Chip gegossen.
Bei 3D Grafik war das damals auch so: Hier meine drei Punkte und hier die Textur. Mach mal!
Hem, dann hat sich die Grafikchipwelt mit den GPUs stark gewandelt? Sie ist sehr allgemein, und heute muß ich eine Grafik-Engine (Software) dafür nehmen, um das zu erhalten, was damals in Chips gegossen war.
Ist nicht schlechter, aber anders.
-
Artchi schrieb:
Bei 3D Grafik war das damals auch so: Hier meine drei Punkte und hier die Textur. Mach mal!
Hem, dann hat sich die Grafikchipwelt mit den GPUs stark gewandelt? Sie ist sehr allgemein, und heute muß ich eine Grafik-Engine (Software) dafür nehmen, um das zu erhalten, was damals in Chips gegossen war.
Die Chips sind jetzt flexibel. Das Verhalten, was damals in Chips gegossen war, war die fixed pipeline. Die konnte man lediglich via Parameter modifizieren. Jetzt kann man alles Möglich mit Shadern beeinflussen. Diese Shader sind Software, die auf der Grafikkarte laufen. Ja, sie sind jetzt extrem flexibel geworden.
-
Artchi schrieb:
Damals waren die Grafikchips ja noch was anderes: ich will ein Sprite an Position X,Y und N Grad gedreht.
War das wirklich so?
Ich kenne die "old-school" Grafikprogrammierung wo man über einen Buffer einzelne Pixel ansprechen konnte.Ich kenne die früheren OpenGL/DirectX-Zeiten wo man gedrehte Sprites über Texturen auf Meshes zeichnen konnte und das via Matrixoperationen über fixed Pipeline rendern konnte.
Ich kenne den neuen Ansatz von Shadern, der die fixed Pipeline ersetzt.
Aber ich kannte nie eine Grafikkarte, die eine High-Level-API ala "zeichne mir gedrehtes Sprite" anbot. Das wurde dann entsprechend über Bibliotheken realisiert.
-
Ich kenne auch noch die Zeiten, wo ich jeden Pixel selbst berechnen und auch setzten musste. Und wer heute etwas über Grafikprogrammierung lernt, der wird auch irgendwann mal einen Software-Renderer schreiben, wo wirklich ALLES per Hand berechnet und in den Speicher geschrieben wird. Dann ist man sehr gut vorbereitet auf Grafikschnittstellen wie OpenGL/DirectX und versteht auch fertige Engines viel besser.
An den TE: Auch heute muss man jede Berechnung selbst programmieren. Nur landen dann viele dieser Programme auf der Grafikkarte als kompilierte Shader. Aber so wie du deine Frage formulierst hast, solltest du froh sein wenn du einen Rechner einschalten kannst. Du scheinst ja wirklich von nix einen Schimmer zu haben.
-
Natürlich konnte man auf den damaligen Chips auch einen Bitmap-Screen ansprechen. Wie sollte man sonst Bilder, Fenster-UI u.ä. darstellen?
Aber für die Spiele gab es halt auch Sprites und Scrollfunktionen. Auf dem C64 war es jedenfalls so:
8 Sprites gleichzeitig, einfach sagen: Sprite Nr. 1 Bitmap findest du an Adresse A. Schalte Sprite Nr.1 an. Position für Sprite Nr.1 an X und Y. Tadaaa! Und das Sprite war mit allem Pipapo zu sehen.
C64 Sprites horizontal Skalieren? Ein Bit setzen, war das Sprite auf einmal doppelt so breit.
Sprite-Kollisionsabfrage auf Pixelebene? Hat der Grafikchip gemacht, mußte man nicht noch jedes Sprite-Pixel mit nem anderen Sprite-Pixel checken. Der Grafikchip hat Pixel-Kollisionen (also nicht einfach Rechteck mit Rechteck!) per Interrupt informiert.
Bildschirmscrolling in vier Richtungen? Eine Speicherstelle die 8 Bits hat shiften. Scrolling hat keine CPU-Rechenleistung gekostet. Danach die Landschaft um einen Block veschieben, und Scrollregister wieder von vorne, bis die 8 Pixel wieder voll waren.
Sprites und Scrolling waren in Hardware gegossen. Man musste dem Grafikchip nur sagen, wo er was im Speicher findet und ein paar Speicherstellen mit Werte befüllen. Und alles änderte sich auf dem Screen umgehend (egal wo, auch im BASIC-Edior erschien das Sprite), sozusagen Live-Objects.
Man sagte dem Chip nicht wie, sondern was er machen sollte.Mit der schwachen CPU-Leistung wäre das auch gar nicht anders möglich gewesen.
Das ist zwar alles schon ewig her, und im Detail kann ich mich heute noch irren. Aber so war es im Prinzip.
Tut mir leid, aber das war dann wohl auch das Erfolgsgeheimnis des C64 als Spielecomputer!
Auf dem Amiga, SNES usw. gab es auch mehr Sprites. Da gab es sogar Mehrfach-Paralax-Scroll-Buffer! Das SNES konnte meines Wissens sogar Sprite-Rotation.
Die heutigen GPUs sind anscheinend flexibler aber "dümmer". Denen muß man nämlich sagen, WIE sie etwas zu machen haben, und nicht mehr WAS sie machen sollen.
-
Beispiel um C64 Sprites Nr. 1-4 zu skallieren:
LDA #%00001111 ; Bits für Sprite Nr. 0-3 setzen STA $D01D ; Grafikchip-Register für X-SkalierungMehr war das nicht!
-
Ja, du hast ja Recht. Auch der Amiga konnte mit dem Blitter Linien zeichnen, Flächen füllen und Speicher schnell ohne CPU-Last kopieren. Dennoch sollte man bei 3D die Mathematik und die Algorithmen dahinter verstanden haben, bevor man sich auf Engines oder auch eine Grafik-API stürzt.
Die ersten coolen Demos(Second Reality etc) auf dem PC, waren hingegen wirklich Pixel für Pixel, da hat die GraKa null geholfen.
-
Artchi schrieb:
8 Sprites gleichzeitig, einfach sagen: Sprite Nr. 1 Bitmap findest du an Adresse A. Schalte Sprite Nr.1 an. Position für Sprite Nr.1 an X und Y. Tadaaa! Und das Sprite war mit allem Pipapo zu sehen.
mit dem C64 konnte man sogar weit mehr als 8 Sprites gleichzeitig darstellen: indem man in einer Zeile unterhalb der Sprites einen Rasterzeilen-Interrupt auslöste, und die Pixeldaten-Zeiger der Sprites auf andere Speicherbereiche umbog. Dann konnte man erneut bis zu 8 Sprites anzeigen, wenn ich mich richtig erinnere.
Ferner konnte man Sprites im Bildschirmrand anzeigen, also da, wo man mit normalen Bitmap nicht hinkam, und das ging nicht nur im oberen und unteren Rand (indem man knapp vor dem unteren Rand mit einem Rasterzeilen-Interrupt eine Routine ansprang, die von 25 auf 24 Zeilen umstellte und damit das Abschalten der Sprites verhinderte oder so).
Sondern das ging sogar im linken und rechten Randbereich (indem man knapp vor dem rechten Rand eines der Register umstellte und den Grafikchip so an der Abschaltung der Sprite-Darstellung hinderte.)
Sprites im linken und rechten Rand darzustellen war allerdings kniffliger als im oberen und unteren Rand. Da reichte, glaube ich, nicht eine von Rasterzeileninterrupt gerufene Routine, sondern man mußte CPU-Zyklen in Mikrosekunden zählen, um genau im richtigen Moment zu schalten.
(dies nur aus der Erinnerung heraus und ohne Anspruch auf Korrektheit - ist schon ein paar Jahre her, daß ich mich mit sowas unter der Schulbank beschäftigt habe ...)
-
Da hast du dich verdammt gut erinnert. Timing war alles und wer ganz cool war hat die CIA-Timer für seine Tricks genutzt.
Auf dem PC gab es auch Tricks die haben Chips missbraucht um einen Rasterzeileninterrupt zu simulieren und zusätzlich wurde noch ein versteckter VGA Modus gefunden.
Echt toll, dass es noch Leute gibt die das, wie ich, alles mitgemacht haben. Heute wird ja schon C und OpenGL als LowLevel angesehen, da können wir alten Hasen nur lachen. Mit dem lahmen C brauchte damals keiner kommen und damit konnte man aus den Kisten auch so gut wie nichts raus holen, das war ASM + direkte Programmierung der Chips pur. Früher hat sich jeder ab 12 an ASM ran getraut heute brauchen sie ein Studium und eine VM...LOL
-
Artchi schrieb:
Natürlich konnte man auf den damaligen Chips auch einen Bitmap-Screen ansprechen. Wie sollte man sonst Bilder, Fenster-UI u.ä. darstellen?
Aber für die Spiele gab es halt auch Sprites und Scrollfunktionen. Auf dem C64 war es jedenfalls so:
(...)
Cool, danke für die kurze Einführung, war mir nicht bekannt.
-
Amiga500 schrieb:
Mit dem lahmen C brauchte damals keiner kommen und damit konnte man aus den Kisten auch so gut wie nichts raus holen
Was aber sicherlich auch daran lag, dass die C-Compiler nicht so gut optimierten. Heute muss man schon ziemlich geschickt Assembler programmieren, um gegenüber dem C-Compiler noch was zu reißen.
Amiga500 schrieb:
, das war ASM + direkte Programmierung der Chips pur. Früher hat sich jeder ab 12 an ASM ran getraut heute brauchen sie ein Studium und eine VM...LOL
Ja klar, jeder. Und heute sind sie alle dumm und in einem Informatikstudium lernt man typischerweise nur das, was früher die 12-jährigen konnten. Und heute kann niemand mehr Assembler und kennt auch keine Interna der CPU. Ist ja zum Glück auch kein Pflichtkurs im Informatikstudium.
-
Ich bin jetzt noch nicht so alt, aber meines Wissens nach konnte man aufm Amiga und dem C64 bereits in Basic entwickeln. Und alle aus der damaligen Zeit die ich kenne haben das auch getan. Von keinem ist mir jetzt aktiv bekannt, dass er auf den genannten Geräten nur in Assembler bzw. hauptsächlich in Assembler programmiert hat.
-
Finde eure Beschreibungen garnicht mal so geil und vermisse es nicht das verpasst zu haben.
-
ich uebersetze das mal auf etwas, was vielleicht allgemein bekannter ist:
Hintergrundwissen schrieb:
Wenn dieses DirectX SDK für alle Spiele die Basis darstellt (sonst müsste man ja nicht Direct X installieren), wie kann es dann sein, dass z.B. bei Far Cry das Wasser besser aussieht als bei Quake oder Unreal hübschere Schatten und Beleuchtungseffekte hat (fiktive Beispiele).
Wenn dieses Internet fuer alle Server die Basis darstellt (sonst mueste man sich ja nicht dran verbinden), wie kann es dann sein, dass z.B. bei Google die Suche bessere Ergebnisses liefert als bei Yahoo oder dass Vimeo bessere videoqualitaet liefert als Youtube.
so in etwa ist das.
-
inflames2k schrieb:
Ich bin jetzt noch nicht so alt, aber meines Wissens nach konnte man aufm Amiga und dem C64 bereits in Basic entwickeln. Und alle aus der damaligen Zeit die ich kenne haben das auch getan. Von keinem ist mir jetzt aktiv bekannt, dass er auf den genannten Geräten nur in Assembler bzw. hauptsächlich in Assembler programmiert hat.
gibt auch sicherlich jetzt bei vielen das gefuehl dass jeder in c#,js,html5,etc. spiele macht. obwohl die meisten programmierer doch c++ nehmen bei spielen. in 20jahren wird die c++ leute niemand kennen. Dennoch waren die spiele die du damals kaufen konntest zum grossteil in assembler gemacht. mit den 64kb die du hast ist da auch garnicht soviel code den du generieren musst um das vollzubekommen. (kennst du einen dieser basic programmierer der seinen code auf groesse optimieren musste weil es nicht in die 64kb passt? :D). das budget fuer code war eher 8kb, weil noch music, sprites...
-
C++ wird doch nur bei den großen Blockbuster-Spielen eingesetzt. Die meiste Anzahl an Spiele sind aber die die im Browser oder auf dem Android-Geräten laufen und das ist alles ein bunter Mix aus Sprachen.
C++ ist schon lange nicht mehr DIE Sprache ohne die nichts geht. Wir leben ja nicht mehr im Jahre 2000.
-
LOLAlter schrieb:
Amiga500 schrieb:
, das war ASM + direkte Programmierung der Chips pur. Früher hat sich jeder ab 12 an ASM ran getraut heute brauchen sie ein Studium und eine VM...LOL
Ja klar, jeder. [...] Und heute kann niemand mehr Assembler und kennt auch keine Interna der CPU.[...]
doch, es stimmt schon, daß auf dem C64 Assembler-Programmierung nichts Besonderes oder (fast?) Normalfall war. Was wären denn die Alternativen gewesen? Basic: das eingebaute hatte - glaube ich - keine Befehle für Grafik und Sound außer PEEK und POKE. Basic-Compiler gab es. Forth gab es und war wahrscheinlich eine ziemlich effiziente Alternative, aber Forth ist ungewohnt und nicht jedermanns Sache. Es gab auch C (und Logo und vielleicht auch Pascal), habe ich aber nicht gekannt.
Die Heimcomputer der 8-Bit-Ära waren allerdings auch erheblich weniger komplex als heutige PCs. Die konnte man wirklich noch fast bis ins letzte Bit kennen, mit Schaltplänen, Bus-Timingdiagrammen, und ROM-listings. Hat jemand einen Schaltplan von seinem PC? Von der Grafikkarte seines PC? Der Amiga-500-Schaltplan war in meinem Benutzerhandbuch abgedruckt, da war allerdings auch viel Funktionalität in speziellen ICs für Sound, Grafik usw versammelt (Denise, Agnus, Paula oder wie sie hießen)
