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)
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?
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...
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;
....
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 ?
Quote from: Shining on 24. October 2016, 13:20:27
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.
Hat da wohl jemand im JavaCPC den "Z80 Turbo" aktiviert?
Welches Timing stimmt nicht?
Lass mir mal bitte eine Alpha zukommen, und ich schaue es mir mal an...
Bei der Apfel-Animation stimmt das Timing ja schon ganz gut, ich muss das nochmal genau testen. Aber ich hab da noch ein Intro vorprogrammiert und da habe ich mit für mich neuen Techniken "geübt". Deshalb macht das Intro Hardwarescrolling, vertikale und horizontale Splitraster und benutzt die Rupture-Technik (ich wollt es halt ganz genau wissen :)). Und wie letztens schon geschrieben: Die horizontalen Splitraster funzen im JavaCPC nicht.
Ich hätte halt gerne ein Video, welches dann im optimalen Fall auch bei dem Hardwarescrolling nicht rucktelt und welches im intro den horizontalen Splitraster anzeigt.
Ich kann Dir aber gerne die tage eine Alpha zukommen lassen.
Ich bitte darum ;) Und, wenn möglich, Fotos bzw Erklärung, welcher Emulator es richtig macht, damit ich Vergleichen kann...
Rastertimings sind für mich seeeeeeeeehr Haarig teilweise noch im JavaCPC (Weil ich eigentlich von Emulation soviel Ahnung habe, wie vom Häkeln)
Ha! Ich freue mich schon auf's erste Release! :jubelaola:
Das angesprochene Problem konnte problemlos gelöst werden ;)
Was noch fehlt, finde ich, @Shining:
Einen schnelleren Trackloader... Keine Einzeldateien...
Ich kann gern mal Arnoldemu (Kevin Thacker) dazu anhauen, der macht vielleicht sogar nen Musical-Loader draus...
Naja, Tackloading ist nicht das schnellste, nur das bei dem man am meisten auf eine Disk bekommt.
Am schnellsten läd es unter FutureOS, vielleicht lässt sich dafür ja (später) auch mal eine Version machen. :zunge0020:
Das hat ehrlich gesagt bei mir jetzt nicht so die Priorität. Das ganze passt ja so ziemlich genau auf eine 3" Disk + eine zweite, zweiseitige mit 80 Tracks. Ich selber lade das immer mit dem M4-Board und da geht das rasend schnell. Ich denke, da ist die Nutzerbasis auch mittlerweile gross genug. Und mit dem XMASS ginge das ganze bestimmt auch. Ich denke so ein M4 haben bestimmt mehr Leute als 1 MB Zusatz-RAM. (Zumindest bevor diese 2MB-Erweiterung fertig ist).
So, genug. Hier isset:
Bad Arnold für erweiterte CPC. Ihr braucht:
- 1MB zusatz RAM
- Playcity
und am besten zum laden ein M4.
Mit weniger RAM läuft das Video dann halt kürzer und der CPC schmiert danach ab....
Echt gelungen!
Gefällt mir sehr, auch das Intro!
:jubelaola:
Ich habs mal auf Juhutube hochgeladen ;)
Ja super!!!
:jubelaola: :jubelaola: :jubelaola: :jubelaola: :jubelaola: :jubelaola: :jubelaola:
Edit: Kleiner Tip: Anstatt DISK die Datei bitte in DISC umbenennen, dann kann sie mit Autostart (= Control + Kleines Enter) gestartet werden. :-)
Mal ne ganz blöde Frage, ich wollte mal Bad Apple mit meinem ZMem und PlayCity testen.
Auf AppleA.dsk ist "DISK" Wenn ich das lade, kriege ich graue Rahmen und schwarzen Hintergrund, und es passiert nichts weiter.
Wenn ich "Apple.bin" lade, kriege ich eine Laufschrift, allerdings ist die nicht leserlich... gibt es noch irgendwelche andere Voraussetzungen die der 6128 erfüllen muss? CRTC oder so? Oder habe ich die falsche DSK erwischt? Ich lade das mit SaxDrive / FlashFloppy.
Naja, die andere Diskette ist in B eingelegt?
Quote from: TFM on 08. July 2019, 22:26:00
Naja, die andere Diskette ist in B eingelegt?
Oh, das könnte es gewesen sein! Hmm... BZD :zunge0020: