Bad Apple für CPC?

[TFM]

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.

[slartibartfast]

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

[Shining]

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...

[Shining]

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.

[Shining]

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.

[Devilmarkus]

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...

[Shining]

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.

[Devilmarkus]

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)

[TFM]

Ha! Ich freue mich schon auf's erste Release! 

[Devilmarkus]

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...

[TFM]

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. 

[Shining]

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).

[Shining]

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....

[Devilmarkus]

Echt gelungen!
Gefällt mir sehr, auch das Intro!
 

[Devilmarkus]

Ich habs mal auf Juhutube hochgeladen