Bad Apple für CPC?

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

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

C64:
https://www.youtube.com/watch?v=fu7rRYkWsyk

Speccy:
https://www.youtube.com/watch?v=cd5iEeIe7L0

Ich hatte mal vor einer Weile schon die Grafiken geripped, und ein "Pseudo-Video" erstellt:
https://www.youtube.com/watch?v=6vaSJvF7-9w

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)
📎 nq - Bad Apple!! (2016).zip

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.

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

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.

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?
📎 badapple.zip

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...
📎 count.txt

Könnte "GGS" eventuell helfen ?

////////////////////////////////////////////////////////////////////////
// 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; 

....

📎 ggs.zip

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 ?

— Shining
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?

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 ?

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

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

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

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

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

Also Sound und Bild sollten wir getrennt von einander behandeln 🙂 Hab das mit den Bildern mal durchgespielt. Mit gute Auflösung brauchts viel Platz (trotz Komprimierung). Und mit einer Auflösung wie auf anderen Computern siehts doof aus.

In dem Fall wäre eine Kompression wie RLE(?), Lauflängen Komprimierung wohl ganz gut. Man könnte es auf Bytes oder halbe Bytes (8 oder 4 MODE 2 Pixel) beziehen. Und man könnte Bits anstatt Bytes nutzen wenn alles im Bildschirmspeicher entweder &00 oder &FF ist. JPEG wär hier glauch ich nicht sinnvoll, das das ja eher auf Vierecke abziehlt.

Nun ist die Frage die: Immer neue Bild aufbauen (brute Force) oder nur die Unterschiede ändern. Das wäre dann das was der FilmeMacher unter FutureOS macht, nur leider etwas zu viel Speicher-Verschwenderisch. Ein neuer Algorithmus könnte da helfen, nur hab ich grad momentan kaum Zeit für irgendwas.

Hi TFM,

nee JPG wäre etwas sehr unpassend. Ich habe ehrlich keine Idee, wie eine gute Kompression aussehen könnte. Mit Pattern könnte viel Platz gespart werden, aber das ganze sollte auch schnell genug sein. Es kommt also nur ein Schreiben der Änderungen in Frage.
Wenn jemand Vorschläge hat, gern her damit. Ich mache gerne das "pre-Prozessing".

Gruß,

slarti

Wie gesagt, ich habe da ja bereits einige Zeit mit experimentiert und mich mit dem pre-Prozessing beschäftigt.. In einem schon weit fortgeschrittenen Versuch habe ich ich mir ein PC-Programm geschrieben, welches als erstes jeden Frame etwas schlechter macht indem er die bytes im Bildschirmspeicher normalisiert. Nach der Normalisierung sind Bytes entweder 0xff oder 0x00. Das Viseo ist dann immer noch rel. ansehnlich. Anschliessend generiert mir das Tool eine Datei in der Pro frame die Byte-Änderungen so codiert abgelegt werden, dass ich sie rel. einfach in den CPC-Speicher schreiben kann. Ich benutze pro byte im Bildschirmspeicher ein WORD welches folgendermassen aufgebaut ist:

Höchstes Bit gesetzt (0x8000): Neuer Frame
0x4000 gesetzt: Byte muss den Wert 0xFF bekommen ; nicht gesetzt: 0x00
Die 2 Bits darunter geben an, ob das Byte im Bereich 0xC000, 0xD000, 0xE000 oder 0xF000 liegt und die niedrigsten 12-Bits konkretisieren dann die korrekte Adresse.

Beispiel:
Byte an der Adresse 0xF780 ist das erste eines Frames und muss auf 0xFF gesetzt werden. Dann würde der Eintrag in meiner Datei lauten: 0xF780. Würde das Byte auf 0x00 gesetzt werde müssen, wäre der Eintrag: 0xB780. Wäre es auch nicht für einen neuen Frame: 0x3780.

Mein Problem bei meinen bisherigen Ansätzen ist aber die resultierende Datenmenge. Ram-mässig kann man ja ohne grosse Klimmzüge bei CPC-Usern max. 512KB erwarten. Und ich habe keine Ahnung, wie man schnellen Bildaufbau incl. Musik gewährleisten könnte und dann die Daten z.B. von einem M4-Board nachläd...

Irgendwie klappte der Upload hier nicht:

https://drive.google.com/file/d/0B41boaSaIb9eWVpUekxmbXVCMDA/view?usp=sharing

Da gibt es mal meine bisherigen unkomprimierten Daten als TXT-Datei und als BIN-File.

Soo meine Version des bösen Apfels nimmt langsam formen an. Sie braucht einen CPC mit 64kB + 1MB RAM, PlayCity und entweder einem 3" Laufwerk als Laufwerk A und ein 2-Kopf-Laufwerk B (macht dann aber nicht viel spass) oder z.B. ein M4 (das ist dafür genial und schnell).

Das Teil ist noch nicht ganz fertig, ich suche aber schon mal jemanden, der so eine Hardware hat und mir ein Video von dem ganzen Demo machen kann. Denn das ganze läuft in keinem Emulator 100% akkurat. Im JavaCPC gibt es Sound, dafür stimmt da das Timing nicht. Im WinAPE stimmt das Timing einigermaßen aber der Ton bleibt stumm. Kann jemand helfen ?

Kleine Anekdote: Ich hatte zuerst die einzelnen Sequenzen komprimiert auf dem M4 und habe die dann entpackt. Ich habe die ganzen blöcke jetzt in der M4-Version ungepackt auf der SD-Karte denn dann geht das laden VIEL schneller als wenn der CPC das auch noch (obwohl er dann weniger laden muss) entpacken muss. Finde ich schon krass und total geil wie schnell das laden mit einem M4-Board geht.