Bad Apple für CPC?

[Devilmarkus]

Vielleicht kennt ihr ja die "Bad Apple" Demo, welche auf Youtube kursiert.

Diese gibt es inzwischen schon für C64 und ZX Spectrum:

C64:

Speccy:

Ich hatte mal vor einer Weile schon die Grafiken geripped, und ein "Pseudo-Video" erstellt:

Was jedoch echt cool wäre, wenn wir das "REAL" für den CPC umsetzen könnten.

Die Original-Musik habe ich als 6 Kanal Chiptune im .pt3 Format (Sollte mit TotO's PlayCity und SyX Player oder mit SymbOS SymAmp spielbar sein, also sollte es ja irgendwie auch möglich sein, dies zu Integrieren?)

Wer kennt sich also mit Komprimierung aus, eventuell einen Videocodec?


Anhang: Der Chiptune vom 128k Speccy. (Spielbar mit oben genannten Tools bzw. mit dem Vortex Tracker)

[Shining]

Die Mukke ist ja nicht so das Problem. Ich hatte ja mal den Playcity-Player für SDCC umgeschrieben. Defence spielt ja auch PT3s ab. Hier wurde der Player nur für den normalen AY im CPC abgespeckt.

[Shining]

Von wo läd der Speccy das video denn ? Hat der das alles im RAM ?

[Shining]

Hab mich gerade ein bisschen eingelesen.

Derjenige, der das für den 8088 gemacht hat, hat sich einen compiler geschrieben, der dann die Änderungen pro frame als assembler-anweisungen in das ouput-file packt. Dadurch kommt sein output file für Bad Apple auf 20 MB.

TFM hatte auch schon mal im anderen Forum was zu Bad Apple auf dem CPC geschrieben.

Cool wäre das ganze ja.

[Devilmarkus]

Also wir hätten im CPC ja (Erweiterung vorausgesetzt) 64k + 512k (Zumindest jeder Emulator kann das, und eben manche CPCs auch)
Ein paar ganz Wenige haben sogar 4mb Ram im CPC...

Ich habe die 5481 einzelnen SCR (16k CPC Format) mal an Demoniak geschickt, der kennt sich recht gut aus, im Bereich der ASCII Animation...
Vielleicht wird es ja was....

Vielleicht will ja hier jemand mit den SCR Dateien herumspielen?

[Shining]

Ich wollte mal als Grundlage die Änderungen pro Frame wissen:

Ich habe mal ein Programm geschrieben welches mir eine CSV-Datei erzeugt, die immer anzeigt wie viele Bytes sich zwischen zwei Bildern geändert haben. Das schwankt sehr. Ich habe die CSV-Datei mal angehängt.

Alles in allem (ohne dass wir jetzt von Zusammenfassung oder ähnlichen Komprimierungsmethoden reden) sind die geänderten Bytes 5753724 = 5,49 MB.

Spannend fände ich ja das auf einem CPC ohne Erweiterungen. Da sind wir dann erst einmal aber meilenweit entfernt....

Würde man denn die Daten so schnell von einem M4 oder so lesen können ?

Ich finde die Idee des 8088-Demo-Machers eigentlich ganz gut also pro frame von einem PC-Programm code erzeugen zu lassen welches byte an welcher speicherzelle zu ersetzen ist. Zusätzlich (hat er auch gemacht) könnte man dann z.b. hintereinander gleiche Bytes zusammenfassen. Mit CPC-Rechenzeit kenne ich mich nicht so gut aus. Keine Ahnung, ob diese Worst-Case-Anzahl der Bytes pro Frame machbar sind und ob man es dann auch noch schafft, die Daten für den nächsten Frame zu laden...

[SRS]

Könnte "GGS" eventuell helfen ?

Code Select Expand


////////////////////////////////////////////////////////////////////////
// ggs.c
// Affichage d'une annimation en 20 images
// Mode 0
// repernsente la dense Gangnam Style !!!
////////////////////////////////////////////////////////////////////////

#define  SCR_SET_MODE0_s \
__asm ld a,#0 \
call #0xBC0E \
__endasm;

....


[Shining]

Mit 20 Bildern kommt man ja leider nicht so weit. Wenn sich jeder Frame ändert käme man noch nicht einmal eine Sekunde weit. Man bräuchte also entweder ganz viel "5-6 MB" RAM oder man müsste superschnell Bildänderungen nachladen können. Von Diskette wäre das wohl utopisch. Wie schnell kann man denn von SD oder Festplatte ins CPC-RAM laden ?

[Devilmarkus]

Wie schnell kann man denn von SD oder Festplatte ins CPC-RAM laden ?

Das wiederum halte ich für Utopisch... Von 10 CPC Usern haben vielleicht 1-2 die Möglichkeit, von SD Karte bzw. HDD zu Laden?

[Shining]

Ich bastel hier immer noch dran. Mein bisheriger Ansatz läuft aber immer darauf hinaus, das die Datenmenge einfach zu gross ist und ich denke, laden und gleichzeitig pro frame einiges ins ram schreiben wird wohl nicht gehen (wenngleich ich nicht der FDC-Profi bin). Da müsste wohl ein Ansatz wie auf Speccy und C64 her: Das ganze Video in ähnliche Sprites zerlegen und dann abspecken. Muss ich mal genauer drüber nachdenken. Da wird mein PC-Analyseprogramm deutlich komlizierter.

By the way...Die SCRs liegen ja hier für mode2 vor. Kann man die irgendwie einfach in mode 1 und mode 0 (auch schwarz/weiss) konvertieren ?

[slartibartfast]

Hallo Shining,

eine Konvertierung von mode 2 nach mode 1 (oder 0) als Datenreduktion würde meines erachtens keinen wirklichen Sinn machen, es sei denn es wird ein Kompressionsalgorithmus verwendet (der auch noch rattenschnell dekomprierten kann). Dann wäre eine Datenreduktion möglich.
Die Konvertierung selbst, um ein kleineres Datenvolumen für einen komprimierten Stream zu erreichen, wäre aber sehr einfach.
Die Farben für ein vordefiertes Pattern in den modes 0 und 1 werden eh einmalig im GA festgelegt.
Bleibt nur noch der Kompressionsalgorithmus als Knobelaufgabe, da ein Frame ja während eines V-Sync gemalt werden sollte. Das ist bei knapp 4 MHz eine schöne Arbeit.
Da hier ein wechsel von Schwarz nach weiss stattfinden soll, eignet sich ein XOR auf die einzelnen "Pixel"; es muß also "nur" die Anzahl der zu invertierenden Punkte, bzw. die der zu übersehenden Punkte im Datenstream abgelegt werden. Das könnte (?) schneller sein, als jeden Frame aus einem Puffer heraus zu füllen (selbst wenn man zwei Bildschirm-Speicher (&4000-&7FFF und &C000-&FFFF) benutzt, um es ruckelfrei hin u bekommen).

Nur so als Anregung ...

Gruß,

slarti

[slartibartfast]

Zur Kompression (Vorschlag):

0 + Anzahl Bytes zu überspringen + 1 + Anzahl Bytes zu ändern + XOR-Pattern + 1 + Anzahl zu ändern + (anderes) XOR Pattern + ...

Es muss dann darauf geachtet werden, dass der Bildspeicher bei &FFFF zuende ist und wieder bei &C000 weitergemacht werden muss.
Ich denke, das bei einer entsprechenden Auflösung (Modus) das Datenvolumen des Streams ausreichend klein ist und in Echtzeit in einer 25tel Sekunde den Bildschirm aktualisiert werden könnte.
Selbst mit LDIR oder findigen Tricks bekommt man beim Z80 keine 16KB in einer 25tel Sekunde kopiert. Also die Daten 1:1 von einer RAM-Disk (Puffer mit 4MB oder mehr ...) in den Graphikspeicher zu kopieren wird m.E. nicht klappen.

Gruß,

Reiner

[TFM]

Anstatt dem XOR Pattern kann man gleich den neuen Wert nehmen, schneller und einfacher.

[slartibartfast]

Hallo TFM,

ja, das Auslesen eines Bytes, invertieren und wieder Speichern ist langsamer und bringt gar nichts. Da hast Du vollkommen recht.
Ich glaube den Stream voruberechnen wird die eigentliche Knochenarbeit: Video in einzelne Bilder zerlegen, Auflösung anpassen und ausgehend von einem schwarzen Bildschirm den Stream generieren. Da wäre mein Laptop gut eine Woche mit beschäftigt, glaube ich.
Technisch gesehen sollte das mit Python relativ einfach sein - Die Bilder fressen aber selbst als JPG viel Platz auf der Platte.

Offene Fragen für mich:
Wie können den die Audiodaten hineingezwengt werden?
Mit IDs > 1? Alle n Bild-Frames einen Audio-Frame? Wenn der Stream immer genau 16KB ändert, kann der Algorithmus schneller sein, da er nicht immer auf das Ende des Bildschirms testen muß. Am Ende eines Blocks wartet schreibt er ggf. die Audio-Daten und wartet auf ein V-Sync, bevor er mit dem Bildschirm weiter macht. So sollte das dann funktionieren, oder? Ich bin kein Demo-Aktivist, habe davon also nicht die geringste Ahnung. Auch Sound-Programmierung ist nicht mein Bereich. Ich könnte nur den Video-Stream vorberechnen, wenn die technischen Fragen geklärt sind.

Mal sehen, ob ich meinen Server dazu überreden kann .... (Wenn ich Zeit habe).

LG,

slarti

[slartibartfast]

Liebe Leut',

es sind knapp 78k Frames - insgesamt 60 MB an JPGs. Das geht aber viel kompakter.
Die JPGs sind noch vielfarbig und nicht monochrom. Mit entsprechender Kopression rechne ich mit ca. 3KB/Frame, wobei einige (z.B. der fallende Apfel) nur jedes 8. Bild aktualisiert und dann mit wenigen Bytes Änderung. Die Zeit kann für ein Auffrischen des Caches genutzt werden (Daten nachladen).
An mindestens einer Stelle werden die Farben invertiert - das sollte auch schnell gehen.
7800 * 3KB = 2,34MB an Bilddaten zum Streamen (also zzgl. Audio-Daten). Die Daten sind aber nur hoch geschätzt.
Bei ca. 4 min. ergibt das ca. 10KB/s. Also muss ein grosser Speicher her.
Der Algorithmus kann auch einfacher und schneller werden:
Grundaufbau:
3 Bytes: Adresse (low + high) und Wert.
Ist High < &c0:
00: warten auf Framesync; Audiodaten verarbeiten, ggf. Farben invertieren
01: Farben ändern
02 - 191: Audio-Daten

Passt das so?

LG,

slarti