Sprites laden in 'C' (cc65)

Es gibt 10 Antworten in diesem Thema, welches 3.916 mal aufgerufen wurde. Der letzte Beitrag (25. Juli 2011 um 12:51) ist von Vernunftmensch.

  • Hallo zusammen!

    Ich habe da mal eine Frage bezüglich des Ladens von Sprites. Ich habe mit einem Sprite-Editor ein paar ganz einfache Sprites erstellt und diese auf Diskette abgespeichert. Nun würde ich diese Sprites gerne mittels C Code (cc65) einladen. Hierfür habe ich mir überlegt, einen Array zu definieren:

    char MySprite[64]; /* 64 bytes of sprite data*/

    Womit ich z.B. 64 Bytes meines Sprites abgelegt bekomme. Die Array Elemente werden auch mit den entsprechenden Werten gefüllt, allerdings sieht das Ergebnis nicht nach dem aus, was ich erwartet habe. Daher hier nun meine Frage an ein appr "alte Hasen": was muß ich beachten, wenn ich von Diskette einen Multicolor Sprite einlesen will. Gibt es evtl. eine bessere Lösung (z.B. die Sprite Daten direkt an die enstprechende Speicheradresse laden oder so), als den von mir angeführten Array?

    Anbei die von mir erstellte 'C' Variante des alleseits bekannten "Baloon Demos" aus dem C64 BASIC Handbuch. Dieses Gerüst dient mir z.Zt. als "Versuchsplattform". Solange ich den Array im Quelltext selber vorbelege, sieht der Sprite auch okay aus. Anders verhält es sich, wenn ich den Array fülle indem ich, wie oben erwähnt, die Spritedaten (Erstellt mit einem Spriteeditor) von Diskette laden will.


    --- Quelltext sprite.c ---

    Bitte melde dich an, um diesen Link zu sehen. "toolfuncs.h"

    int main(void)
    {
    char *pcAddr;

    // define pointer to VIC video memory (53248)
    char *pcVidMem = 0xd000;
    int n,x;

    int q[63] = { 0,127,0,1,255,192,3,255,224,3,231,224,
    7,217,240,7,223,240,7,217,240,3,231,224,
    3,255,224,3,255,224,2,255,160,1,127,64,
    1,62,64,0,156,128,0,156,128,0,73,0,0,73,0,
    0,62,0,0,62,0,0,62,0,0,28,0 };

    clrscr();
    gotoxy(10,10);
    cprintf("Hit 'q' to quit!");

    // REGISTER No. DESCRIPTION
    // =====================================
    // 0-15 SPRITE POSITIONING
    // 16 EXTRA MOVEMENT
    // 21 ENABLE (ON/OFF)
    // 23 EXPAND (VERTICAL)
    // 27 PRIORITIES
    // 28 MULTI-COLOR SELECT
    // 29 EXPAND (HORIZONTAL)
    // 37-38 MULTI-COLORS
    // 39-46 COLOR

    // Before you see and use your sprites, you must first activate them.
    // You do this by using the SPRITE ENABLE register, register number 21.
    // As mentioned above, line 11 in the balloon program turns on sprite 2.
    // This is done by placing the value 4 in the register. This is 2 to the
    // power of the sprite number 2, i.e. the sprite you are initializing.
    // For example, to turn on sprites 2 and 3 add 8 and 4 (23 + 22).
    // The instruction would then be: POKE V + 21,12

    // Activate sprite 2 (POKE 53248+21,4)
    *(pcVidMem+0x15) = 4;
    //poke(0xd015, 0x04);

    // The sprite pointer indicates where you have stored your sprite in memory.
    // The sprite pointers are stored in 8 bytes from location 2040 to 2047 inclusive.
    // The normal location of the pointer for sprite 0 (the first sprite) is 2040;
    // the location for the pointer for sprite 1 is 2041; and so on with location 2047
    // used as the location of the pointer for sprite 7.
    // Each sprite pointer can contain a value between 0 and 255. This number, multiplied by 64,
    // corresponds to the start address of your sprite data.
    // Since each sprite uses 64 bytes, the sprite pointer can contain a block number anywhere
    // within the first 16K block of memory accessible by the VIC II chip, i.e. 256 * 64.
    // It is also possible to use other 16K blocks.
    // Further details can be found in the COMMODORE 64 Programmer's Reference Guide.

    // 0x7FA = 2042 --> sprite pointer no. 2
    // Use sprite pointer no. 2
    pcAddr = 0x7FA;

    // Choose one of 255 data blocks for storing 64 bytes
    // of dprite data. In this example, we use block 13.
    //poke(0x7fa, 0x0d);
    *(pcAddr) = 13;


    // The address for sprite data is determined as follows:
    // 13 (block no.) * 64 (size of sprite data in bytes) = 832 (0x340) = address of sprite data!
    // Here, we store sprite data to the corresponding memory block.
    pcAddr = 0x340;
    for (n=0; n < 63; n++)
    {
    //poke(pcAddr, q[n]);
    *(pcAddr) = q[n];
    pcAddr++;
    }

    do
    {
    for (x=0; x < 200; x++)
    {
    // set x and y postiotions of sprite 2 (POKE 53252,x and POKE 53253,y)
    //poke(0xd004, x);
    //poke(0xd005, x);
    *(pcVidMem+0x4) = x;
    *(pcVidMem+0x5) = x;
    }
    } while (cgetc() != 'q');

    // deactivate sprite 2
    *(pcVidMem+0x15) = 0;

    return 0;
    }

  • definier das array mal als "unsigned char" und nicht als int :)

  • Äh, sorry - da habe ich leider einen älteren Stand meiner Sourcen geposted ... :rolleyes:

    Den Array habe ich bereits nach unsigned char geändert. Damit habe ich dann auch endlich ein byte pro Element reserviert - ja, ich kann auch (mit etwas Phantasie) die ungefähre Form dessen erkennen, was ich eigentlich als Sprite auf dem Bildschirm zaubern will, aber das wirkt alles "ineinander verschoben". So, als ob die einzelnen (in BASIC wären es die entsprechenden DATA Zeilen) Werte nicht in der richtigen Reihenfolge ausgelesen werden. Gibt es da eine Regel, wie diese 64 byte gefüllt werden müssen? Oder hat mein Sprite Editor evtl. die einzelnen Werte in einer anderen Reihenfolge abgespeichert?!

    Oh mann, vor 15 Jahren hätte wenigstens noch ein bischen was zum Thema gewußt - aber heute?! Fast alles weg ... ?(

  • hört sich so an als würde der editor ein file mit ladeadresse in den ersten beiden bytes abspeichern.... schmeiss mal die ersten beiden bytes weg beim einladen bzw beim umkopieren in den sprite-buffer. wenns das nicht war ists vielleicht genau andersrum und der editor speichert ohne ladeadresse aber die funktion die du zum laden benutzt erwartet ein file mit ladeadresse...

  • Das könnte evtl. der Schlüssel zum Erfolg sein, denn im Hexeditor werden mir in dem File 66 bytes angezeigt. Könnte also wirklich daran liegen. Das muß ich heute Abend erstmal ausprobieren. Die Laderoutine öffnet via cbm_open das Spritefile, mittels cbm_read lese ich dann "in einem Rutsch" 64 bytes aus dem File. Dem cbm_read selber übergebe ich den Sprite Array, den ich zuvor erwähnt hatte. Wie gesagt, ich checke das mal gegen.

    Dann noch eine Frage: Multicolor Sprites belegen letztlich doch auch 64 bytes im Speicher, oder? Allerdings wird die "horizontale" Anzahl an Pixeln halbiert, um in den frei gewordenen 12 bytes die Farbinformation der nun 12x21 statt 24x21 umfassenden Spritematrix zu speichern, richtig?

  • Zitat


    Das könnte evtl. der Schlüssel zum Erfolg sein, denn im Hexeditor werden mir in dem File 66 bytes angezeigt. Könnte also wirklich daran liegen. Das muß ich heute Abend erstmal ausprobieren. Die Laderoutine öffnet via cbm_open das Spritefile, mittels cbm_read lese ich dann "in einem Rutsch" 64 bytes aus dem File. Dem cbm_read selber übergebe ich den Sprite Array, den ich zuvor erwähnt hatte. Wie gesagt, ich checke das mal gegen.

    jau, hört sich so an als wärs das....überspringe die ersten beiden bytes und es sollte klappen :)

    Zitat


    Dann noch eine Frage: Multicolor Sprites belegen letztlich doch auch 64 bytes im Speicher, oder? Allerdings wird die "horizontale" Anzahl an Pixeln halbiert, um in den frei gewordenen 12 bytes die Farbinformation der nun 12x21 statt 24x21 umfassenden Spritematrix zu speichern, richtig?

    jein. im multicolor mode belegt jeder pixel 2 aufeinander folgende bits, sprich 4 pixel pro byte.

  • @Sauhund:
    Was meinst du, wie gut kann man tricksen um 8-Farbige Sprites zu schrauben?
    Also für jedes Sprite alle Hardwaresprites stapeln und natürlich noch schaffen für jedes Objekt alle 8 Sprites zu modifizieren.

    EDIT: Lass dich heute Abend mal sehen im Bunker!

    Blog: Bitte melde dich an, um diesen Link zu sehen. - The Seventies Board: Bitte melde dich an, um diesen Link zu sehen. Bitte melde dich an, um diesen Link zu sehen.

    Ein Terminal und ein Z80 :D

    Einmal editiert, zuletzt von BastetFurry (9. August 2005 um 18:32)

  • Zitat


    Was meinst du, wie gut kann man tricksen um 8-Farbige Sprites zu schrauben?
    Also für jedes Sprite alle Hardwaresprites stapeln und natürlich noch schaffen für jedes Objekt alle 8 Sprites zu modifizieren.

    prinzipiell kein thema...nur kannst du nebeneinander ja nie mehr als die 8 sprites darstellen, ist also nicht wirklich brauchbar für ein spiel oder so

  • Für ein Spiel wäre das eh' zuviel, da reichen eigentlich auch 2 Sprites übereinander (und das wird ja durchaus auch getan). Das maximale was ich mal gebastelt hatte waren 4 Sprites übereinander, das ergibt bereits 7 Farben bei (fast) Hiresauflösung. War hübsch bunt. :smile:

  • @sauhund:

    Perfekt! Hat geklappt, die ersten beiden Bytes der Spritedatei waren tatsächlich die Adresse. Nun funzt es gabz hervorragend ... *freu* - danke für den Tip!

    Mal sehen, ob ich so nicht ein lecker kleines Game hingezaubert bekomme ... *programmier* *bastel* :wink:

    Einmal editiert, zuletzt von lodger (12. August 2005 um 13:30)

  • Aktuell möchte ich alle acht Sprites normal nutzen. (c64)

    Mir fehlen
    SPRITE2_PTR, SPRITE3_DATA, SPRITE4_...

    Wie schaltet man bei cc65 alle Spritesdefinitionen ein?

    Code
    #define SPRITE2_PTR 0x07FA
    #define SPRITE3_PTR 0x07FB
    #define SPRITE4_PTR 0x07FC
    #define SPRITE5_PTR 0x07FD
    #define SPRITE6_PTR 0x07FE
    #define SPRITE7_PTR 0x07FF

    Nach Code drüber fehlt nur noch SPRITE2_DATA usw. .
    Oder ist dafür kein Speicherplatz reserviert, also nur für die ersten beiden Sprites?