Hello, Guest the thread was viewed6.2k times and contains 94 replies

last post from Zirias/Excess at the

Map effizient auf Screen abbilden

    Quote from Zirias/Excess

    Wenn ich sowohl dem ZP-Pointer als auch meinem Instruction-Argument fürs LDA/STA ein Label verpasse, wieso ist es dann mehr oder weniger fehleranfällig?

    Wenn's jetzt nur um das Verändern von Operanden geht, finde ich selbstmodifizierenden Code sogar ab und zu lesbarer (mit entsprechenden Kommentaren) und wartbarer (da kein Heckmeck in der Zeropage nötig).


    Aber fehleranfällig ist's schon, wenigstens z.B. sofern RUN/STOP-RESTORE angeschaltet bleibt (z.B. bei Utilities sicherlich üblich) und z.B. der Code fest davon ausgeht, dass die Low-Bytes der Operaden beim Start immer #$00 sind. Da ist mein eigener Code auch häufiger eigentlich kaputt. :)


    Und es ist natürlich unschön, dass man den Code für ROM (auch ggf. in CRTs) nicht benutzen kann.

    Quote from 1570

    Aber fehleranfällig ist's schon, wenigstens z.B. sofern RUN/STOP-RESTORE angeschaltet bleibt (z.B. bei Utilities sicherlich üblich) und z.B. der Code fest davon ausgeht, dass die Low-Bytes der Operaden beim Start immer #$00 sind. Da ist mein eigener Code auch häufiger eigentlich kaputt. :)

    Also der NMI durch RESTORE bringt dir so ziemlich JEDES Programm zum Absturz (oder zumindest unerwünschtem Verhalten falls KERNAL noch eingeblendet ist) wenn du das nicht bedacht hast. Handlen, oder gleich ganz blocken falls du sonst keine NMIs brauchst :-D


    Quote from 1570

    Und es ist natürlich unschön, dass man den Code für ROM (auch ggf. in CRTs) nicht benutzen kann.

    Zumindest auf dem C64 spielt das heute(!) in der Praxis in aller Regel keine Rolle mehr :nixwiss: es sei denn vielleicht man bastelt an seinem eigenen KERNAL. Aber Software aus Cartridges wird fast immer sowieso erst mal ins RAM kopiert.


    Aber klar, das ist immer der Pferdefuß. Wenn's direkt aus ROM lauffähig sein muss dann braucht man die ZP-Pointer :-)

    Quote from Zirias/Excess

    edit: Nur immer NTSC bedenken, falls man das supporten will ... die 20% schnellere Framerate kann heftig in die Suppe spucken :-D

    edit2: NTSC war der Grund, warum ich von einer Map mit "Tile-Nummern" weggekommen bin und stattdessen die Map schon beim Level-Laden in Screencodes übersetze, was 4 mal so viel RAM braucht, aber nur so war das Zeichnen auf NTSC noch schnell genug. NTSC is a bitch :thumbsup:

    NTSC? Oh, da hatte ich gar nicht dran gedacht. Ich habe gerade mal im Vice nachgeschaut, wie mein Programm darunter läuft. Es ist ein wenig glitchier, aber noch im Rahmen. Puh. Ich habe zeitweise viele Rasterzeileneinsprungspunkte in meinem IRQ-Handler, der IRQ ist nicht stabil, und weder BASIC noch KERNAL sind ausgeschaltet.


    Acorn Coole Idee, danke. Aber was soll das "EOR #$DC" bewirken? Die low Bytes von Screen und Color sind bei mir ja eh immer gleich. Also habe ich es einfach weggelassen, und es funktioniert hervorragend.

    Quote from WebFritzi

    Acorn Coole Idee, danke. Aber was soll das "EOR #$DC" bewirken? Die low Bytes von Screen und Color sind bei mir ja eh immer gleich. Also habe ich es einfach weggelassen, und es funktioniert hervorragend.

    Klar stimmt da hatte ich das H-Byte im Sinn und nicht das L-Byte, mit EOR dürfte das so auch gar nicht laufen, sowas passiert, wenn man den Code nicht testet.

    Zu der Idee habe ich mal hier ein paar Testprogramme geschrieben: Zarch (Virus) auf dem C64 1:1 machbar?

    Wie ist das gemeint: "die Farbe im Zeichensatz ablegen"? Ich stelle mir das jetzt so vor, dass man z.B. eh nur 8 der 16 Farben verwendet und die 256 Zeichen in 8 Blöcke von 32 Zeichen anordnet. Dann muss man noch in einem Table festlegen, welche der acht Farben das sind und könnte dann sowas schreiben:

    Das ist zwar nicht schnell, spart aber 256 Bytes (wenn wie in meiner ursprünglichen Routine jedem Char eine Farbe zugeordnet ist) oder sogar noch mehr, wenn man eine oder mehrere Colormaps benutzt. Oder habe ich das jetzt falsch verstanden?

    Quote from WebFritzi

    Oder habe ich das jetzt falsch verstanden?

    Die Zeichen 0,16,32,48 usw. sind auf der Position für schwarz, 1,17,33 weiß, 2,18 rot usw. im Zeichensatz. Man legt die Zeichen einfach entsprechend ihrer Farbe für das Farbram im Zeichensatz ab. Dann kann man den selben Wert auch direkt ins Farbram schreiben.

    Code
    1. LDA MAP
    2. STA SCREEN
    3. STA COLOR

    Hmm, die Idee fand ich jetzt doch faszinierend genug und habe deshalb ein bisschen analysiert...


    Bei einem char kann ich die Farbe beliebig (>= 8 )wählen, weil nur eine MC-Farbe verwendet wird. Damit schaffe ich es, dass ich maximal 2 Zeichen mit der gleichen Farbe habe. Und DAS heißt, der Trick wäre sogar umsetzbar obwohl im gleichen Charset noch ein Font mit Text- und Grafikzeichen liegt :thumbup:


    Einsparpotential liegt in meinem Fall bei knapp 14000 Cycles, oder mindestens 220 Rasterlines (nur überschlagen). Da Die Spiellogik schon jetzt aus Performancegründen direkt auf den Screencodes arbeiten muss ist DAS natürlich ein kleiner Nachteil, wenn die dann ohne jede "logische" Anordnung liegen ....


    Ich denke ich werde trotzdem mal versuchen, das umzusetzen, denn mit etwas Glück ermöglicht es ein Feature, das bisher ebenfalls aus Perforemancegründen nicht machbar war: Schnelleres Scrolling im "sich umschauen"-Modus :thumbsup: Wäre echt cool, wenn das hinhaut.

    Hm, ich muss sagen, das rockt :thumbsup: (Screenshot auf NTSC)



    Natürlich ist JETZT erst mal die komplette Spiellogik kaputt weil die Screencodes komplett durcheinander sind, aber das lässt sich ja fixen. Extraschnelles Scrolling für "sich umschauen" -- scheint jetzt machbar :thumbup: wirklich sehr cooler Trick!

    Quote from Zirias/Excess
    Quote from oobdoo

    Was ist das?

    Naja, sowas wie eben !for oder .repeat.

    Unnötiger Scheiß. Das ist der Grund, warum viele gerade zu Anfang nichts mit Assembler-Beispielen anfangen können und wieder quiten. Das mag Quality of Life Improvement sein, aber Assembler ist das nicht...:angel

    Mit "Fakten" hat das trotzdem nichts zu tun, "Assembler" ist eben mehr als nur n "besserer Monitor". Klar kann man alles von Hand runterhacken, selbst im Monitor, oder meinetwegen sogar mit ner Opcode-Tabelle auf Papier. Auch nur halbwegs bei nem komplexeren Projekt den Überblick behalten ist so aber nicht drin.

    Nein. !For steht wahrscheinlich in keinem Assembler Buch, und schon gar nicht in einem Lern-Tutorial. Und kein Anfänger freut sich, wenn er neben der Assembler-Logik gleich noch weitere Prä-Compiler Logik verstehen muss, die dann auch noch "von Compiler zu Compiler" anders sein kann.


    Ich habe es oft genug erlebt, dass Anfänger zu Code-Beispielen dieser Art gelinkt werden, mit denen sie dann nichts anfangen können. Meine Aussage von oben stimmt genau. Das kriegt man vielleicht nicht mehr mit, wenn man nur noch unter Veteranen codet...:streichel:

    Quote from Endurion

    Musst du den KickAssembler lieben :)

    Ganz ehrlich, was DA alles an abgefahrenem Scripting-Krempel drinsteckt finde ich auch grenzwertig, das ist mehr n "Toolkit zur Berechnung von Demo-Tabellen" als n Assembler :emojiSmiley-23:


    Aber die Argumentation bleibt trotzdem unsinnig. Ein brauchbares "Assembler-Buch" erklärt selbstverständlich auch Makros und anderen Präprozessor-Kram inklusive wofür man das sinnvollerweise einsetzt. Natürlich am Beispiel von EINEM Assembler. Aber wenn man das Prinzip mal verstanden hat ist es wirklich keine Raketenwissenschaft, sich mal das Manual von nem anderen Assembler zu Gemüte zu führen ....

    Ich erinnere mich, dass ich das Anfangs schon unverständlich fand: Assembler hat keine Variablen, und dann gibt es "Assembler", und der hat dann doch wieder Variablen... Aber ich glaube nicht, dass das länger als 1 Woche ein Rätsel war.


    Aber für den absoluten Einstieg würde ich auch erstmal Monitor nennen.

    Btw: Was macht eigentlich Roland?