Vespertino world racing

Noch mehr Vorfreude :slight_smile:

Nur 2 Fragen:

  • Wir wissen, dass das Spiel im Cartridge-Format mit einem Adapter für CPC Standard und die Plus-Serie erscheinen wird, stimmt das?
  • Ist eine digitale Version für Emulatoren oder FPGA-Systeme geplant?
17 „Gefällt mir“

Schon wieder nur KI-Slop…

:Liegt weinend auf dem Boden:

1 „Gefällt mir“

Keine 4 Spieler auf demselben Bildschirm? Gebt mir mein Geld zurück, das ich noch gar nicht ausgegeben habe…

Rhino, ganz ehrlich, ich bin sprachlos.

RESPEKT an dich persönlich und an all die Leute, die daran mitgewirkt haben.

Angefangen bei Batman Forever im Jahr 2011 hast du der CPC-Community auf so viele Arten neuen Schwung verliehen.

Vielen Dank!

2 „Gefällt mir“

Das Killer-Spiel ist wie versprochen da.

Vielen Dank.

1 „Gefällt mir“

Ich kann nur sagen:

wtf.

1 „Gefällt mir“

Auch wenn man es erst noch auf echter CPC-Hardware sehen muss, sieht es echt beeindruckend aus, nicht mehr lange :alien::cool_button:

2 „Gefällt mir“

Einfach atemberaubend!

1 „Gefällt mir“

Einfach u n g l a u b l i c h !!!

1 „Gefällt mir“

Sieht echt beeindruckend aus, aber warum hast du die Slop-Maschine diesen miesen Trailer machen lassen?

Dreißig Sekunden Video – auf echter Hardware laufend – hätten den Zweck noch viel besser erfüllt.

1 „Gefällt mir“

Typisch meckeriger alter Knacker :smiley:

Ich bin mir bei World Racing im Titel nicht sicher. Real Racing Simulator klingt doch viel besser. Und wenn wir schon dabei sind, warum setzen wir nicht noch ein Gran vor Vespertino? Na bitte! Besser geht’s nicht!

OMG, stell dir mal eine Version auf einem Standard-Plus-Modul vor, vollständige Gamepad-Steuerung, spielbar auf einer gemoddeten 128K GX4000 :face_with_tongue:! Kannst du dir das vorstellen?

1 „Gefällt mir“

Interessantes Video. Es scheint meine Vermutung zu bestätigen.

Nachfolgend meine Vermutungen und Einschätzungen. Ich will das Ganze weder bewerten noch kleinreden. Das Ergebnis ist extrem beeindruckend. Bravo!

Die Gesamtstrategie beruht m. E. auf zwei Säulen

  • :chipmunk: Der Z80 hat keinen Befehlscache. Jeder Befehl kostet viel Zeit (im Vergleich zum i386 und neueren Prozessoren, bei denen Befehle, die mehrfach innerhalb einer kleinen Schleife ausgeführt werden, deutlich schneller laufen). Schneller Z80-Code ist Code, der weniger Befehle pro geschriebenem Byte ausführt. Daher lautet eine goldene Regel der Z80-Code-Optimierung: Entferne alle Befehle, die keine Bytes an das Ziel schreiben. Schleifen auflösen (Loop Unrolling). Es ist erstaunlich, wie viel man einsparen kann, wenn man diesen Ansatz auf die Spitze treibt. Genau durch das Ausreizen dieser Ideen ist es mir damals gelungen, Sunny Day (for A Shadow Party) :: pouët.net zu schreiben.
  • :optical_disk: Ein extremer Kompromiss zwischen Speicherbedarf und CPU-Leistung (Trade-off). Normalerweise hat der CPC nicht genug Speicher, um diese Strategie bis zum Äußersten auszureizen. Wenn man jedoch ein externes ROM hat, das beliebig groß sein kann, geht das noch viel weiter. Details dazu unten.

Details

  • :alien_monster: Bei genauer Einzelbildanalyse (Pixel Peeping) des Videos fällt auf, dass Autos mit Byte-Granularität gezeichnet werden. Die Breite wächst nach links und rechts in Schritten von jeweils zwei Pixeln. Wenn einer dieser Pixel ungewollt ist, wird er grau dargestellt. Auf den grauen Straßenabschnitten ist das unsichtbar, anderswo hingegen schon. Das ermöglicht einfachere und schnellere Zeichenroutinen: einfach Bytes schreiben, keine Masken, keine Bit-Operationen.
  • :high_voltage: Dennoch wird eine extrem schnelle Zeichenroutine benötigt. Hier gilt die oben genannte goldene Regel.
  • :left_right_arrow: Wenn sich das Auto nicht nach oben oder unten bewegt (insbesondere das eigene Auto), ist die Routine sogar noch einfacher und schneller.
  • :optical_disk: Reize diese Entscheidungen bis zum Äußersten aus, egal wie viel Speicherplatz es kostet. Genau deshalb funktioniert das nur mit einem ROM-Modul. Es werden riesige (schreibgeschützte) Speicherbereiche benötigt.
  • :window: Die riesigen, rotierenden Autos im Auswahlbildschirm basieren auf einfacher Delta-Kompression. Die meisten Pixel ändern sich nicht, und die Änderungen sind im Voraus bekannt, was das Ganze extrem schnell macht. Wenn massenhaft ROM-Bytes zur Verfügung stehen, macht man es genau so. Ähnlich ist es auch bei Sunny Day (for A Shadow Party) :: pouët.net, wo die tatsächlich geschriebene Byte-Menge n-mal kleiner ist, als es den Anschein hat (wenn ich mich recht erinnere, n=6).
  • :high_voltage: Alle animierten Elemente werden per „Graphics-as-Code“ gezeichnet. Das Zeichnen ruft keine generische „Zeichne-Etwas“-Routine mit spezifischen Objektdaten auf. Stattdessen bedeutet „etwas zeichnen“, eine spezialisierte Routine aufzurufen (z. B. eine eigene Routine für jedes Auto in jeder spezifischen Ausrichtung, eine Routine für jedes Objekt in jeder Entfernung). Die Routinen sind vorausberechneter Z80-Code, konzeptionell simpel: einfach Bytes schreiben, keine Schleifen, gar nichts. (Die Technik ist nicht neu und wurde schon in etlichen Produktionen eingesetzt. Ich habe das für die Goodies beim Levelübergang in Just Get 9 gemacht).
  • :optical_disk: Ein klarer Hinweis auf die Strategie „Sobald man davon ausgeht, dass ein riesiges ROM verfügbar ist, darf man auch einen riesigen ROM-Bedarf haben“, ist die Anzahl der Ansichten für jedes Objekt. Im Video sprechen die Entwickler von über 5000 Sprites. Wenn man Unmengen an Bytes hat und Tausende von Sprites über ein 3D-Modell eines Autos rendern kann – warum nicht? Das Ergebnis ist eine beeindruckend flüssige und ansehnliche Darstellung der 3D-Positionen der Autos auf der Straße.
  • :motorway: Das gilt vermutlich auch für die Darstellung der Straße. Man hat eine riesige Liste spezialisierter Routinen, die einfach einen komplett fertigen horizontalen Straßenabschnitt zeichnen. Dann wird für jede Zeile die passende Routine aufgerufen. Das dürfte schneller sein als das ohnehin schon schnelle Chase HQ, das grobe Abschnitte zeichnet und dann die weißen Fahrbahnmarkierungen nachzieht. Das ist natürlich komplexer als ein sich wiederholendes Muster wie in Sub Hunter, aber dieses Spiel beweist, dass sich riesige Bildschirmbereiche absolut flüssig animieren lassen, indem man einfach Bytes schreibt (pusht).
  • :window: Zudem kommt Double Buffering zum Einsatz, allerdings nicht für den gesamten Bildschirm. Ein vollständiger Overscan-Bildschirm entspricht 24 KB Nutzdaten. Mit gezielten CRTC-Einstellungen und eventuell einem Screen-Split lassen sich diese 24 KB „zusammenpacken“ (sodass der restliche Speicher nicht zu stark fragmentiert wird). Zwei Puffer bedeuten 48 KB. Es verbleibt ein komplett austauschbarer 16-KB-Bereich für Bank-Switching. Über diesen schaltet man die unzähligen Seiten um, um auf das physische ROM im Modul zuzugreifen. Sogar der Code selbst lässt sich in ROMs duplizieren.

Und… ich bin mir keineswegs sicher, ob das schon alles ist. Vielleicht (sehr wahrscheinlich) stecken da noch weitere Geheimnisse dahinter.

3 „Gefällt mir“

Vielen Dank für deine Worte!

1 „Gefällt mir“

Eine interessante Analyse, ich will gar nicht beurteilen, ob sie zutrifft oder nicht! :slight_smile:
Aber ich hätte da eine Frage… Bei dieser Art von Spielen ist die Straßenbreite normalerweise viel größer als die Breite des sichtbaren Bildschirms, da sich die Straße bei Seitwärtsbewegungen verschiebt. Würden die von dir vorgeschlagenen Routinen, die jede horizontale Linie zeichnen, nur den sichtbaren Bereich rendern? Falls ja, wie viele Routinen wären pro horizontaler Linie erforderlich, um horizontales pixelgenaues Scrolling zu erreichen? Danke!

Das ist absolut umwerfend. Einfach unglaublich!

Herzlichen Glückwunsch an das gesamte Team zu dieser phänomenalen Entwicklung.

@Rhino

Wird es in Zukunft Diskussionen über einige der im Spiel verwendeten Techniken geben?

1 „Gefällt mir“

Als ich hörte, dass das Spiel Tausende von vorgerenderten, im ROM gespeicherten Sprites nutzen würde, wusste ich, dass es eine Geschmeidigkeit bei Skalierung und Rotation bieten würde, die alles bisher Dagewesene übertrifft – und als ich es nun endlich in Bewegung sah, hat es mich keineswegs enttäuscht. Der CPC kann beeindruckende Dinge leisten, wenn man ihm jede Menge Speicher spendiert, aber es erfordert viel Arbeit, diesen auch sinnvoll zu nutzen.

Was mich wirklich beeindruckt hat, ist die Sorgfalt und Liebe zum Detail, die in das Frontend, die Menüs usw. gesteckt wurde. Das ist ein zeitaufwändiger und nicht immer unterhaltsamer Teil der Spieleentwicklung, und hier sieht alles so ausgefeilt aus, wie es nur geht, mit einem stimmigen Design, das alles zusammenhält.

Bei so viel Aufwand können wir nur hoffen, dass es sich genauso gut spielt, wie es aussieht. Ich sehe etliche Autos gleichzeitig auf dem Bildschirm, was vielversprechend ist. An den gegnerischen Fahrzeugen wurde definitiv nicht gespart.

4 „Gefällt mir“

Na ja, ausgerechnet du, der Master-Coder der Batman Group, stellst mir eine Frage zum Coden? Da muss doch ein Haken bei sein. :sweat_smile:

Und in der Tat, ich habe keinerlei Berechnungen angestellt – genau deshalb habe ich auch strategisch klug „eine Zillion Bytes“ geschrieben, was für eine willkommene „Unschärfe“ sorgt.

Okay, lass mich nachdenken und versuchen, deine Frage zu beantworten. Spezialisierte Routinen zu haben, die in allen Fällen eine komplette Straßenzeile schreiben, wäre simpel (konstante Zeit, 80 oder gar 96 Bytes bei vollem Overscan schreiben), würde aber eine extrem hohe Anzahl an Routinen erfordern. Eine Möglichkeit zur Reduzierung könnte sein, Bytes mit der Bodenfarbe von rechts zu PUSH-en, dann spezialisierte Routinen aufzurufen, um die Straße selbst zu schreiben, und dann noch mehr Bodenfarb-Bytes zu PUSH-en. Dieses Modell schränkt die Anzahl der Kombinationen zwar etwas ein, kann aber nicht zeichnen, wenn die Straße links oder rechts über die Bildschirmränder hinausragt. Mmmh, es gibt noch eine weitere Option, die die Anzahl der Routinen erneut begrenzt und gleichzeitig die Gesamtgeschwindigkeit hoch hält. Wie wäre es mit einer kaskadierten, zweistufigen Tabelle: Für eine gegebene Zeilengeometrie wird eine Liste kürzerer Routinen nachgeschlagen, und diese Routinen werden dann aufgerufen. Sie haben vorberechnete Bytewerte, um alle Pixel zu zeichnen, und ihre Anzahl ist deutlich kleiner. Das deckt sogar Situationen ab, in denen die Straßenzeile links und rechts über den Bildschirm hinausragt, ganz ohne Berechnungen zur Laufzeit. Liege ich da richtig, @Rhino?

(Achtung, Witz im Anflug :police_car_light:) Plot-Twist: Über all die Jahre waren die Vespertino-Teaser gefälscht, die Autoren fragen die Leute im Forum aus, sammeln ihre Antworten über die Jahre hinweg, bis eine ausreichend leistungsstarke KI existiert, füttern diese mit den Antworten und lassen sie die eigentliche Arbeit machen. :exploding_head: Nur ein Scherz. :smile:

Aber mal wieder im Ernst: Glückwunsch an das gesamte Team für diese beeindruckende Prod!

Nach all der Zeit und den vielen Teasern brenne ich darauf, Vespertino endlich zu sehen und zu spielen!

1 „Gefällt mir“