letzter Beitrag von Nognir am
So ein Easy Flash 1 habe ich seit heute schonmal.
Das war erstmal die Grundvoraussetzung für mich.., weil ich so viel wie möglich stets auf der real Hardware schreibe u. teste.
Jetzt "nur noch" die Motivation finden mein Prg. weiterzuentwickeln.. :).
Sobald ich mich mit dem Exomizer oder vielmehr mit der Umwandlung nach .CRT Format herumschlage, eröffne ich sicher nochmal einen extra Thread, denn
damit werd' ich bestimmt erstmal ein paar Probleme haben. 
Dabei wird es zum Glueck aber gar nicht noetig sein, Dich in das CRT Format voll einzulesen (siehe codebase64.org)
Das haben bis auf TRSi glaube ich ALLE falsch gemacht bei der ersten Compo
Effizienter und dann auch richtig gelingt es mit dem vicetool 'cartconv' dass Dir ein rohes binary (ab $8000 mit CBM80 Kennung und Co) in ein CRT umwandelt.
Und keinesfalls Tips von mir Cartridges betreffend annehmen! 
..dann auch richtig gelingt es mit dem vicetool 'cartconv' dass Dir ein rohes binary (ab $8000 mit CBM80 Kennung und Co) in ein CRT umwandelt.
Jo, hab' ich auch schon erfahren/gesehen.
--
Mein Hauptproblem wird vlt. sein, dass das Exomizer etc. gepackte File (weil es wohl gepackt werden muss, um unter 16 KB zu bleiben) meine Einzeldateien für Soundeffekte, Zeichensatz, Sprites auch wieder jeweils an ihre org. / gedachte Speicherstelle entpackt. Aber das wird sich dann zeigen, ist ja nicht unlösbar.
(Ist wahrscheinlich ganz simpel, wenn man vlt. einfach alles -vom Speicherabbild inkl. der Lücken- zusammenpackt, dann wird es wahrscheinlich eh wieder genauso entpackt.
-Vorher die Lücken mit Nullen vollpocken ;), weil die ja auch nicht immer 'leer' sind und sonst auch gepackt unnötig Speicherplatz fressen würden.. :), sobald dann aber alle Lücken gleiche Werte haben, kann der Packer das dann zumindest ordentlich packen. Ein Packer kann ja nicht von sich aus von einer 'Lücke' oder 'nicht Lücke' / relevant oder nicht relevant unterscheiden :).)
So, Name und Logo unseres Beitrags kann ich ja schon mal rausrücken: Unser Spiel wird Monster Buster heißen und es ist diesmal wieder ein Action-Titel. Die Grafik ist zu 90% fertig, Taxim hat die Musik schon komponiert und ALeX muss noch kräftig (wie schon in den letzten Monaten) in die Tasten hauen, was den Code angeht – aber die meisten Basisroutinen (vor allem der Sprite-Multiplexer) stehen schon.
Das von mir gepixelte Logo kann man sich auf der CSDB angucken, wo ich es als eigenständige Grafik released habe.
Freu mich schon 
Gibt's eine aufgebohrte Version von Spacechem?
Ich werde wohl auch teilnehmen, in der Hoffnung das Devil Ronin Demake fertig zu bekommen. Da hatte ich ja vor Jahren schon mal angefangen, und wegen irgend einer Kleinigkeit liegen gelassen. Wer das mal antesten will, sucht mal nach Devil Ronin. Ist ein klasse Spiel (ich meine das originale PC-Spiel mit 64-Musik und -Grafik)
Gibt's eine aufgebohrte Version von Spacechem?
Ja, mit zusätzlichen Leveln, Level-Editor und In-Game-Musik von unserem neuen Gruppen-Mitglied Taxim. ALeX muss da "nur noch" einmal drüberschauen, die Anleitung schreiben und die Sachen an HeavyStylus/RGCD übergeben.
Ich werde wohl auch teilnehmen, in der Hoffnung das Devil Ronin Demake fertig zu bekommen.
Die ganzen Hintergründe passen aber in 16K eher nicht hinein, oder?
Nee, ich bin ja ohne schon bei 30 kB. Da aber die Sprites beim Kämpfen übermäßig viele Frames haben (und dabei auch so aussehen wie ich beim Wandstreichen) werde ich da mächtig eindampfen.
Die Hintergründe werden vermutlich ziemlich leiden 
Mein Hauptproblem wird vlt. sein, dass das Exomizer etc. gepackte File (weil es wohl gepackt werden muss, um unter 16 KB zu bleiben) meine Einzeldateien für Soundeffekte, Zeichensatz, Sprites auch wieder jeweils an ihre org. / gedachte Speicherstelle entpackt.
Das ist schon in exomizer eingebaut, hier ein Beispiel aus meinem makefile:
exomizer sfx sys pharaoh.prg -o pharaoh.exo pgsprites.spr@53248 pgcharset.col@61184 pgcharset.chr@63488
Ein Gerüst wie man dann das gepackte prg im modul aufruft gibts auch direkt bei RGCD.
Das von mir gepixelte Logo kann man sich auf der CSDB angucken, wo ich es als eigenständige Grafik released habe.
Das Titel-Logo ist genial! 
Wie wäre es mal mit einem screenhot?
Danke. Soweit sind wir noch nicht – technisch ist zwar fast alles wichtige im Programm-Code drin aber präsentationsreif ist das ganze noch nicht wirklich. Evtl. haben wir zur Doreco Party schon etwas mehr fertig und können dort was zeigen – sicher ist das aber auch nicht. Die Titel-Musik steht – aber Levels haben wir noch keine und bei der Grafik ändere ich noch immer viel herum (da bin ich etwas überperfektionistisch und schiebe einzelne Pixel immer wieder hin und her und gucke mir das dann auch noch auf echter Hardware an). Glücklicherweise stört paralleles Arbeiten bei uns nicht, da ALeX einfach immer meine aktuellsten Assets aus unserem Arbeits-Dropböx-Ordner beim compilieren verwendet. Außerdem wollen wir auch nicht zu viel zu früh verraten, weil wir die Überraschung nicht zu sehr kaputt machen wollen. Ich finde, eine Compo soll ja möglichst spannend sein.
Ich finde, eine Compo soll ja möglichst spannend sein.
Du magst Monster, oder? Jaja, die die Spannung... Nagut, etwas zum Heben der Spannung, bittesehr:
pgtube1.gif
Ausserdem: 16k sind zu wenig. Hab fast 40k belegt, mehr kann exomizer nicht in 16k quetschen. 
Was mach ich jetzt? (Mein Plan zur Zeit: Panisch im Kreis laufen)
Lazycow, wieviel platz brauchst du denn noch in etwa? Mein "Beruf" ist ja quasi das Datenkuerzen, vielleicht kann ich dir helfen.
das ist halt die frage in sachen RAM: wurde das stumpf durch den exomizer gejagt oder gibt es bereits levelcrunching? Lass Dir mal von fratzengeballer helfen, sieht wirklich gut aus, wäre schade, wenn es nun an wenigen kB scheitert
Ok, hab man nachgezählt: Unkomprimiert hat es 32k und komprimiert 16k, aber der Sound fehlt noch und ein Mini-Lied aus dem goattracker hat ca. 2k (davon 1.5k schon der Player) - Autsch!
Hier mal, was ich noch im Ärmel hab:
- Programm ist C und assembler: Evlt kann man den cc65-init-code irgenwdie kürzen?
- könnte ein paar Hintergrund-blöcke weglassen, aber sieht jetzt schon ehr karg aus
- könnte den Zeichensatz aus dem rom nehmen, spart ca. 288 bytes
- wenn ich die objekte in tabellen statt in structs ablege, wird der code ca. 300 bytes kürzer
Dann die grossen "Opfer":
- wenn ich scrolling weglasse, spare ich ca. 2k (wär schade)
- die Spielfigur hat 2 sprites übereinander mit 26 animationsphasen, wenn ich das overlay sprite weglasse spare ich 1664 bytes (wär schade)
Die levels werden generisch erstellt, der code dazu ist ca. 2-3k, da wird kaum was zu holen sein. Trotzdem, bin für Tips dankbar. (jedes Byte zählt)
Flixt, das generische Erstellen hast du schon (du meinst mit Pseudo-Random etc.?)
Grundsätzlich würde ich, wenn machbar, C komplett raustreten. Das bringt ja eine Runtime mit, die einiges wegfrisst. Ist da ein optimierender Linker bei? (der alle nicht benutzten C-Funktionen rauswirft?)
Die allerletzten Sparmethoden bei Soulless waren dann unkontrolliertes Vertauschen von binären Daten, damit die Exomizer besser gepackt bekommt. Also ähnliche Daten aneinander reihen, oder Lookup-Tabellen ineinander schieben (soweit machbar). Sowas kann man aber eigentlich nur zum Abschluss machen.
Endurion: Bei Soulless haste aber noch etwas Platz verschwendet, bei den Sprites z.B. habe ich noch ein wenig herausbekommen 
da hättest du noch ein paar Bytes mehr gehabt..
Ich hab ja aufgehört zu stopfen, als alle drei Teile ins Cartridge gepasst haben
