Richtig, den Fortschritt schön zu RGCD schicken. UND... natürlich vorher auch hierher einen Screenshot oder eine Appetithäppchengrafik posten.
Hallo Besucher, der Thread wurde 26k mal aufgerufen und enthält 163 Antworten
letzter Beitrag von alx am
RGCD 16KB Game Compo 2014 (Dev)
- enthusi
- Erledigt
-
-
Ok :), ein paar Pixel bzw. Ausschnitte/Häppchen mache ich evtl. , da nette Idee natürlich (Spannung). Denn wenn mehr, würde man ansonsten das Spiel sofort quasi ganz kennen, wäre es ein kompletter Screenshot :). Es ist nämlich nicht soo komplex, "komplex" sind nur die freien Einstellmöglichkeiten daran.
Es ist basic und ist aus Basic (aber ich lade die Spritedaten und Chars nicht mit Datazeilen ein keine Sorge, soo schlimm nicht :)). Wird aber compiliert und ist dann dadurch für das was alles an 'paralleler' Kalkulation (nee leider keine Interreupts/Interruptroutinen ;)) abgeht relativ ok flott. -
Bei BASIC denk dran, das soll am Ende in ein Cartridge!
Da ist es etwas tricky an BASIC zu gehen.
-
Ja wird sich zeigen, das Cartridge-gefriemel kommt am Ende :-\. Ich weiß nicht, ob das Compilat dann noch den Basicinterpreter braucht (z.T. vlt.) aber man kann die cartridge ja abschalten, erst sobald alles an seinen Platz ist im Speicher, soweit ich weiß und dann ist Basic und Kernal wieder verwendbar vom Prg. .
-
Ja wird sich zeigen, das Cartridge-gefriemel kommt am Ende :-\. Ich weiß nicht, ob das Compilat dann noch den Basicinterpreter braucht (z.T. vlt.) aber man kann die cartridge ja abschalten, erst sobald alles an seinen Platz ist im Speicher, soweit ich weiß und dann ist Basic und Kernal wieder verwendbar vom Prg. .
Diese Annahme würde ich an Deiner Stelle am besten als Erstes prüfen. Ich dachte, bei den RGCD-Cartridges hat man 16K ROM ($8000-$BFFF), und wenn man das via $01 abschaltet, dann hat man dort ($8000-$BFFF) stattdessen RAM, also kommt man niemals an das BASIC-ROM.
-
"aber man kann die cartridge ja abschalten,"
Nein kann man nicht.
Und bitte NICHT erst 'am Ende' als Cartridge bauen, sondern das von Anfang an testen...(!)Siehe auch hier:
RGCD 16KB Game Compo 2014Man hat selbstverstaendlich kein BASIC, wie ssdsa schon schrieb eben.
Compiliertes BASIC ist also nur dann drin, wenn der resultierende Code kein BASIC verwendet UND auch keine Kernel-Calls die sich durch das BASIC hangeln (kommt auch vor).Es ist nicht viel was man braucht um ein lauffaehiges 16KB cart zu erstellen, aber es ist nicht nichts.
-
Ich dachte wenn schon Kernal und Basic im code am Anfang der cartridge initialisiert werden, auf diversen Bsp. auf codebase, dann ist es auch nutzbar ? Aber scheint ja doch nicht so zu sein, wie angenommen.
Wenn's dann leider nicht klappen/laufen sollte -ich probiere das vorher dann 'mal aus-, dann kommt das einfach auf csdb, in 'nem gewöhnlichen d64 File veröffentlicht. -
Ansonsten kannst du basic in die 2. haelfte deines roms packen, dann sollte das alles gehen - aber dann bleiben halt nur noch 8k...
-
Wird aber compiliert
Ok, welchen Compiler benutzt du denn?
-
Den "Blitz!" compiler. War -neben evtl. noch dem Data Becker Basic Compiler von '84-, der "einzig wahre", der ohne Probleme und einfach mit meinem Prg. lief/läuft.
--
8KB wäre dann mit Basic Rom im Rom definitiv zu wenig für mein Zeug auch mit / trotz Exomizer. -
Was alx sagt könnte man zur Not noch ausbauen. BASIC-ROM gepackt im Cartridge unterbringen, und das dann ins RAM entpacken. Den Kernal kann man ja einfach umkopieren. Da kommst du dann evtl. mit weniger als 8k hin.
-
Es gibt da viele Moeglichkeiten
Wichtig ist nur, dass man die selbst fruehzeitig testet und ausprobiert damit man seine gesamte Herangehensweise gegebenenfalls anpassen kann.
Ich habe bisher sicher 3/4 aller Entries auf die eine oder andere Weise mehr oder weniger intensiv fixen muessen, weil es kurz vor Schluss dann hiess: "und jetzt noch eben auf Cart".
Dabei waeren schon einige Entries sonst verloren gegangen (was auch sehr schade ist wie ich und wir finden).
Wer fuer Cart programmieren moechte _muss_ sich einfach einmal kurz damit auseinandersetzen was das bedeutet und welche Vor- und Nachteile das mit sich bringt.
Yars' Revenge z.B. nutzt das 'ewige Cart-ROM' explizit zu seinem Vorteil aus.
Wenn Dein Projekt Gross und Toll wird, koennte irgendwann z.B. das 64KB-Modul von RGCD interessant sein fuer Dich.
DAS kann man abschalten
Quod Init Exit ist z.B. compiliertes BASIC.Generell gibt es zwei wichtige Dinge bei Modulen:
- der C64 durchlauft KEINE Reset-Routine sondern startet quasi direkt im Code des Moduls
-> alles was wichtig ist, muss man selbst initialisieren. Da das KERNEL ROM aber zur Verfuegung steht, kann man sich auf eine Reihe von JSR $kernel beschraenken
(sie z.B. Codebase64.org da habe ich einige templates hochgeladen), wenn man z.B. das blaue Aufflackern verhindern will, muss man eben genau diese Routine auslassen und dessen (Teil)aufgaben selbst uebernehmen, etc...
*** dabei sind viele Dinge wichtige die man NICHT sofort sieht. Wenn man z.B. d015 oder sonstwas nicht initialisiert mag das in Vice super aussehen, am echten C64 dann aber je nachdem ueberhaupt nichtmehr.
(und den SID nicht vergessen, wenn man die entsprechende Kernel-Routine nicht aufruft- das BASIC ROM ist nicht sichtbar. Egal was man macht. Du dachtest vermutlich an Punkt 1 nur (BASIC 'einrichten'). Das waere auch notwendig aber nicht hinreichend wenn es gar kein BASIC ROM gibt
Aus Erfahrung halte ich es fuer wenig praktikabel Teile des BASICs im RAM zu extrahieren, es sei denn es geht einem jemand zur Hand der 'sowas' kann. uU muessen $01 settings im Basic-Kompilat ebenfalls angepasst werden etc. Kein Hexenwerk, aber nicht immer selbstredend.
-
Endurion: Das wäre evtl. ein gutes Projekt für die DoReCo. Ich bring' die fertigen 4-5 Einzelfiles (Spiel, Chars, Sprites, Soundefekkte / Basic Rom) mit und du hilfst dabei die alle mit dem Exomizer zu einem exomizer File zusammenzufügen und natürlich mit Angabe / Verwendung der bei den Files jeweils bereits gespeicherten/enthaltenen Ladeadresse/Entpackadressen ins Ram. Und schreibst dann noch die Kopierroutine für Kernal und ggf. den Rest für das CBM80 Cartridge Format ;).
-
Ich glaube, ich bekomme grade zur DeRoCo wieder diese Kopfschmerzen, irgendwas bahnt sich da an
-
Sehe gerade: Mittlerweile seit kurzem sind dann doch sogar schon Preview Bilder online auf der HP.
-Mit meinem Kram bin ich noch auf dem letzten obigen Stand, noch nicht weiter getestet, ob's funzen würde oder nicht.
-
Gibt es, oder hat es schon mal ne Compo für "echte" 16K Games gegeben ?
Das täte mich näher interessieren. Code, der speziell für den Bereich von $8000-$C000 ausgelegt ist, ohne dass vorher irgendetwas entpackt wird was teilweise mit viel Mühe auf 16K zusammengecruncht wurde.
Das ganze dann speziell noch für 8K ($8000-$A000) um die Sache abzurundenHucky
-
Code, der speziell für den Bereich von $8000-$C000 ausgelegt
Es steht jedem frei sowas bei der RGCD compo einzureichen
Also Compo selbst sehe ich da wenig Sinn, da der Uebergang von 'gecruncht' zu 'echt' wie Du es nennst ja fliessend ist. -
Nunja, wenn man speziell etwas für den 16K Bereich codet hat man eigentlich keine Chance gegenüber den Leuten, die mehr Speicher und andere Möglichkeiten haben und das dann nachher "einfach" zusammencrunchen.
Für mich ist der Übergang nicht fließend
Es wäre doch mal interessant sich wirklich nur auf den Bereich zu beschränken mit Ausnahme auf Zugriff zum Kernal und natürlich der Zeropage sowie Register von CIA, Video+Audio.
Quasi nur das RAM zwischen $8000 und $C000 nutzen.Hucky
-
ja, von sowas als Compo rate ich auch eher ab, ggf. müsste man sehr genau die Regeln definieren, was "NUR" $xxxx bis $yyyy nun bedeutet. zB gab es bei einer MYD internen compo da mal missverständnisse, ob es z.B. erlaubt sei, mittels Codegenerator (also nichts mit Crunching) Bereiche außerhalb des Rahmens zu nutzen oder nicht. Mates waren nachher schon beleidigt, dass ich 'ne halbe leere VIC-Bank erzeugt hatte
-
Dann wirst Du an einer 4K compo teilnehmen muessen und einen Cruncher benutzen
Platzsparend coden/packen gehoert nunmal dazu.
Mit Fliessend meine ich:
an einem Ende als postprocessing Exomizer am anderen Ende ohne ueberhaupt ueber Platz nachzudenken stumpf loscoden. Am besten mit ACME und dann enigen KB mit Nullen aufgefuellt.
Die Realitaet liegt dann meist dazwischen, fuer eine Compo mit Limitierung ganz klar weiter am Exomizer-Ende.
Man wird sich ueberlegen bei einem 16 KB Rollenspiel mit Text, ob man den Text als PETSCII, oder 7, 6, 5 Bit codiert ablegt, eben genau UM PLATZ ZU SPAREN.
Ein anderer codet einen eigenen Packer, wieder andere nehmen einfach Exomizer etc.
Eine Compo MIT Platzlimit aber OHNE Kompression ist ein Widerspruch in sich meiner Meinung nach.
Du wirst Dich eines Tages wohl oder ueber mit Packern auseinandersetzen muessen Es ist ein spannendes Thema und die "Grossen Blackboxartigen" wie Exomizer und Pucrunch laengst nicht immer angesagt. Siehe z.B. die aktuelle Text-Kompressions-Compo.
Da haben Exomizer & Co nichts zu melden