Beiträge von Mnemonic

    lubber & sauhund:

    Für die Lesbarkeit braucht man ja nur den "Spread" für jede Zeile und den Versatz zur folgenden Zeile etwas zu verändern.

    Die Tabelle dafür steht ab $0dc0 (Versatz zur nächsten Zeile) bzw. $0dd0 ("Spread" der Punkte auf der Zeile). Sind jeweils 16 Werte.

    Probiert's z.B. mal mit $00,$02,$04,$08, ... $1e ab $0dc0 und 16 mal $03 ab $0dd0 aus! :winke:

    Ist halt 'ne Preview, an den Proportionen für den Scroller muss ich noch bissel basteln.

    Roland: Ja, da haste recht, ist etwas sinnfrei mit dem Interrupt... ich wollte das für mich halt einfach ein bisschen trennen mit den einzelnen Routinen. Hab' ich ja auch mehr so als Muster gemacht.

    Hihi, das hab' ich jetzt davon, dass ich immer mit dem gleichen Gerüst inkl. stabilem Raster loslege, wenn ich mal was code... :whistling:

    Nee, das optimiere ich mir dann schon noch etwas. :winke:

    Nebenbei, Dein Beispiel für die Adressberechnung im Charset fand' ich genial!

    Grüßle,

    der Mnemonic

    Hallo zusammen,

    ich wollte Euch alle mal an meinem neuesten Erfolgserlebnis teilhaben lassen... mein erster Borderscroller! :winke:

    War für mich als Neuling viel Arbeit, aber jetzt läuft's!

    Sind auch zwei Ideen aus dem Forum drin verbaut, danke :dafuer: an Roland und Hoogo!

    Viel Spaß beim ausprobieren (des wahrscheinlich wieder einmal überkommentierten) Source!

    Gruß und einen guten Start in die Woche,

    der Mnemonic

    Hallo miteinander,

    ich bin grade am tüfteln, wie ich (taktmäßig) am schnellsten die Startadresse für die acht Bytes eines Chars innerhalb des Charsets berechnen kann.

    So weit bin ich schon mal, läuft auch absolut zuverlässig. Im Akku steht der Char aus z.B. einem Scrolltext, dann mache ich folgendes...

    X- und Y-Register nehme ich zum Zwischenspeichern her, als Ergebnis habe ich dann das LowByte der Startadresse für die 8 Bytes des Chars in $f7, das HighByte in $f8.

    So weit, so gut, aber geht das in "Echtzeit" auch schneller als die obigen 48 Takte? Wie berechnet Ihr denn das?

    Grüßle,

    der Mnemonic

    Hi Jasmin,

    das mit dem CarryBit ist doch kein Problem. Schieb das erste Byte des Chars, der in den Sprite soll, irgendwo in 'ne temporäre Adresse, mach mit CLC sicherheitshalber das Carry leer und mach dann ein ROL auf die temporäre Adresse. Dann hast Du erstmal Bit 7 von Charbyte im Carry-Register.

    Wenn Du jetzt direkt danach ein ROL auf der ersten Adresse in den Spritedaten machst, wo der Char hinsoll, schiebst Du damit das Carry in Bit 0 dieser Adresse und Bit 7 ins Carry. Dann machst Du genau das gleiche mit der zweiten Adresse im Sprite, dann in der dritten, usw., bis Du alle durch hast.

    Das ganze dann halt acht mal für jeweils acht Bytes des Char.

    Die acht Bytes kannst Du z.B. so bekommen wie im Anhang... sorry, net groß kommentiert, halt mal so runtergetippt.

    Gruß,

    der Mnemonic

    So, hab' mal was mit diesen Timingsachen gebastelt... und ich hab's immerhin an der (für mich) kritischen Stelle runtergebracht auf einen Jitter von max. 2 Cycles. :D

    Ich hab' halt mal meine Boing-boing-Sprites genommen und 'nen FLD-Effekt dazugebastelt. Die obere schwarze Linie konnt ich ja durch 'nen DoppelIRQ nach dem FLD-Teil stabil bekommen, nur die untere schwarze Linie war halt Chaos...

    Die Zeile direkt über IRQ anspringen war net drin, da war ich dann schon zu weit auf der Zeile, um die Farben noch sauber zu setzen, zumal die Sprites im blauen Bereich auch noch bis zu 2 Cyclen Jitter erzeugen. :cursing:

    Ich bin dann halt auf die Zeile davor gesprungen, auf der auch die letzte Spritezeile liegt, habe drauf geachtet, dass die immer in der gleichen Reihenfolge da landen und dann halt versucht, dass mit dem Timing per Tabelle, den Infos von Roland und dem Codeschnipsel von sauhund hinzukriegen.

    Unter zwei Cycles hab ich's jetzt net gebracht, dafür sind wohl die Spritebewegungen im blauen Bereich zu unregelmäßig.

    Mal schauen, vielleicht mach' ich da mal 'nen kleinen Noter drauß mit so ASCII-Grafik im blauen Bereich.

    Start ist wieder mit SYS 2051, und an $09e6 mal aus dem LDX #$09 ein z.B. LDX #$04 machen, dann ist der Jitter auf der unteren schwarzen Zeile sichtbar.

    Gruß,

    der Mnemonic

    So, hab's jetzt halt unter den Border gefummelt, da sieht man's net mehr. :rotwerd:

    Ich weiss auch net, seit ich mir den stabilen IRQ draufgeschafft habe, nervt's mich halt total, wenn sich was net stabilisieren lässt. Naja, dann soll's halt zappeln, muss ich mit leben. :whistling:

    Gruß,

    der Mnemonic

    Ja, der Artikel von Pasi Ojala ist mir dazu eben auch eingefallen...

    Zumal ja die Sprites, die da meine Grafik kreuzen, auch nicht zwingend in der richtigen Reihenfolge kommen.

    Mal sind z.B. Sprite Bitte melde dich an, um diesen Link zu sehen. und Bitte melde dich an, um diesen Link zu sehen. darüber, dann wieder #0 und Bitte melde dich an, um diesen Link zu sehen., des gibt echt nur Chaos, glaub ich. :buhu

    Naja, vielleicht bekomme ich's ja doch hin, das ganze springt ja auch "nur" um maximal 10 Cycles, das bekomme ich vielleicht im 38 Spalten-Modus beim scrollen grade so unter den Sideborder bzw. in die vertikale Austastlücke.

    Gruß,

    der Mnemonic

    Hallo zusammen,

    ich bin grade mal wieder an einen Punkt gekommen, an dem ich mir die Zähne ausbeisse... :aerger:

    Wie bekommt man denn einen Bereich auf dem Screen, über den unregelmäßig ein paar Sprites fliegen, so stabil, dass man da noch zu einen fixen Punkt z.B. die Scrollregister in $d016 setzen kann?

    Konkretes Problem ist, ich habe meine 8 Sprites, die in einem Sinus über den ganzen Bildschirm rauschen, und ich will in der unteren Hälfte halt noch 3 Bereiche mit unterschiedlichen Geschwindigkeiten scrollen (halt so Charset als Pseudohintergrund), und die stoßen grafikmäßig halt auch direkt aneinander, also nix mit Luft dazwischen für irgendwelches geflatter.

    Geht das überhaupt? Wie löst Ihr denn so etwas? In dem Bereich, den die Sprites kreuzen, kann ich ja auch net mit 'nen Doppel-IRQ stabilisieren, da haut's mir ja jedesmal mein Timing wieder kaputt.

    Irgendwie muss dass doch zu machen sein, oder nicht?

    Ich hab' ja jetzt auch schon in mehreren Demos gesehen, dass da sogar Sprites kreuz und quer über irgendwelche Rasterbars schwirren und da trotzdem nix flattert...

    Etwas verzweifelte Grüße,

    der Mnemonic

    @kHaos-Prinz

    Nein, da ist kein Multiplexing im Spiel, das sind exakt 8 Sprites.

    Hm, also Schematisch ist das so... die Rotation der Sprites (also diese schöne Kreisbewegung der Sprites gegen den Uhrzeigersinn) sind eine Sinustabelle auf der X-Achse und eine Cosinustabelle auf der Y-Achse.

    Die jeweils niedrigsten Werte dieser Tabellen sind die äußerste linke (X-Achse) bzw. äußerste obere Position (Y-Achse), an der ein Sprite grade noch vollständig sichtbar ist.

    Die Maximalwerte liegen dann in beiden Tabellen um den gleichen Wert auseinander, dadurch wird der Kreis schön rund.

    Das rumdotzen ist dann eher simpel. Für die Bewegung auf der X-Achse habe ich eine weitere Sinustabelle, die ich als Offset nutze, d.h. je Frame den Wert aus der Tabelle für die Rotation (s.o.), dann den Wert aus der Offsettabelle drauf, ab ins Positionsregister des Sprites, und schon bewegt sich der ganze Kreis von links nach rechts und zurück.

    Ähnlich läuft das für hoch und runter, allerdings ist das hier so eine Cosinuswelle, die unten "gekappt" ist. Auch hier gilt dann wieder Y-Position aus der o.g. Tabelle, Offset drauf, und schon hüpft's hoch und runter.

    Das "eindellen" des Kreises ist auch nicht sooo kompliziert gewesen, ich habe einfach die maximale Position links, rechts und unten gesucht, an der die Sprites immer noch komplett sichtbar sind. Wenn dann die X- und Y-Position des Sprites berechnet ist prüfe ich einfach, ob die irgendwo außerhalb dieser Maximalwerte liegt (also links, rechts oder unten schon ein bisschen unter dem Border) und falls ja, setze ich dann einfach den Maximalwert als X- oder Y-Position.

    Die Offsettabelle sind dabei bewusst so gemacht, dass der Kreis IMMER etwas in den Border rausgeschoben wird, dann greift diese Routine und "hält" die jeweiligen Sprites an dieser Grenze.

    Schau Dir am besten in einem Monitor mal die Tabellen ab $1200 (Offsettabelle X-Achse) und ab $1300 (Offsettabelle Y-Achse) an, oder setz die mal einfach mit einem festen Wert, dann wird das etwas deutlicher.

    Die Tabellen für die Kreisbewegung der Sprites liegen ab $1000 bzw. $1100, da kannst Du ja auch mal drin was ändern.

    Puh, hoffentlich war's jetzt auch noch einigermaßen nachvollziehbar... :winke:

    Gruß,

    der Mnemonic