Sgdk - Sega Megadrive / Sprite

hello la compagnie

Je galère pas mal à trouver des infos, pour les sprites,

Dans l'exemple du Sonic dans sgdk , chaque ligne correspond  à une animation, j'ai trouvé des sprites
ou sur chaque ligne on peut avoir plusieurs animations et une taille différente du personnage.

J'arrive à bien afficher ce personnage mais il est entre  2 animations.

J'aimerais comprendre ou l'on defini cela ?

Et quels sont les parametres ici à la fin ? que veut il dire ? (j'ai pas trouvé dans la doc) : SPRITE sonic_sprite "sonic.png" 6 6 -1 5

Est cela ?
//sprite data
00064 u8 sprite_width;
00065 u8 sprite_height;
00066 u16 nbTiles;
00067 u16 *sprite_data;

Si oui que veut dire le -1.

Dans une grille l'ideal pour un personnage, est qu'il soit dans chaque carrée de 32x32 pixels ?

Merci à vous

En fait tout est expliqué dans le fichier rescomp.txt qui se trouve dans le répertoire bin de SGDK. Comme c'est rescomp qui gère les ressources j'ai splitté sa documentation. Certes ce n'est pas forcément évident de s'y retrouver :p

Voici ce qu'on peut y trouver sur la ressource de type SPRITE :

Code:

SPRITE
------
Take an image as input and transform it in SGDK SpriteDefinition structure.
SpriteDefinition is used to draw, animate and manage sprites, it internally contains severals TileSet, Palette and Animation structures.

Syntax:
SPRITE name img_file width heigth [compression [time [collision]]]

    name          name of the output SpriteDefinition structure
    img_file      path of the input image file (should be 8bpp .bmp or .png)
    width         width of a single sprite frame in tile (should be <= 20)
    heigth        heigth of a single sprite frame in tile (should be <= 20)
    compression   compression type (use unpackSprite(..) to unpack)
                   -1 = AUTO (use best compression scheme)
                    0 = NONE (no compression)
                    1 = APLIB (aplib library)
                    2 = LZKN (Konami LZW compression, disable for legal reason)
                    3 = RLE (4bits RLE compression)
                    4 = RLE MAP (tilemap adapted RLE)
    time          display frame time in 1/60 of second (time between each animation frame)
    collision     collision type: CIRCLE, BOX or NONE (BOX by default)

Some informations about how SpriteDefinition is generated from the input image:
- input image dimension is aligned on tile (multiple of 8).
- input image is a grid where each cell represents a single sprite frame and where a row define a complete sprite animation.
- cell size (frame size) = width * height (in tile)
- a frame can be composed of several internal VDP sprites (max = 20) if width or height are > 4.
- rescomp detect flipped frame to avoid redundant sprite tiles.
- rescomp detect empty frame at end of animation row to not store empty frame data.
- rescomp detect frame copy inside an animation to generate the according animation sequence.
- collision bounds are calculated by using 75% of the original sprite frame.
- In future rescomp could detect empty tiles in a frame to optimize the internal VDP sprite usage (and also improve the collision box).
That may be a nice future addition :)


Donc le paramètre à -1, c'est la compression

Hello stef ,

name    : sonic_sprite
img_file      : "sonic.png"
width         : 6  (c'est quoi ? comme unité ?)
height        : 6  (meme question ? comme unité ?) 
compresion : -1 (cela veut dire ne compresse pas ?)
time           : 5  (alors a quoi ca sert ? en sec ?)

Car j'ai mon sprite qui clignote entre le sprite 1 et le sprite 2 à coté.

Merci à toi

pckid a écrit:Hello stef ,

name    : sonic_sprite
img_file      : "sonic.png"
width         : 6  (c'est quoi ? comme unité ?)
height        : 6  (meme question ? comme unité ?) 
compresion : -1 (cela veut dire ne compresse pas ?)
time           : 5  (alors a quoi ca sert ? en sec ?)

Car j'ai mon sprite qui clignote entre le sprite 1 et le sprite 2 à coté.

Merci à toi

L'unité de taille c'est le tile, ça fonctionne ainsi sur megadrive (et bien d'autre machine), tout tes sprites sont composés de bloc de 8x8 pixels.
Donc si tu met width à 4 et height à 4, ça signifie que ton image est une grille de sprite de 32x32 pixels.
Pour le paramètre compression, -1 comme c'est indiqué dans le bloc que j'ai posté plus haut, signifie "AUTO", dans ce mode rescomp choisi la meilleur compression (pas forcément la plus rapide mais celle qui compresse le mieux).
Le paramètre "time" est la durée (en 1/60s) pour chaque étape d'animation.
En mettant 5, tu demandes à ce que l'animation passe à la frame suivante toute les 5/60s de seconde. Si tu gères l'animation manuellement, tu peux laisser ce paramètre à 0.

Perso, j'ai trouvé ça trop compliqué pour démarré, j'ai géré moi même l'animation. Mais c'est plus par fainéantise qu'autre chose :)

bfg a écrit:Perso, j'ai trouvé ça trop compliqué pour démarré, j'ai géré moi même l'animation. Mais c'est plus par fainéantise qu'autre chose :)

C'est vrai qu'il faut s'accrocher pour comprendre la philosophie, et c'est ultra bordé, stef a voulu faire de la direction assistée partout.

il faut quand même avoué qu'il a bossé comme un digue pour générer cela. bravo stef !

Mais à force ,et si on s'adapte aux contraintes on peut construire le moteur plus rapidement.
Il faut que je modifie ma grille car chez sprite ressource, ils se foute des grilles , ils mettent à coté comme cela.

un petit cadeau pour toi michel !

http://www.spriters-resource.com/arcade/superpang/sheet/60043/

http://www.spriters-resource.com/arcade/superpang/sheet/60047/

j'ai converti en 8 couleurs avec gimp ca marche sous Sgdk, je vais essayer en 16 couleurs car je ne connais pas les contraintes de la megadrive !


ps : michel tu aurais un petit bout de code pour voir comment tu gères à la mano l'affiche de ton sprite et son rafraichissement ? j' hallucine comment ton cerveau est rapide pour appréhender un sdk.

et une autre version
http://www.spriters-resource.com/arcade/pangbusterbrospompingworld/

Stef a écrit:
L'unité de taille c'est le tile, ça fonctionne ainsi sur megadrive (et bien d'autre machine), tout tes sprites sont composés de bloc de 8x8 pixels.
Donc si tu met width à 4 et height à 4, ça signifie que ton image est une grille de sprite de 32x32 pixels.
Pour le paramètre compression, -1 comme c'est indiqué dans le bloc que j'ai posté plus haut, signifie "AUTO", dans ce mode rescomp choisi la meilleur compression (pas forcément la plus rapide mais celle qui compresse le mieux).
Le paramètre "time" est la durée (en 1/60s) pour chaque étape d'animation.
En mettant 5, tu demandes à ce que l'animation passe à la frame suivante toute les 5/60s de seconde. Si tu gères l'animation manuellement, tu peux laisser ce paramètre à 0.

petite question : dans un fichier png, composer d'une grille de 32 px , ton Sdk
lit de gauche à droite ? puis descend à la ligne N°2 et relis de gauche à droite ?

Je suis entrain de faire Bouger Pc Genjin ici : http://www.spriters-resource.com/arcade/bonksadventurebckid/sheet/41645/

Mais il y a la marche et le saut sur la même ligne par exemple : Est ce que ce genre de fichier peut fonctionner avec ton mode ? SPR_setAnim ou  SPR_update ?

pckid a écrit:

bfg a écrit:Perso, j'ai trouvé ça trop compliqué pour démarré, j'ai géré moi même l'animation. Mais c'est plus par fainéantise qu'autre chose :)

C'est vrai qu'il faut s'accrocher pour comprendre la philosophie, et c'est ultra bordé, stef a voulu faire de la direction assistée partout.


ps : michel tu aurais un petit bout de code pour voir comment tu gères à la mano l'affiche de ton sprite et son rafraichissement ? j' hallucine comment ton cerveau est rapide pour appréhender un sdk.

C'est pas propre ce que j'ai fait, mais je te file ça rapido, le temps de nettoyer ce qui pourrait polluer autour du code.

pckid a écrit:
petite question : dans un fichier png, composer d'une grille de 32 px , ton Sdk
lit de gauche à droite ? puis descend à la ligne N°2 et relis de gauche à droite ?

Je suis entrain de faire Bouger Pc Genjin ici : http://www.spriters-resource.com/arcade/bonksadventurebckid/sheet/41645/

Mais il y a la marche et le saut sur la même ligne par exemple : Est ce que ce genre de fichier peut fonctionner avec ton mode ? SPR_setAnim ou  SPR_update ?

Oui ça lit de gauche à droite et de haut en bas.
En gros chaque colonne est une frame d'animation et chaque ligne une animation différente (marcher, courir...)
Mais après rien ne t'empêche de gérer tout ça toi même. Tu peux trouver toutes les méthodes su Sprite Engine dans l'unité sprite_eng.h

La méthode suivante :

Code:

void SPR_setAnimAndFrame(Sprite *sprite, s16 anim, s16 frame);

te permet de position l'animation courante (ligne) et la frame courante (colonne) de ton sprite.

Pas mal du tout, j'avais pas trouvé cette function mais je l'ai fait comme çà

SPR_setAnim(&sprites[nSpriteX], nSpriteY);

Et je bouge le nSpriteX et nSpriteY


Par contre dans ma boucle
je ne sais pas si je garde cela si c'est necessaire ?

// update sprites (only one to update here)
 SPR_update(sprites, 1);

Merci à toi
j'ai hate de m'attaquer à la map, (meme si tu la genere  pas je crois que Sgdk sait la lire ?)

Voilà comment j'ai fait salement l'animation.

Code:

struct genresSprites
{
    u16 *pal; //pointer to pal data
    u32 **sprites; //pointer to sprites data
    u16 count; //nb sprites
    u16 width; //width of each sprite in pixels (not tiles!)
    u16 height; //height of each sprite in pixels (not tiles!)
    u16 size; //since we use width/height in pixel, useful info on sprite size
    //TODO : size is not SGDK compliant, you need to use size>>8
    // will be fixed in coming release
};

extern struct genresSprites player_sprites;


SpriteDef sprites[MAXSPRITE];

        while(1)
        {
                /* GESTION DES MOUVEMENT DROITES */
 if (bright1==1)
 {
 sprites[0].posx+=2;
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,0,BASE_SPRITE_PATTERN+16+(cpt_anim<<4));

 }
 else    /* GESTION DES MOUVEMENT GAUCHE */
 if (bleft1==1)
 {
 sprites[0].posx-=2;
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,1,BASE_SPRITE_PATTERN+16+(cpt_anim<<4));
 }
 else
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,0,BASE_SPRITE_PATTERN);

 for (spr=0;spr<MAXSPRITE;spr++) VDP_setSpriteP(spr, &sprites[spr]);

 if ((timer&7)==0) cpt_anim++;
 if (cpt_anim>2) cpt_anim=0;


 }

bfg a écrit:Voilà comment j'ai fait salement l'animation.

Code:

struct genresSprites
{
    u16 *pal; //pointer to pal data
    u32 **sprites; //pointer to sprites data
    u16 count; //nb sprites
    u16 width; //width of each sprite in pixels (not tiles!)
    u16 height; //height of each sprite in pixels (not tiles!)
    u16 size; //since we use width/height in pixel, useful info on sprite size
    //TODO : size is not SGDK compliant, you need to use size>>8
    // will be fixed in coming release
};

extern struct genresSprites player_sprites;


SpriteDef sprites[MAXSPRITE];

        while(1)
        {
                /* GESTION DES MOUVEMENT DROITES */
 if (bright1==1)
 {
 sprites[0].posx+=2;
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,0,BASE_SPRITE_PATTERN+16+(cpt_anim<<4));

 }
 else    /* GESTION DES MOUVEMENT GAUCHE */
 if (bleft1==1)
 {
 sprites[0].posx-=2;
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,1,BASE_SPRITE_PATTERN+16+(cpt_anim<<4));
 }
 else
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,0,BASE_SPRITE_PATTERN);

 for (spr=0;spr<MAXSPRITE;spr++) VDP_setSpriteP(spr, &sprites[spr]);

 if ((timer&7)==0) cpt_anim++;
 if (cpt_anim>2) cpt_anim=0;


 }

De toutes façons à l'écran ça se voit pas 

bfg a écrit:Voilà comment j'ai fait salement l'animation.

Code:

struct genresSprites
{
    u16 *pal; //pointer to pal data
    u32 **sprites; //pointer to sprites data
    u16 count; //nb sprites
    u16 width; //width of each sprite in pixels (not tiles!)
    u16 height; //height of each sprite in pixels (not tiles!)
    u16 size; //since we use width/height in pixel, useful info on sprite size
    //TODO : size is not SGDK compliant, you need to use size>>8
    // will be fixed in coming release
};

extern struct genresSprites player_sprites;


SpriteDef sprites[MAXSPRITE];

        while(1)
        {
                /* GESTION DES MOUVEMENT DROITES */
 if (bright1==1)
 {
 sprites[0].posx+=2;
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,0,BASE_SPRITE_PATTERN+16+(cpt_anim<<4));

 }
 else    /* GESTION DES MOUVEMENT GAUCHE */
 if (bleft1==1)
 {
 sprites[0].posx-=2;
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,1,BASE_SPRITE_PATTERN+16+(cpt_anim<<4));
 }
 else
 sprites[0].tile_attr=TILE_ATTR_FULL(PAL1,1,0,0,BASE_SPRITE_PATTERN);

 for (spr=0;spr<MAXSPRITE;spr++) VDP_setSpriteP(spr, &sprites[spr]);

 if ((timer&7)==0) cpt_anim++;
 if (cpt_anim>2) cpt_anim=0;


 }

Disons que tu as passé par l'ancienne méthode ;-)
Ça marche mais c'est bien plus bas niveau que les méthodes SPR_xxx ;-)

pckid a écrit:Pas mal du tout, j'avais pas trouvé cette function mais je l'ai fait comme çà

SPR_setAnim(&sprites[nSpriteX], nSpriteY);

Et je bouge le nSpriteX et nSpriteY


Par contre dans ma boucle
je ne sais pas si je garde cela si c'est necessaire ?

// update sprites (only one to update here)
 SPR_update(sprites, 1);

Merci à toi
j'ai hate de m'attaquer à la map, (meme si tu la genere  pas je crois que Sgdk sait la lire ?)

Tu vas voir ce n'est pas bien compliqué ;-)
pour le SPR_update(..) oui tu dois le conserver, normalement tu dois appeler cette méthode a chaque frame, c'est elle qui met a jour ton(tes) sprite(s) s'il est animé ou si tu viens de changer sa position.

Stef pour les sprites, tu détectes le nombre d'image par ligne non ?

Car j'ai animé mon croco, j'ai mon animation wait en 2 images et la marche en 6 images et je n'ai aucun problème.

Normalement oui ça détecte le nombre de frame pour une animation, j'ai du mal a comprendre ton problème sur l'animation ?

Il n'y a pas de problème.
Je voulais juste une confirmation, car je ne comprenais pas pourquoi ca fonctionnait.

stef a fabrique une direction assiste , au départ c est déroutant car on cherche a allé plus bas. Et en fait on peut faire des super trucs.

on peut surement faire des choses a la mano pour ceux qui aiment. J esserais après avoir fini un niveau de faire de l assembleur voir si je comprends quelque chose . Si j y arrive je pourrais faire des choses en pc engine qui possède pas un tel outil.

mais ce sont mes machines préférées et un rêve de gosse qui est entrain de se réaliser. Développer un jeu sur des consoles retro !

r_songo a écrit:Il n'y a pas de problème.
Je voulais juste une confirmation, car je ne comprenais pas pourquoi ca fonctionnait.

Ok, tant mieux si ça fonctionne bien alors

stef a fabrique une direction assiste , au départ c est déroutant car on cherche a allé plus bas. Et en fait on peut faire des super trucs.

on peut surement faire des choses a la mano pour ceux qui aiment. J esserais après avoir fini un niveau de faire de l assembleur voir si je comprends quelque chose . Si j y arrive je pourrais faire des choses en pc engine qui possède pas un tel outil.

En fait il y a toujours possibilité de travailler à plus bas niveau pour les sprites (avec les méthodes VDP_setSpritexxx(..) ) mais réellement ça peut devenir vite prise de tête quand tu veux gérer des gros sprites par exemple. Les méthodes SPR_xxx sont bien plus simples à utiliser mais en contre partie tu as une abstraction avec l'implémentation hardware (allocation des sprites hard, des tiles en VRAM...).

Stef le : SPR_update(sprites, 1);

C'est pour dire qu'on met à jour le sprite 1  du tableau ou qu'on met 1 sprite à jour dans le tableau ?
Ex: SPR_update(sprites, 50); on met 50 sprites à jour ?

Que se passe t'il lorsqu'on a des sprites temporaire. Comme les anneaux dans Sonic.

Si on a 64 sprites au total, le sprite 5 et 10 peuvent avoir été pris par Sonic. Du coup, il ne faut plus les gérer. Est ce que les sprites ont une propriété "en vie" ?

Comment faut t'il réinitialiser un sprite etc ...

Merci

Oui en fait c'est ça, il faut bien voir que la méthode SPR_update(..) ne doit être appelée qu'une seule fois par frame ! En gros une fois que tu as mis à jour tout tes sprites pour la frame en cours, tu termines avec le SPR_update(..) qui va reconstruire la table de sprite du VDP et s'assurer que les bonnes images soient en VRAM.

Effectivement si tu dois gérer des sprites temporaires, tu peux changer le nombre de sprites à mettre à jour et il vaut mieux faire ainsi pour alléger les traitements, du coup il vaut mieux mettre les sprites qui seront toujours visible en début de table et les sprites temporaires derrière.
Si tu veux ré-initialiser un sprite tu utilises la méthode SPR_initSprite(..) comme lors de la première initialisation

En prenant un exemple concret
Si en position 45 à 62 j'ai des anneaux.
Si j'attrape les sprites 46 et 48, je dois supprimer ces 2 sprites de l'affichage.

Je ferrais un : SPR_update(sprites, 64) dans tous les cas car je dois bien mettre à jour de 1 à 62.
Il me mettra forcement à jour les sprites 46 et 48.

Puis je mettre à null les sprites 46 et 48 ? Si oui comment?
Ou dois je mettre visibility à -1 ou une autre propriété, et géré par moi même les sprites mort.

Pour l'instant il n'y a pas de flag pour mettre le sprite en "enabled", la solution simple c'est donc de le mettre hors écran avec une position X à -100 par exemple.
A l'avenir j'ajouterai surement un flag "enabled" pour faciliter ce genre d'opération et aussi pour que ça soit plus rapide car avec la position X à -100 je passe par un calcul de visibilité pour "rejeter" le sprite.

Oui, ca pourrait être pas mal.