Hallo Besucher, der Thread wurde 16k mal aufgerufen und enthält 155 Antworten

letzter Beitrag von spider-j am

Project: Blasto

    Funzt wunderbar jetzt. Bitte noch dran denken die Spritebewegung beim finalen Programm in einen IRQ zu packen. Sonst gibt es inbesondere dann Probleme, wenn man "nach oben fährt" - weil man sich sozusagen entgegen dem Rasterstrahl bewegt. Ergebnis: Sprite ist manchmal nicht 100%ig sichtbar. Wenn man die Spritepositionen einmal pro Frame im Border updatet sollte sich das erledigt haben :)

    Grundsätzlich ja. Wichtig ist eben, dass Du für Grafikupdate Geschichten (eben Spritepositionen ändern, neu setzen, Charset Manipulationen, Hires/Multicolorbild anzeigen etc.pp) zusiehst einen Rasterzeilenbereich außerhalb des "sichtbaren" Bildschirms (bei ungeöffnetem Border idealerweise der Border) zu wählen. D.h. konkret, dass Dein IRQ z.B. getriggert wird, wenn $d012 den Wert #$f7 (bin mir nicht hundertpro sicher, musste nochmal nachgucken, ab welcher Rasterzeile der untere Border beginnt) erreicht. Dann wird Dein Code exakt zu der Zeit ausgeführt, in der sich der Rasterstrahl im unteren, bzw. wenn er ganz unten angekommen ist, dann auch wieder oberen Border befindet. Erreicht der Rasterstrahl dann oben die erste Zeile in der Chars, Grafik, Sprites dargestellt werden, so sind bereits alle "Änderungen" an den VIC-Adressen vorgenommen und alles auf dem Screen wird korrekt und flackerfrei dargestellt.

    Zitat von gh23

    Ich habe ein gutes Gefühl das, dass was wird!

    Na Hauptsache ich hab mir hier so langsam nen Platz in der Greetingsliste verdient ;)
    Wenn ich schon selber nix mehr fertig bekomme, weil ich bei mir hier ständig an tausend Baustellen gleichzeitig rumwurschtele*, dann will ich doch wenigstens anderen dabei behilflich sein, dass mal was fertig wird.


    *Pixel z.B. seit Tagen an meinem ersten Koalabildversuch herum und stelle mit Erschrecken fest, wieviel 160x200 Pixel sind, wenn man quasi jeden einzeln setzt und wie häßlich trotz all der Mühe das Ergebnis zu werden scheint :P


    EDIT: Nein gh23, Rasterkoordinaten sind nicht gleich Screenkoordinaten. Siehe hier: http://ebspso.dnsalias.org/c64…/C64/Vic/html/dsec34.html
    Also nicht zwischen #$33 und #$fa (sagen wir also ab #$fb)

    Hallo Leute! :winke:
    Bastle Grade dran, die Joystick - Routine in einen IRQ zu verfrachten *g*
    Und ich habe auch schon einen zweiten Joystick, damit ich Euch nicht länger mit dem Testen belasten muß!


    Der Stand der Dinge:
    Ich grüble immer noch über die Möglichkeit nach Screen's klein im Speicher unterzubringen ohne diese nachladen zu müssen wie bei Jumpman
    Habe bis jetzt noch nicht den richtigen Durchblick und bin noch am suchen nach Infos diesbezüglich! Denn das mit dem nachladen ist ja auch so ne Sache :whistling:
    Denn falls ich mit dem Code von der Länge her übertreiben sollte, wäre das vielleicht die einzige Möglichkeit.


    Wäre auch zu überlegen das Basic komplett auszuschalten um mehr Memory zu bekommen!
    Aber ich denke soweit bin ich noch nicht. Ich betrachte mich als fortgeschrittenen Anfänger im ASM Coden.
    Denn ich lernen durch Euch und durch Disasm und versuchen, immer wieder neues!


    Habe schon die Forumssuche ausproiert, aber das hat mir auch nicht wircklich weitergeholfen!
    Sag mal birngt das eigentlich etwas, wenn ich eine V2 Zeile durch den Basiccompiler laufen lasse und die dann Disassembliere, um festzustellen wie der einzelne Befehl z.B.: If funktioniert
    oder sollte ich das gleich wieder vergessen?

    Also prinzipiell spricht garnix dagegen, das KERNAL-Rom auszuschalten, solange du keine Basic-Ansprünge nutzt (was ich nicht glaube). Das einzige an was du dann denken musst, ist
    a) Die Interruptvektoren entsprechend zu wählen (FFFA-FFFF), und natürlich deine eigenen Interrupt-Handler zu schreiben. Das ganze sollte dir auch einen enormen Vorteil an Performance schaffen, wenn du CIA-Interrupts so machst, wie du das willst, oder gleich nur Raster-Ints nimmst. Darin kannst du dann alles unterbringen, Spritebewegung, Joystickabfrage (auch im Hauptprog machbar, da unkritisch).
    Und schlimm schwer ist das Abschalten auch nicht, mehr als ein lda#$35 sta $01 ist das ja nicht :) Gut Mut, viel Probieren hilft mir da auch. Wenn du mal ein Paar ruhige Minuten hast, führ dir mal übersichtsweise den Magic-Disk-IRQ-Kurs zu Gemüte, denke das begreifst du beim drüberlesen, bist ja nun schon sehr weit, Respekt!


    Viel Glück & gutes Gelingen


    EDIT: Klar, immer Probieren, niemals verkehrt. Wenn du so vorgehst, kannst du zuerst versuchen BASIC-Befehle mal zu verstehen, wie das alles gelöst ist, dir hinterher aber auch einfach Demos, Spiele etc disassemblieren und schaun, wie das da gemacht ist, das wird mit der Zeit zur zweiten Muttersprache glaub ich.

    @thasti: BASIC-ROM ist was anderes als das Kernal ROM. gh23 wollte ja erst einmal nur das BASIC ausblenden. Den "enormen Vorteil an Performance" sehe ich ehrlich gesagt auch nicht, denn so viel Zeit benötigt der Timerinterrupt nicht. Der Vorteil den auszuschalten, wenn man den Rasterinterrupt verwendet, ist eher, dass man sich bei der IRQ-Routine nicht mehr darum kümmern muss, wer die nun ausgelöst hat, sondern schon weiss, dass es der Raster-IRQ war.


    gh23: Ob das Ergebnis von BASIC-Compilern als Lerngrundlage taugt!? Ich bezweifle es ein bisschen. Was ist denn an einem IF so geheimnisvoll? Da wird irgendein Vergleich gemacht, und danach dann bedingt irgendwo hingesprungen. Das kannst Du doch schon in Assembler.

    gh23: Verstehe ich nicht, denn so ein IF wird in Assembler eigentlich nur mit einem Branch-Befehl umgesetzt. Die Auswertung der Bedingung würde ich davon getrennt betrachten, aber das ist in der Regel ja auch nur ein Vergleich. Alles was in der Bedingung darüber hinausgeht, wie zum Beispiel irgendwelche Berechnungen oder Funktionsaufrufe, sind unabhängig vom IF, d.h. die funktionieren ausserhalb des IFs genau so.

    gh23: Worauf bezieht sich denn jetzt das "deshalb"!? Ich glaube nicht, dass man von dem Ergebnis eines BASIC-Compilers viel über Assemblerprogrammierung lernen kann, vor allem nichts, was einem nicht auch ein gutes Assembler-Tutorial besser und direkter beibringen kann.


    Man muss ja auch immer bedenken, dass ein Compiler nicht unbedingt Code erzeugt, den man von Hand in Assembler so schreiben würde. Zum einen weil ein Compiler, gerade BASIC-Compiler auf dem C64, nicht besonders optimieren muss, also teilweise wahrscheinlich ziemlich umständlichen und "dummen" Code erzeugt. Auf der anderen Seite können gut optimierende Compiler Code erzeugen, der ziemlich verwirrend erscheint und für menschliche Programmierer schlecht und fehleranfällig zu warten ist. Das sind dann die Stellen, wo man als Mensch im Quelltext Kommentare zur Warnung anbringt, was man an den Stellen beachten muss. Etwas was in dem Kompilat was Du Dir im Monitor ansehen kannst, natürlich nicht mehr steht.

    Zitat von gh23

    Ich grüble immer noch über die Möglichkeit nach Screen's klein im Speicher unterzubringen ohne diese nachladen zu müssen

    Wenn Du keine Lust hast, Dir da selber irgendwas spezielles auszudenken kann es wirklich schlau sein, sich einfach mal ein bisschen mit dem Exomizer auseinanderzusetzen. Da ist sogar schön dokumentierter Sourcecode vorhanden, wie man mitten innerhalb eines Programms entpacken kann. Sprich, Du kannst alle Screens gepackt im Speicher lassen und dann bei Bedarf entpacken.


    Auch wenn das Teil anfangs etwas verwirrend ist, weil es eben so mannigfache Funktionen hat. Wenn man sich wirklich mal die Docs durchliest und ein bisschen rumprobiert kommt man schnell auf den Trichter, dass das Ding echt geil ist und dass man ohne Nachladen extrem weit kommt. :)