Posts by mrsid

    Manchmal fragt man sich echt. Wie kann z.B. @ in verschiedenem Kontext so verschiedene Bedeutungen haben? In Variablen das Target, in Recipes Unterdrückung des Outputs, bei Targets zeigt es Target Groups an, gerne dann in Verbindung mit doppelten wie einfachen Doppelpunkten. An anderen Stellen werden munter haufenweise andere Sonderzeichen eingestreut, - um Fehler zu ignorieren; ^, <, >, *, %, ? in Kombination mit einer ganze Latte von Buchstaben für Unmengen von automatischen Variablen... Und da reden wir noch nicht einmal vom unsäglichen Tab vs Space in der Syntax.


    Vielleicht liegt's ja an meinem Alter, aber ich kann mir Sonderzeichen einfach schlecht merken. Ein paar Schlüsselworte wäre da echt besser gewesen. Aber vermutlich stammt das alles aus einer Zeit, wo jedes Byte wertvoll war...

    Ich glaub da hat einfach jemand mal in Perl programmiert...

    Ich hasse make auch. Deshalb verwende ich es nicht mehr. :D


    Es gibt andere Buildsysteme, und im allgemeinen funktionieren die besser als make. Es ist natürlich eine Umstellung, aber für mich war es das die Mühe wert.

    Prince of Persia hab ich mit make gebaut. Damals hab ich mich durchgewurschtelt, aber danach hab ich das bereut.


    Ab Canabalt und DkJr hab ich auf SCons umgestellt, auch wegen meiner Python Affinität. Vorerst nur für den Code, aber mit Sonic dann auch komplett für die Daten. Damit konnte ich das ganze Spiel von den original Assets (.png/.psd/.sng/.ins/etc.) direkt mit einem komplett vollständigen Dependency-Baum bauen.

    Da SCons auch die Inhalte hasht anstatt nur auf die Filesystem Mod-time zu schauen, ist das Resultat immer korrekt und bei Änderungen immer in Minimal-Zeit fertig, und man kann das auch verlässlich auf allen Cores parallel laufen lassen.


    Mit make wäre ich bei Sonic wohl verrückt geworden (141 Source Files, 149 Asset Files, 44000 Zeilen Code).

    SCons ist nur eines von vielen System, schau dich mal um was dir am Besten zusagt...

    Ich hab das ja schon vor Jahren in diesem Fred geschrieben: das Problem bei so einem Spiel ist nicht die Engine, sondern die Steuerung und die Fahrphysik. Man sollte erstmal das machen und sich nicht mit der Darstellung beschäftigen…

    Jein. In meinem ursprünglichen Konzept war z.B. das EasyFlash 1 (1 MB ROM) eine der Voraussetzungen. Nur weil eine App (oder ein Modul davon) blitzschnell aus dem ROM kopiert wird, statt sie von Diskette zu laden, ist das noch lange kein "geladen halten" oder Multitasking. Trotzdem ist das blitzschnell im Verhältnis zu dem, was man vom C64 (oder GEOS im Diskettenbetrieb) kennt. In einem anderen Vorschlag sollten Apps (oder Bestandteile) über das WIC64 von einem Server (der auch im LAN stehen kann) "geladen" werden.

    Das funktioniert aber nicht wirklich weil Applikationen ja auch ihren Zustand/Daten im RAM halten. Wie hast du dir das vorgestellt?

    Ich habe ChatGPT vor über einer Stunde mal aus jux und dollerei mit einem Sourcecode von Super Mario gefüttert und gebeten mir daraus ein funktionierendes Spiel für den C64 zu schreiben. Natürlich wird da viel Grütze bei rauskommen...vermutlich ist der Code auch sehr durcheinander da mir Tele gerade alles in Textblöcken ausgibt und zwischendurch immer wieder Schwierigkeiten hat, vermutlich fehlt viel...aber mich würde einfach nur mal interessieren, ob das was da raus kommt Ansatzweise funktionieren könnte und brauchbar ist (ich habe ausser Basic-Grundkenntnissen eigentlich null Ahnung davon). Du hast nicht zufällig Lust, da nur mal grob drüber zu schauen ob das funktionieren KÖNNTE - oder ChatGPT totalen Murks fabriziert?

    ChatGPT kann leider gar nicht wirklich C64 programmieren. Das KI Modell ist darauf ausgelegt Output zu produzieren das auf den ersten Blick richtig aussieht (damit das Reward Modell es gut bewertet) sich aber bei genauerer Inspektion als unvollständig oder inkorrekt herausstellt. Dabei kommt nix funktionierendes raus…

    Hatte Prince of Persia nicht auch in der ersten Releaseversion Probleme mit dem C128-2MHz-Modus?

    Ja, aber nur weil der 2 MHz Modus beim Speichern aufs Flash via EAPI eingeschaltet war. Ab Version 1.1 wurde das dann nicht mehr gemacht, wodurch es auf einem original EF1 auch am C128 funktioniert hat.

    Nein mit 64 KB kommt man da nicht sehr weit.

    Man braucht zwei 64 KB banks für die Screen und Color RAM Daten. In der dritten Bank sind dann die Sprites. In der vierten Bank sind verschiedene andere Sachen (Musik, Charset Animationen, Map Grafiken, etc.). Es ist nur sehr wenig frei. Unter 4 Banks (256 KB) wird das also wahrscheinlich nix. Wenn's eine Chance gegeben hätte das mit weniger als 256 KB zu machen, dann hätte ich das getan.


    Die Level Grafiken brauchen so viel Platz weil die ja direkt kopiert werden, und daher unkomprimiert in der REU liegen müssen.