Hello, Guest the thread was viewed13k times and contains 272 replies

last post from Nobato at the

Mega Karate - Wer macht mit ?

    Ich hab mal ein Problem mit den Sprites.

    Ich möchte die Spriteblöcke (16x21 Pixel in 16 Farben) umschalten um eine Animation zu realisieren.

    Ich setze den Pointer auf Block 0 und erhalte das erste Bild. Wenn ich den Pointer jetzt auf 1 setze,

    habe ich Teile vom ersten und vom 2. Bild. erst wenn ich den Pointer auf 3 setze, also 2

    Blöcke auslasse erhalte ich erst das 2. Bild. Obwohl die Daten 168 Bytes für das 1. Bild und direkt dahinter

    die nächsten 168 Bytes für das 2. Bild im Speicher liegen.

    Muss ich an VIC Konfig noch etwas ändern ?

    Quote from Ticker
    Quote from Endurion
    Quote from Drachen

    Wielviel Hindergründe soll denn das Spiel enthalten ?

    Yes

    Die Hauptstädte der Welt fände ich gut. Und natürlich im Kakteenhain.:thumbsup:

    Daran habe ich auch schon gedacht, aber welchen Platz soll ich da nehmen damit man es gleich erkennt.

    Berlin ist leicht, da kann man den Bundestag nehmen, Das Branderburger Tor wurde auch schon gewünscht.

    Aber ich werde mir das was einfallen lassen.

    Und die Hauptstadt von Kakteen-Land muss ich noch finden. Bin aber ihr auf der Spur.

    Nur mal so ein paar Gedanken dazu. Muss gleich vorwegschicken, dass ich mich mit BASIC Null auskenne, da ich immer alles direkt in Assembler mit den Chips direkt bespreche.


    Kann es sein, dass BASIC gar keine Fullcolor-Sprites unterstützt? Dann musstest Du wahrscheinlich per POKE dem VIC direkt sagen, dass das Sprite Fullcolor ist? Ich gehe mal stark davon aus, dass BASIC das ja nicht mitbekommt und weiterhin davon ausgeht, dass nur ein Bit pro Pixel an Farbddaten im RAM stehen. Durch die Änderung werden aber nun immer vier Bits pro Farbe benutzt - das Sprite wird also viermal größer im RAM. Daher musst Du wohl jetzt auch immer die Pointer entsprechend anders setzen.

    Quote from kibo

    Kann es sein, dass BASIC gar keine Fullcolor-Sprites unterstützt? Dann musstest Du wahrscheinlich per POKE dem VIC direkt sagen, dass das Sprite Fullcolor ist? Ich gehe mal stark davon aus, dass BASIC das ja nicht mitbekommt und weiterhin davon ausgeht, dass nur ein Bit pro Pixel an Farbddaten im RAM stehen. Durch die Änderung werden aber nun immer vier Bits pro Farbe benutzt - das Sprite wird also viermal größer im RAM. Daher musst Du wohl jetzt auch immer die Pointer entsprechend anders setzen.

    Die Sprites sind auf Fullcolor gesetzt.Ich dachte der VIC passt sich dem intern an.

    Dann habe ich doch nichts falsch gemacht.

    Quote from MC64

    Obwohl die Daten 168 Bytes für das 1. Bild und direkt dahinter

    die nächsten 168 Bytes für das 2. Bild im Speicher liegen.

    Du hast es zwar eh schon selbst beantwortet. Aber ja, bei Fullcolor 16x21 Sprites brauchen wir jeweils 3 x 64-Byte-Slots, daher muss der Pointer jeweils um 3 erhöht werden. Die jeweils letzten 24 Bytes (192-168) bleiben dann halt unbenutzt ...

    Quote from TOS22

    Du hast es zwar eh schon selbst beantwortet. Aber ja, bei Fullcolor 16x21 Sprites brauchen wir jeweils 3 x 64-Byte-Slots, daher muss der Pointer jeweils um 3 erhöht werden. Die jeweils letzten 24 Bytes (192-168) bleiben dann halt unbenutzt ...

    Ich hatte hier mit mehreren Problemen zu kämpfen. Erst mal war mir nicht klar, das der VIC das nicht anpasst, was die Spritepointer angeht.:rolleyes:

    Das nächste war das meine Spritedatei fehlerhaft ohne Ende ist.8| Ich habe versucht mit C64 Studio die Sprites zu konvertieren, das geht

    aber voll in die Hose. Unterm Strich kam vom ersten Spriteblock abgesehen, nur Grafikmüll dabei raus.:S


    Mein Werdegang der letzten Stunden: :D -> 8| -> :huh: -> ?( -> :S -> ;( -> :platsch: -> :honk: -> :gahh: ->:cry:

    Aber jetzt gehts wieder. :winke:

    Ich hatte gedacht das das Problem schon lange behoben worden ist, da ich ja auch damit Ärger hatte.

    Und Endurion hat das seiner seits auch gleich korrigiert als ich das gemeldet habe. Dies bezog sich sich zwar nur auf das S-Basic von Snoopy,

    dürfte aber nichts daran änderen, oder täusche ich mich da. :gruebel

    Nur mal ganz grob. Ich werde Später Bilder machen.

    Ich habe aus einer Datei die Sprites importiert. Das funktioniert auch hervorragend. Wenn ich

    aber die als Binärdatei exportiere. Dann sind die Sprites verschoben. Sie sind in der horizontalen verschoben.

    Eventuell auch in der vertikalen, da bin ich aber noch nicht sicher.

    Ich habe Data Statements generiert. Mach ich das mit einem Spriteblock, stimmen die Daten.

    Bei 2 Spriteblöcken, stimmen die Daten dann nicht mehr überein.

    Daher kam bei mir die Frage mit den Pointern auf, da ich dachte das ich die ganze Zeit einen Fehler mache.

    So wie ich das bisher sehe, werden da zusätzliche Datas integriert, die da nichts verloren haben und alles

    durcheinander bringen. Bis auf den ersten Block.

    Was ich schon mal gemacht habe, als das bei mir mit Sprites war bei C64-Studio.

    Ich hab die Sprites mit S-Basic erstellt.

    Siehe Beispiel:


    So habe ich es dann mit allen meine Sprites gemacht.


    Mit C64 Studio die Sprites gezeichnet, dann die Sprites nach S-Basic konventieren lassen.

    Endurion war so freundlich mit der Bitte von mir das im C64 Studio mit einzubauen.

    Ist zwar etwas umständich, aber meine Sprites werde damit korrekt angezeigt.

    Falls es von Wichtigkeit ist, die Sprites werden für das S-Basic nach $8000 geladen.

    Und man hat unter S-Basic nur einen bestimme Anzahl für seine Sprites. Hängt mit dem Speicher zusammen. Aber drüber kann Snoopy mehr schreiben.

    Quote from Drachen

    Und man hat unter S-Basic nur einen bestimme Anzahl für seine Sprites. Hängt mit dem Speicher zusammen.

    Der MEGA65 bietet uns hier super Möglichkeiten; Wir sind zwar wie früher mit 8 gleichzeitig limitiert, aber wir haben ein extrem schnelles DMA (auch in BASIC) und wir haben viel Speicher im ATTIC RAM. Üblicherweise ändert man bei Spriteanimationen den Spritepointer. Ich möchte das aber jetzt bewusst etwas überstrapazieren: Wir könnten sogar die Spritepointer oder einzelne Spritepointer gleich lassen und dafür laufend Spritedaten vom ATTIC in den lower RAM schieben.


    In einer Sekunde kann BASIC65 mit EDMA über 3000 (!) Einzeltransfers von 168 Bytes Daten durchführen. Natürlich muss in einer Sekunde sonst auch noch viel gerechnet werden (Joystick input, Move Sprites, Töne spielen, KI, etc), aber mit 10% der verfügbaren Rechenleistung bekämen wir satte 30fps für 8 Sprites hin, ohne auch nur ein einziges Mal einen Pointer zu ändern. Das ist natürlich nur ein Rechenbeispiel, denn natürlich werden wir mit den Pointern arbeiten, aber ich wollte v.a. klarstellen, dass wir - was den Speicher anbelangt - mit großer Sicherheit an keine Grenze stoßen werden :)

    Quote from Drachen

    Falls es von Wichtigkeit ist, die Sprites werden für das S-Basic nach $8000 geladen.

    Das ist in dem Fall egal. Ich habe die Sprites in Bank 4 liegen.

    Es ist so, das die Datei falsch erstellt wird. Das erste Sprite ist immer korrekt.

    Das zweite dann nicht mehr, das habe ich von Hand korrigiert und das funktionierte dann auch.

    Quote from TOS22

    Ja, überhaupt kein Problem. Ganz im Gegenteil, je mehr unterschiedliche Bewegungen, umso interessanter das Spielerlebnis

    Deshalb hatte ich mich für die GBA Sprites entschieden. Da hat man die meisten Bewegungen.

    War es nun eigentlich möglich mit einem R3 Board Joysticks mit 2 Buttons anzusprechen ?

    Ich meine, das geht nur mit neuen R6 Board.