Posts by daybyter

    Ich würde dann vielleicht mal langsam und schrittweise versuchen, die Routine ein bischen zu optimieren. Nach jedem Schritt schauen, ob Dein Bild noch lädt.


    Edit: verbesserte Version angehängt, wo jetzt zumindest mal das Sprite korrekt erscheint. Hab einiges am Makefile gemacht, so dass z.B. automatisch ein d64 Image erzeugt werden kann und der Emulator dieses auch gleich lädt und das Programm startet. Spart Zeit beim Testen...


    Ciao,
    Andreas

    Files

    • shooter.zip

      (15.26 kB, downloaded 7 times, last: )

    Hallo!


    Danke fürs Anschauen des Codes. Ja, die meisten Compiler sollten ja Multiplikationen mit 2er Potenzen durch Schieben ersetzen. Interessanter wird es aber, wenn man die Sachen über den Stack übergibt. Ich weiss nicht, wieviele Compiler dann das Argument weglassen, und direkt im Code der Funktion Konstanten benutzen. gcc z.B. kann ja auch gleich ganze Funktionen weglassen und inline compilieren. Ich trau dem cc65 aber ehrlich gesagt noch nicht soviel zu, weshalb ich halt recht viel per Hand optimiere. Und es sieht ja auch nur innerhalb der Lib-Funktionen bischen eklig aus. Von ausserhalb soll man das Ding als ganz normale Funktion benutzen können, so dass es einem wurscht ist, was genau darin passiert. Hauptsache es wuppt und ist schnell genug für ein Spiel... :)


    Die Sache mit der Geschwindigkeit bezog sich ja auf das Setzen der Sprite-Positionen usw. Und das findet ja während des Spielverlaufs permanent statt, sollte also schnell gehen.


    Ich hab jetzt mal ein ganz klein wenig was am Laufen. Hab alles auf ein D64-Image kopiert und per Vice gestartet. Das Laden des Sprites klappt noch nicht wirklich, weil er entweder die falsche Adresse setzt, oder wohl alle Farben auf Weiss setzt. Hab also nur ein weisses Klötzchen, anstatt eines Sprites.


    Das setzen der X-Position klappt anscheinend auch noch nicht wirklich, weil ich nicht an den rechten Rand komme. Anscheinend klemmt es da noch mit der Berechnung des High-Bits. Muss ich auch nochmal debuggen (Morgen ist ja auch noch ein Tag :) ). Ich steuer auch mit der Tastatur. Evlt. brauch ich mal nen USB-Joystick, oder so. Mal sehen, wie sich das entwickelt.


    Dann hab ich noch die Sprite-Enable-Funktion vergessen. *schäm*.


    Und das Einfügen der Sprite-Nummer in den Set-X und -Y Macros hat natürlich auch nicht geklappt. Es geht jetzt aber mit dem ## Befehl.


    Dann stimmt noch was mit dem Joystick-Port nicht. Ich frage Stick 1 ab, und Stick 2 scheint zu reagieren.


    Ich häng mal den aktuellen Stand an, falls jemand schauen möchte, was ich so treibe.


    Ciao,
    Andreas

    Files

    • shooter.zip

      (14.06 kB, downloaded 9 times, last: )

    Kann es sein, dass der `bankStart`-Code falsch ist? Die Banken sind „falsch“ herum nummeriert, also wenn die untersten drei Bits von `CIA2.pra` 3 (dez) ergeben, dann ist die Bank von $0000-$3fff aktiv.

    Dicken Dank für den Tipp! Hab da eben mal nach gesucht aber zumindest in der Programmers Reference nix zu gefunden. Also ist die Bank praktisch 3 - (CIA2.pra & 3) , wenn ich das recht verstehe?


    Hab den Code jetzt mal auf


    Code
    1. bankStart = (unsigned char *)(((unsigned int)~(CIA2.pra & 3)) << 14);


    geändert. Dieses Not müsste ja die Funktion von 3 - ... erfüllen, aber ein Stück schneller sein. Die Bits darüber kippen zwar auch, da ich aber ja um 14 nach links schiebe, sollten die ja eh verloren gehen.


    Danke nochmal für den Tipp,
    Andreas

    Hallo!


    Das Tool läuft schonmal unter Gentoo. Prima! Allerdings erzeugt es ein PRG Format mit Adresse drin, was mir eigentlich nicht so gut gefällt. Vielleicht nehm ich die Adresse mit dem Hex-Editor raus.


    Das mit dem Einbinden der Sprite ins Binary gefällt mir ehrlich gesagt nicht ganz so gut. Meine Idee war eher, das Binary recht kompakt zu halten und dann für jeden Level einfach Sprites und Hintergrund aus Dateien nachzuladen. Das hätte u.a. den Vorteil, dass man sie recht einfach austauschen könnte und auch gleich den Speicherplatz einer ganzen Floppy nutzen könnte. Ich hab aber zugegebenermassen ein bischen die Vorstellung verloren, ob das mit der Geschwindigkeit erträglich wird. Im Hinterkopf hab ich noch, dass eine 1541 wirklich laaaahm war. Andererseits sind die Datenmengen ja überschaubar und vielleicht kann man den User bischen beschäftigen, während nachgeladen wird. Z.B. Intro/Anleitung o.ä. anzeigen. Muss ich mal ausprobieren. Evtl. ist das mit den Daten im Binary schon besser, oder man sollte alle Daten eines Levels in einer Datei zusammenführen. Wird man noch sehen...


    Ich häng mal den aktuellen Stand meiner paar Sprite-Routinen an. Hilft ja vielleicht jemand. Das Meiste hab ich als Define gemacht, weil ich keinen grossen Plan hab, wie gut der cc65 wohl optimiert. So sollte er zumindest die konstanten Ausdrücke, wie (1 << 2) direkt berechnen können und der Overhead der Funktionsaufrufe fällt auch weg. Unter C++ hätte man das wohl als Templates gemacht, aber das gibt es hier ja nicht. Und Speicherplatz ist im Moment ja noch kein Problem, also tausch ich mal Platz gegen Geschwindigkeit. Der Hack mit der Sprite-Nummer in dem Setzen der X und Y Koordinaten ist wirklich übel. War überrascht, dass es compiliert...


    Ein paar Sachen sollte man vielleicht noch rausnehmen und als separate Funktion realisieren. Z.B. das Berechnen der Bildschirmspeicher-Adresse. Das würde sich in dem Modul zum Laden eines Playgrounds ganz gut machen. Kann man später ggf. noch ändern.


    Auch der Tipp mit dem Setzen der Sprite-Register ist gut. Werd ich evtl. noch realisieren. Einiges wird sich halt erst zeigen, wenn die Routinen dann benutzt werden. Dann kann man solche Sachen ja aber noch ändern.


    Ciao,
    Andreas

    Files

    • sprites.zip

      (2.62 kB, downloaded 12 times, last: )

    Zu Deinem Quelltext noch mal: Deine Funktion vermischt zwei Sachen, die eigentlich auch getrennt nützlich wären — Laden von Spritedaten und das setzen der Register für ein Sprite.

    Ja, da hast Du wohl recht. Ist alles noch ein bischen unfertig. Hatte auch ein Define drin,um die X/Y-Position eines Sprites zu setzten, bis ich drauf kam, dass man das besser zunächst mal splittet, damit die Koordinaten bei Bedarf auch einzeln gesetzt werden können.


    Na ja, ich werd mal versuchen, ein Sprite anzuzeigen und mit dem Joystick zu bewegen. Klappt das, kann man das ja schrittweise weiter ausbauen. Ein scrollender Hintergrund wäre z.B. toll. Wobei ich da an vielen Stellen noch ziemlich im Dunkeln tappe. Z.B. das Aufrufen einer C-Routine per VBI, und so.


    Im Moment muss ich mal schauen, wie ich ein Sprite male und in eine Datei schreibe. Vielleicht bekomme ich dieses Tool ja unter Gentoo ans Laufen


    http://www.nightfallcrew.com/0…nuxwindows-by-fieserwolf/


    und dann sehen wir weiter.


    Danke nochmal für die Tipps,
    Andreas

    Hallo plus4fan!


    Dicken Dank für Deinen Beitrag! Leider versteh ich Deine Funktion gerade nicht so ganz, weil es wohl 20 Jahre her ist, das ich ins Handbuch geguckt hab, und ich gerade nur einen winzigen Bildschirm auf dem Docs lesen nicht gut geht.


    Brauchst Du wirklich diese Poke-Befehle? Es gibt doch zumindest in _vic2.h eine Struktur, um auf die VIC Register per Namen zugreifen zu können. Such mal bei Dir nach dem File. Vielleicht hilft es Dir ja.


    Gute Nacht!


    Andreas

    Guter Tipp! Das hab ich übersehen. Vielen Dank! Ändere ich gleich.


    Ich gehe ehrlich gesagt davon aus, dass der User an dieser Stelle mal kurz zum Ein/Aus-Schalter greift, wenn das Spiel steht, so dass ein verlorenes Filehandle nicht so gross stören würde. :)


    Um richtig defensiv zu programmieren, wäre ja vor allen Dingen noch ein Test nötig, ob
    - die Speicheradresse im aktuellen 16k Block des VIC liegt, und
    - ein Vielfaches von 64 ist.


    Andererseits grüble ich halt wegen der Performance. D.h. wenn ich 8 Sprites lade, würde ja jedesmal getestet werden, was halt Zeit kostet.


    Vielleicht kann man es so machen, dass man diese Tests in ein ifdef legt, so dass sie z.B. fürs Debuggen aktiviert werden können und bei einer Release entfernt werden. Muss ich mal grübeln....


    Meinst Du, dass Interesse an so einer kleinen Sprite-Lib besteht?


    Danke nochmal für den Tipp,
    Andreas

    Dicken Dank für den Tipp! Das war eines der Probleme. cc65 hat dann noch etwas über meine Integer-Rechnerei gemeckert, aber so compiliert der Code mal zumindest:


    Hallo!


    Bin C-technisch ein wenig eingerostet, und versuche gerade eine kleine Sprite-Lade-Routine mit dem cc65 zu schreiben und er bringt mich gerade etwas zur Verzweiflung. Es geht um folgende, kleine, Funktion:



    , und nun scheitert es schon in der Zeile:
    unsigned char *bankStart = ((unsigned char *)CIA2.pra & 3) << 14;


    , wobei der Compiler meint:
    ====
    localhost shooter # make
    cl65 -t c64 shooter.c sprite.c -o shooter
    sprite.c(67): Error: Expression expected
    sprite.c(67): Warning: Statement has no effect
    sprite.c(67): Error: `;' expected
    sprite.c(67): Error: Expression expected
    sprite.c(67): Error: Undefined symbol: `bankStart'
    sprite.c(67): Error: Invalid lvalue in assignment
    sprite.c(67): Error: Integer expression expected
    sprite.c(70): Error: Expression expected
    sprite.c(70): Warning: Statement has no effect
    sprite.c(70): Error: `;' expected
    sprite.c(70): Error: Expression expected
    sprite.c(70): Error: Undefined symbol: `screenOffset'
    sprite.c(70): Error: Invalid lvalue in assignment
    sprite.c(70): Fatal: Too many errors
    make: *** [all] Fehler 1
    ====


    Sieht jemand auf die Schnelle, warum das kein Ausdruck sein soll? Irgendwie bin ich wohl gerade etwas blind...


    Vielen Dank im Voraus,
    Andreas

    Also der SHA256 ist knapp über 1000 Zeilen. Problem dürfte sein, wieviel Code für die Long-Ops gebraucht wird. Bei der 6510 CPU haben sie ja irgendwie die Grundrechenarten für solche Datentypen vergessen :) , so dass man das wohl alles 8-Bit-weise zusammenrechnen muss. Ich denke mal, dass muss auch in den Compiler, wenn man das halbwegs schnell hinbekommen will. Da mit externen Libs o.ä. zu rechen dürfte den armen Prozessor noch viel mehr ausbremsen, als es wohl eh schon der Fall sein wird.


    Natürlich wird da keine benutzbare Geschwindigkeit bei rauskommen. Aber dafür gibt es ja aktuelle Grafikkarten, die das können. Es geht ja nur um den Beweis, dass es möglich sein könnte (oder eben auch nicht).

    Es ist natürlich nach als Konkurrenz zu modernen Grafikkarten gemeint. Eher als Proof of concept, dass es halt auch mit einem Brotkistchen geht... :)


    Allein zu rechnen macht ja eh keinen Sinn mehr. Zur Not müsste man halt einen Pool starten, paar Leute finden, die dann so ca. 1 Mio mal Vice starten... :)


    Es hätte mich halt mal interessiert, wieviel Hashes pro ...ähhh... Minute?...Stunde?.... ein 6510 so hergibt.... :)

    Hallo!


    Hat schonmal jemand versucht einen Miner auf dem 64er zum Laufen zu bringen? Hab schon gegoogelt, aber nix gefunden. CC65 hat wohl keinen 64-Bit Long Typ, was die SHA-256 Implementierung ja nicht einfacher macht. Wer weiss also etwas in dieser Richtung?


    Vielen Dank im Voraus,
    Andreas