Asterix - wie wurde das eigentlich gemacht

ZeHa · 23. März 2017

Hallo,

ich finde es immer ganz nett, sich mal ueber die technischen Details von Spielen zu unterhalten. Hat jemand schonmal "Asterix" analysiert? Ich finde das Rendering ziemlich eigenartig, es scheint sich um Bitmap-Grafik zu handeln, die uebereinander geblittet wird. Allerdings koennen ja auch die Sprites sich korrekt im Vordergrund oder im Hintergrund der einzelnen Bitmap-Objekte (z.B. Haeuser und Baeume) befinden. So spontan haette ich da jetzt keine Idee, wie man sowas umsetzen koennte.

Was mich auch interessieren wuerde; der Bildaufbau ist ja manchmal furchtbar langsam. Ich fand es als Kind zwar irgendwie auch cool, wie sich die Bildschirme so Stueck fuer Stueck aufbauen, aber ich frage mich, ob das auch schneller hinzukriegen gewesen waere.

TheRealWanderer · 23. März 2017

Ich denke mal da wurde mit Spritemaskierungen gearbeitet. So hatte es @enthusi auch mit dem Adventure Caren gemacht: Caren and the Tangled Tentacles, enthusi & veto
Und bei Prince of Persia wurde auch sehr viel mit Spritemasks gearbeitet: http://popc64.blogspot.de/2011…g-hide-and-seek-with.html

Oder Predator:

[Externes Medium: https://www.youtube.com/watch?v=-_QMGqWVKPA]

In dem Video sieht man aber auch, wie Fehler beim Spritemasking aussehen.

Mac Bacon · 23. März 2017

Ich meine mich zu erinnern, dass bei Caren ein weiteres Sprite zum Maskieren benutzt wurde; PoP macht es in Software und ändert das Spielersprite entsprechend ab.

EDIT: Hier die Sprite-Maskiermethode in Basic 7. Auf einem C128 mit SPRDEF die Sprites 1 und 2 definieren und dann eingeben:

Code

100 sprite 1,1,1,1,1,1
110 sprite 2,1,2,0,1,1
120 movspr 1,100,100
130 movspr 2,100,100
140 movspr 2,90#5

Sprite 1 ist schwarz und liegt hinter den Buchstaben (geh mal mit dem Cursor drauf), Sprite 2 ist weiß und liegt vor den Buchstaben. Aber wenn sich die beiden Sprites überlappen, verschwindet Sprite 2 trotzdem hinter den Buchstaben, da Sprite 1 eine höhere Priorität hat als Sprite 2.

enthusi · 23. März 2017

Ja also moment. Da wird gerade alles verwechselt
POP macht meiner meiner nach gerade KEIN Sprite masking. Sondern in Software gerendert.
So machen es auch Maniac Mansion und Last Ninja.
Einige Spiele lassen Sprites hinter Bitmap laufen, das ist kein Sprite masking sondern umgekehrt. Bei Tusker oder so sieht man das.
Seltener wird ein Sprite als Maske VOR dem Spieler verwendet - z.B. bei The Detective.
Das wuerde ich dann Spritemasking nennen.
Was Caren macht bzw ich hab ich in Spielen bisher nicht gesehen. Wir haben eine Spritemaske HINTER dem Spielersprite die dafuer sorgt, dass die Bitmap HINTER dem Spieler durch den Spieler durchscheint.

TheRealWanderer · 23. März 2017

Zitat von Mac Bacon

PoP macht es in Software und ändert das Spielersprite entsprechend ab.

Zitat von enthusi

POP macht meiner meiner nach gerade KEIN Sprite masking. Sondern in Software gerendert.

Stimmt, ihr habt recht. Ich habe es gerade im Dev-Blog von POP gelesen

Zitat von Mr.SID

The other method typically used to obscure certain parts of a sprite is by overlaying them with another sprite that has a higher priority and contains the same graphics as the background. This however requires that sprite to share some of its colors with the background, which puts a restriction on the colors to use for the actual sprite (two out of three sprite colors are shared).
Another trick is to put one sprite behind the foreground layer and the lower priority sprite in front of the foreground layer. This will perform the same masking but the foreground graphics will hide the sprite that is causing the masking.
But I knew already from the size of the animation images that I'll need a lot of sprites and that using extra sprites for masking would be pretty much impossible. Plus that would've meant even higher memory usage.

After considering all of these options and also taking their complexities into account, I've decided for the one solution that would be slowest, but would yield the most accurate results: Actually modifying the sprite data in memory, for each frame, every time. Ouch.
After all, I wanted to have pixel-precise occlusion.
So whenever the character would walk behind a pillar or other occluding object, I would have to mask out those pixels of the sprites and replace them with the transparent color bit-pair.

Alles anzeigen

ZeHa · 12. Dezember 2017

Bin grad mal wieder auf ein Asterix-Video gestossen und habe mir die selbe Frage erneut gestellt und dann gesehen, dass ich hierzu mal einen Thread eroeffnet habe

Also im letzten Beitrag steht ja, dass es auch die Moeglichkeit gibt, einfach die Sprite-Daten live zu aendern, je nachdem wo das Sprite gerade rumlaeuft. Ist an sich einleuchtend, aber glaubt ihr wirklich, dass das in diesem Spiel so gemacht sein koennte? Teilweise gibt es ja sehr krasse "Z-Order", da viele Baeume usw. vor- und hintereinader sein koennen und die Sprites sich ja theoretisch sehr stark zwischen allem herumbewegen koennen. Ich stelle mir gerade den Aufwand, die Sprites je nachdem, zwischen welchen "Schichten" sie sich gerade befinden, entsprechend abzuaendern, extrem hoch vor.

Man nehme nur mal einen Screen wie hier im Video bei 4:55, oder bei 2:27

[Externes Medium: https://www.youtube.com/watch?v=eyU1E-BYWTA]

Generell muss ich auch nochmal sagen dass die Grafik fuer den C64 schon irgendwie sehr eigenartig und speziell ist. Erinnert mich auch ein bisschen an Win3.11-Grafik aber cool irgendwie

ZeroZero · 13. Dezember 2017

Normalerweise kenne ich das noch aus der 2-D Adventureprogrammierung so, dass man mehrere Planes bereit hatte, u. a. für die Ausmaskierung bestimmter Screenteile.

Eine Plane davon hatte die Z-Order der Objekte, also welches Objekt liegt in der Z-Order an welcher Stelle (z. B. ganz vorne die Spielerfigur, dahinter die nahen Bäume und Gebäude, dahinter wieder weiter entfernte Objekte usw. Sich unabhängig im Hintergrund bewegende Objekt haben eine entsprechende Z-Nummer zugeteilt bekommen, und man wusste VOR welchen anderen Objekten und HINTER welchen anderen Objekten diese dargestellt wird. Legt also die Zeichenreihenfolge fest...)

E D I T

Nachdem ich jetzt das Video ansehe, sieht es sehr stark danach aus, dass Asterix genauso gemacht wurde.

ZeHa · 13. Dezember 2017

Aber das wuerde ja bedeuten dass ziemlich viel Speicher verbraten wird fuer die einzelnen Planes, da ja somit nicht einfach nur der Bildschirm seine 8K benoetigt, sondern jede Plane noch zusaetzlich Speicher belegt. Gut, voellig unmoeglich wird es nicht sein, zumal die Planes auch nicht unbedingt die gesamte Hoehe des Bildschirms benoetigen muessen. Aber auf den C64 bezogen finde ich es schon irgendwie erstaunlich, wenn wirklich so vorgegangen werden sollte.

ZeroZero · 13. Dezember 2017

Ich habe Asterix nicht ausgeschnüffelt, denkbar wäre aber, dasss überhaupt nicht mit Hardwaresprites gearbeitet wurde, sondern die Figuren ebenfalls soft gecoded sind.....

Die Z-Plane wäre relativ klein, weil sie lediglich die Objektnummern und deren Z-Position speichern müsste. Sie muss keine Grafik ausmaskieren. Figuren, die sich in Z-Richtung bewegen können, ändern natürlich ihre Z-Nummer entsprechend.

ZeHa · 13. Dezember 2017

Die Sprites sehen aber sehr nach Sprites aus, wenn die softgecodet wären würde das farblich alles ganz anders aussehen denke ich. Daher halte ich das für unwahrscheinlich.

ZeroZero · 13. Dezember 2017

Ich habs auch nur theoretisch aufgeworfen. Wie gesagt, ich habe das Spiel noch nicht nach möglichen Spriteblöcken durchsucht.

Ich hatte nur überlegt: wenn das Spiel so sehr viele Z-Ebenen hat, dann kommt man mit den 7-8 Spritepriomaskierungen nicht besonders weit. Außerdem dachte ich immer, dass die Hardwaresprites nur eine Maskierung hätten für vor oder hinter der Bildschirmgrafik. Damit käme man ja nicht sehr weit.