Du bist nicht angemeldet.

Kindische ungebremste Freude: Kommende Spiele

Lieber Besucher, herzlich willkommen bei: Pixelor. Falls dies dein erster Besuch auf dieser Seite ist, lies bitte die Hilfe durch. Dort wird dir die Bedienung dieser Seite näher erläutert. Darüber hinaus solltest du dich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutze das Registrierungsformular, um dich zu registrieren oder informiere dich ausführlich über den Registrierungsvorgang. Falls du dich bereits zu einem früheren Zeitpunkt registriert hast, kannst du dich hier anmelden.

djberningo

yondan

Beiträge: 814

Wohnort: Ingolstadt

Beruf: Senior Software Engineer

  • Private Nachricht senden

313

16.12.2021, 15:43

Zitat von »v3to«

Das funktioniert über den DMA der Ram Expansion. Dadurch ist der Speicher-Zugriff nahezu in Echtzeit möglich, was auch der Grund ist, weshalb das Spiel für diese Erweiterung und nicht zb Easyflash entwickelt wurde. Die Grafik ist bis auf das Intro-Logo auch komplett in Zeichensatz gehalten.

Btw verwenden auch Mayhem und Sam's Journey Zeichensatz-Grafik. AFAIK nutzt derweil nur Mayhem VSP zum Scrollen (was in der Demoszene eher für Bitmap-Grafik eingesetzt wird). VSP läuft allerdings auf gefühlt jedem zweiten C64 nicht stabil und stürzt willkürlich ab. Es gibt inzwischen eine Methode, VSP sicher einzusetzen. Nur laut Aussage von Codern in meinem Umfeld, geht das zu Lasten der Geschwindigkeit.

Vielen Dank für die Richtigstellung und die Erklärungen! Ich bin jetzt doppelt beeindruckt, wie gut Sam's Journey aussieht - bei den Beschränkungen des Multicolor-Char-Mode.

Auch Sonic sieht fantastisch aus. Aber was bewirkt der DMA hier? Laden / Austauschen des Zeichensatzes in Verbindung mit Rasterinterrupts? Gibt es irgendwo im Netz eine technische Beschreibung oder was die Herausforderungen waren? So etwas interessiert mich sehr.
oliver-berning.de
@OliverBerning

henrikf

Pixelor-Team

  • »henrikf« ist der Autor dieses Themas

Beiträge: 6 828

Wohnort: Bad Aibling / Bayern

Beruf: Software-Entwickler

  • Private Nachricht senden

314

17.12.2021, 14:41

Zitat von »djberningo«

[...] Gibt es irgendwo im Netz eine technische Beschreibung oder was die Herausforderungen waren? So etwas interessiert mich sehr.

Mich auch, mich auch! :D
--== Island2Live / Henrik Fisch==--
Homepage: http://www.island2live.com/ deviantART: http://island2live.deviantart.com/
Spielt gerade: Yonder: The Cloud Catcher Chronicles

v3to

yondan

Beiträge: 531

Wohnort: Bielefeld

  • Private Nachricht senden

315

20.12.2021, 18:37

Da ich kein Coder bin, kann ich das vermutlich nicht so wirklich im Detail wiedergeben. Es geht hauptsächlich um das Scrolling.

Zum Vergleich kann man Spiele wie Turrican oder Sam's Journey heranziehen. Die Spiele zeigen wie schnell in etwa ein großflächiges Scrolling mit Farbram auf dem System sein kann. Bzw das dürften so 4 Pixel Verschiebung pro Bilddurchlauf sein. Nun scrollt Sonic den ganzen Bildschirm mit variabler Geschwindigkeit bis zu 16 Pixel pro Bilddurchlauf (doppelt so schnell wie die Master-System-Version btw). Das ist auf einem Vanilla-C64 so nicht möglich.

Ich meine der Zugriff per DMA ist gegenüber Kopiervorgängen per CPU etwa 8x schneller, ich mag mich da irren. Jedenfalls sehr viel schneller.

das Spiel ist übrigens inzwischen erschienen:
https://csdb.dk/release/?id=212190

und auch ein Gameplay-Video vom ersten Level

djberningo

yondan

Beiträge: 814

Wohnort: Ingolstadt

Beruf: Senior Software Engineer

  • Private Nachricht senden

316

23.12.2021, 12:48

Vielen Dank! Ja, 4 Bit kann gut hinkommen, weil das Hardware-Scroll-Register ein "Shifting" von 0-7 erlaubt, ehe man Screen- und Farb-RAM auf die nächste Position eines Character-Blocks umkopieren und das Scroll-Register zurücksetzen muss.

Das habe ich vor langer Zeit programmiert und festgestellt, dass man aus Performance-Gründen tunlichst verschachtelten Loops vermeiden sollte und lieber mehrere (4?) 8-Bit Loops (per X-Register inkrementiert) verwendet, um den ganzen Screen umzukopieren. Das Farb-RAM hatte ich damals nicht umkopiert, auch weil nicht mehr allzu viele "Cycles" im gleichen Rasterinterrupt übrig blieben, um ein 50-Hz-Softscrolling zu erreichen. Mit der heutigen Erfahung und den besseren Assemblern hätte ich versucht, das Farb-RAM in den gleichen Loops umzukopieren. Warum ich früher nicht auf die Idee kam, verstehe ich selbst bis heute nicht.

Die Idee, REU zu verwenden, finde ich jedenfalls großartig. Seit Ultimate64 und UltimateII+ ist das auch keine exotische Erweiterung mehr - im Gegensatz zur SuperCPU.

Ich schaue mir das Spiel wegen der technischen Aspekte auf dem Ultimate64 an. Durchspielen werde ich es vermutlich nicht, denn Sonic habe ich bereits auf dem Megadrive und auf dem Master System (per MiSTer-FPGA) durchgespielt.
oliver-berning.de
@OliverBerning

henrikf

Pixelor-Team

  • »henrikf« ist der Autor dieses Themas

Beiträge: 6 828

Wohnort: Bad Aibling / Bayern

Beruf: Software-Entwickler

  • Private Nachricht senden

317

24.12.2021, 10:24

Zitat von »djberningo«

[...] dass man aus Performance-Gründen tunlichst verschachtelten Loops vermeiden sollte und lieber mehrere (4?) 8-Bit Loops (per X-Register inkrementiert) verwendet, um den ganzen Screen umzukopieren. [...]


<klugscheißermodus>
(das nehme ich mir mal heraus, weil ich das ca. 1993 hautnah miterlebt habe und es hier super passt)

Bei Compilern heißt das »loop unrolling«: Man programmiert keine Schleife, sondern wiederholt den Code in der Schleife einfach so oft manuell, wie die Schleife ausgeführt werden soll. Das war, zu Zeiten von MS-DOS/Windows 3.x und als Borland noch tolle Compiler gebaut hat, der heiße Scheiß. Auch zum Beispiel die GNU-Compiler können das heute immer noch:

https://gcc.gnu.org/onlinedocs/gcc-4.5.2…ptimize-Options
-funrol-loop

Auf aktuellen Prozessoren ist das nicht mehr notwendig, weil die - kein Witz! - so etwas selber erkennen und mit Hilfe der Pipelines und Caches ein Loop-Unrolling intern in ihren Eingeweiden vornehmen. Aber bei den 8-Bit-Prozessoren (6502/Z80/6809 und so weiter) und auch noch den 16/32-Bit-Prozessoren (8086/68000/80386/i486/Pentium) war das echt Gewinnbringend.

Die Idee ist einfach: Wenn eine Schleife 25 mal ausgeführt wird (bitte korrigiert mich, ich meine das Color-RAM des C64 hat genau diese Zeichenauflösung von 40x25 Byte) und der Sprung an den Anfang der Schleife und die vorherige Abfrage, ob die Schleife schon zu Ende ist, sagen wir mal zusammen 6 Taktzyklen dauert ... dann spart man 25x6 = 150 Taktzylen. Der Code wird zwar länger, aber das ist in solchen Zeitkritischen Anwendungen meistens weniger das Problem.

</klugscheißermodus>
--== Island2Live / Henrik Fisch==--
Homepage: http://www.island2live.com/ deviantART: http://island2live.deviantart.com/
Spielt gerade: Yonder: The Cloud Catcher Chronicles

djberningo

yondan

Beiträge: 814

Wohnort: Ingolstadt

Beruf: Senior Software Engineer

  • Private Nachricht senden

318

24.12.2021, 14:20

Zitat von »henrikf«

Bei Compilern heißt das »loop unrolling«: Man programmiert keine Schleife, sondern wiederholt den Code in der Schleife einfach so oft manuell, wie die Schleife ausgeführt werden soll.

Genau, "Loop Unrolling" oder "Loop Flattening", wenn die Loops verschachtelt ("nested") sind. Das ist neben Controller- und FPGA-Programmierung auch heute noch mit Hochsprachen sinnvoll, beispielsweise wenn die Loops asynchron oder parallel ausgeführt werden sollen. Das habe ich zuletzt mit Kotlin vor zwei Jahren so gemacht, weswegen ich sehr gute Laufzeitverbesserungen erreichte.

Zitat von »henrikf«

Die Idee ist einfach: Wenn eine Schleife 25 mal ausgeführt wird (bitte korrigiert mich, ich meine das Color-RAM des C64 hat genau diese Zeichenauflösung von 40x25 Byte) und der Sprung an den Anfang der Schleife und die vorherige Abfrage, ob die Schleife schon zu Ende ist, sagen wir mal zusammen 6 Taktzyklen dauert ... dann spart man 25x6 = 150 Taktzylen. Der Code wird zwar länger, aber das ist in solchen Zeitkritischen Anwendungen meistens weniger das Problem.

40x25 ist richtig. Da gibt es so einige Ansätze (auch aus alten Zeitschriften), wie man Speicherbereiche effizient umkopiert. Am Ende läuft es aufs Takte-Zählen hinaus. Und ein guter Makro-Assembler macht es viel leichter, weil man das Unrolling als Makro umsetzen kann. Ich hatte damals nur den Monitor vom Action Replay Cartridge MK VI und später SMON, aber keinen Makro-Assembler. Heute wird man ja mit Cross-Platform-Tools wie z.B. KickAssembler regelrecht verwöhnt :-D

Zitat von »henrikf«

(das nehme ich mir mal heraus, weil ich das ca. 1993 hautnah miterlebt habe und es hier super passt)

1993... Da hatte ich meinen ersten Computer, den C64, gerade mal ein Jahr und war gerade zum BASIC-Profi aufgestiegen. Erst ein Jahr später konnte ich einigermaßen gut Assembler, sodass ich was an die 64er-Redaktion schicken konnte.
oliver-berning.de
@OliverBerning

Ähnliche Themen