Spielsteuerung vs. animierte Grafikszene? Wann im Programmablauf werden solche Objekte aktualisiert?

[2d Computerspiele]

Bei der Computergrafik gibt es ja in der Regel zwei Buffer und da ist es so, während der Inhalt des ersten Buffers angezeigt wird, wird der zweite im Hintergrund verändert und die Änderungen der Grafikobjekte, die sich ändern sollen, berechnet.
Nur ist aber nicht jedes Grafikobjekt gleich wichtig.
Am wichtigsten ist in erster Linie erstmal die Spielerfigur, da diese ja reaktionsschnell reagieren soll, aber was ist z.B. mit funkelnden Sternen oder Wolken die sich bewegen?
Die sind ja nicht so relevant, aber werden die auch bei jedem Bild neu berechnet?

Bei der 3d Grafik dürfte (Imposter ausgenommen) alles neu berechnet werden, aber nur weil etwas neu gezeichnet wird, bedeutet das nicht, daß gleichzeitig alles neu animiert werden muß. Die Postition der 3d Objekte die sich im 3d Raum ändern, dürfte also nicht ständig neu aktualisiert werden, sondern nur die Sicht des Spieler auf eine recht statische 3d Welt.
Aber meine Frage richtet sich eher an 2d Grafik, z.b. bei einem Jump & Run.
Wie oft wird da das ausehen, eines Sterns, der funkel soll, verändert?
Also mal größer mal kleiner gemacht?
Läuft die Berechnung jedesmal, für jedes Bild, von neuem ab oder sagt man, daß sich die Sterne n-m nur bei jedem 10 Bild neu aktualisiert werden sollen, während die Sterne n1-m2 zwar das gleiche gilt, aber diese bei dem aktuell folgenden Bild dran sind?
Man also die Arbeit aufteilt?
D.h. von 300 Sterne, die ersten 50 für das 1. Frame, die nächsten 50 für das 2. Frame usw.?
Oder ist es gar so, daß diese in einen eigenen Thread gepackt werden?

Wie macht man so etwas im Detail bei einem 2d Computerspiel?

[cooky451]

Du musst doch eh jedes mal den kompletten Backbuffer neu bemalen, da kannst du nichts sparen! (Vielleicht mit ganz dreckigen Hacks, aber mach das lieber nicht.)

[rapso]

als frueher manche systeme/spiele das in software machten, wurde wirklich nur das veraendert was neu dazu kam bzw sich veraendert hat, wenn bei einem iso spiel gescrollt wurde, hat man den sichtbaren bereich umkopiert und dann am rand das fehlende neu gezeichnet.

Jump&Runs sind ja eher eine domaene der konsolen, diese hatten meistens spezial hardware um das zu zeichnen, diese haben z.b. einen index buffer auf sprites und einen sprite buffer, beim anzeigen geht dir hardware dann nicht einen linearen speicher durch (also keinen framebuffer), sondern wirklich nur den indexbuffer und kopiert aus den sprites die pixel. je nach hardware hatte man mehrere 'layer' fuer sowas.

auf neuen betriebssystemen hat man eher keine moeglichkeit auf die hardware zuzugreifen, entsprechend zeichnen die graphikkarten alles neu.
es haellt dich aber natuerlich niemand ab es in software so zu machen wie zu dos zeiten, falls du wirklich was aufwendiges zu zeichnen hast und sich wenig aendert, kann das schneller sein.

[2d Computerspiele]

cooky451 schrieb:

Du musst doch eh jedes mal den kompletten Backbuffer neu bemalen, da kannst du nichts sparen! (Vielleicht mit ganz dreckigen Hacks, aber mach das lieber nicht.)

Naja, aber funkelnde Sterne gehöhren ja eher zu den Animationen als zum Backbuffer.

Für den Backbuffer könnte man z.b. entweder die alten Daten nehmen, also Aussehen des alten Sterns oder Stern neu berechnen und das gehört wieder zur Animation dazu.

[hustbaer]

Wie macht man so etwas im Detail bei einem 2d Computerspiel?

Heutzutage macht man es im Prinzip gleich wie bei 3D Spielen, also immer alles neu zeichnen. Weil's (viel) einfacher ist, und die Hardware es erlaubt.

Was das Aktualisieren des Spiel-Zustandes angeht, also z.B. die Positionen von Gegnern, die Grösse/Farbe/... deines Funkelsterns etc.: das wird normalerweise auch für jedes Frame gemacht.
Wenn man jetzt z.B. für den Funkelstern (oder allgemein irgendwas was sein Aussehen ändert) nicht genug Animationsphasen hat, so dass sich nicht jedes Frame was ändern kann, tut man normalerweise trotzdem pro Frame neu berechnen welche Animationsphase "aktuell" verwendet werden soll. Auch wieder: weil es einfacher ist.

Oder ist es gar so, daß diese in einen eigenen Thread gepackt werden?

Macht bei einem 2D Game IMO keinen Sinn. Man könnte bestimmte Dinge in einen Thread verlagern, z.B. die KI bei Strategiespielen (oder Brettspielen o.ä.). Updates des Szenengraphen macht man aber normalerweise nur im Main-Thread. Und das Zeichnen sowieso.

p.S.: früher war das natürlich alles anders, da die Hardware es eben nicht erlaubt hätte immer alles neu zu zeichnen.

Bei Space-Invaders wurden die einzelnen Invader nacheinander versetzt, vermutlich sogar ohne irgendein Double-Buffering. Dadurch ergab sich die eigenartige Wellenbewegung der Invader.

Das "nicht neu zeichnen" von Objekten die sich gegenüber dem Hintergrund nicht bewegt hatten war auf vielen Systemen sowieso Standard. Computer wie Amiga oder Atari hatten keine ausreichend mächtige Sprite-Hardware, daher wurden bewegte Objekte oft einfach in den Grafikspeicher gezeichnet. Dafür konnte man aber das Bild im Grafikspeicher grösser machen als was am Bildschirm sichtbar war, und dann einfach durch das Ändern eines Zeigers drinnen rumscrollen.

Manche Spiele gingen noch weiter: bei der Amiga Portierung von R-Type war IIRC das Spieler-Sprite flüssig animiert (es wurde vermutlich ein echtes Hardware-Sprite verwendet), der Rest (Hintergrund, Gegner, Schüsse etc.) aber nur jedes 2. Frame aktualisiert.

Das ist schon alles irgendwie interessant, aber es ist mittlerweile ziemlich nutzloses Wissen geworden. Sogar auf jedem Smartphone hast du heute einen ziemlich mächtigen 3D-Chip, der die paar Pixel, die das kleine Handy-Display hat, in Null-Komma-Nix vollgemalt hat.

[2d Computerspiele]

hustbaer schrieb:

Das ist schon alles irgendwie interessant, aber es ist mittlerweile ziemlich nutzloses Wissen geworden. Sogar auf jedem Smartphone hast du heute einen ziemlich mächtigen 3D-Chip, der die paar Pixel, die das kleine Handy-Display hat, in Null-Komma-Nix vollgemalt hat.

Danke für deine Ausführliche Antwort.

Gibt es dieses Wissen der Geschichte der technischen Realisierung von Computerspielen eigentlich in Form eines Buches?
Es wäre nämlich doch eigentlich viel zu schade, wenn dieses Wissen einfach so verloren gehen würde, nur weil die Hardware heute schnell genug geworden ist.
Denn ziemlich interessant finde ich das Thema ebenfalls.

Dann würde mich noch interessieren, aber welcher CPU Generation man bei 2d Spielen nicht mehr solche Tricks verwenden mußte.
War das z.B. schon ab dem Pentium 1 via Software so, oder brauchte es dazu wirklich die ersten 2d/3d Grafikkartenchips?

Anderseits würde ich noch bezüglich dem Punkt "lohnt sich nicht mehr" gerne wissen, ob das generell so gilt.
Denn wenn man die Tricks anwendet, dann hätte man bei einem komplexen Spiel ja z.b. wieder viel mehr Rechenzeit für z.b. die KI zur Verfügung.

Und wenn ich mir die 3d Welt anschaue, dann dürften solche Tricks doch zumindest bei der Physikberechnung hilfreich sein, oder?

[cooky451]

2d Computerspiele schrieb:

Und wenn ich mir die 3d Welt anschaue, dann dürften solche Tricks doch zumindest bei der Physikberechnung hilfreich sein, oder?

Dreidimensional kommst du an einer Neuberechnung eh nicht vorbei, zumindest wüsste ich nicht wie. Aber wo ist da jetzt eigentlich dein Gedankengang zur Physikberechnung

[hustbaer]

Gibt es dieses Wissen der Geschichte der technischen Realisierung von Computerspielen eigentlich in Form eines Buches?

Ich kenne zumindest keines. Allerdings findet man noch einige Artikel im Netz. Hab aber keine Liste, also frag nicht nach Beispielen.

Und natürlich gibt es noch Plattformen wo es bestimmte Optimierungen doch noch interessant sind. Ein Gameboy DS(i) hat z.B. nicht gerade unlimited Rechenpower, da kann man schonmal ein wenig optimieren.

Dann würde mich noch interessieren, aber welcher CPU Generation man bei 2d Spielen nicht mehr solche Tricks verwenden mußte.
War das z.B. schon ab dem Pentium 1 via Software so, oder brauchte es dazu wirklich die ersten 2d/3d Grafikkartenchips?

Keine Ahnung
Ich schätze ab dem Pentium war es ziemlich uninteressant beim "Logik-Update" zu tricksen. Bei der Grafik-Ausgabe ist es bei PCs aber sicher erst mit Beginn der 3D Ära uninteressant geworden. Bzw. bei Windows Spielen etwas früher, da man unter Windows über den Grafiktreiber schon früher den Hardware-Blitter der Grafikkarte nutzen konnte (unter DOS gab es AFAIK keinen Standard, d.h. man hätte für jede Karte eigenen Code schreiben müssen).

Anderseits würde ich noch bezüglich dem Punkt "lohnt sich nicht mehr" gerne wissen, ob das generell so gilt.
Denn wenn man die Tricks anwendet, dann hätte man bei einem komplexen Spiel ja z.b. wieder viel mehr Rechenzeit für z.b. die KI zur Verfügung.

Und wenn ich mir die 3d Welt anschaue, dann dürften solche Tricks doch zumindest bei der Physikberechnung hilfreich sein, oder?

Siehe oben (Gameboy DS(i) etc.).

Was 3D Spiele angeht: da wird auch genug getrickst. z.B. werden Objekte "eingefroren", wenn die Physik-Engine erkennt dass sie sozusagen "stabil stehen". Solche Objekte werden dann erst wieder simuliert, wenn sie von etwas anderem angestubbst werden.

Oder man interpoliert zwischen Physik-Frames (bzw. extrapoliert anhand der letzten bekannten Geschwindigkeit der Objekte), falls die Physik zu lange braucht, oder bei Netzwerk-Spielen die Updates vom Server nicht oft genug kommen. Dadurch leidet die Genauigkeit der Simulation etwas, aber die Grafik bleibt wenigstens schön flüssig.