Problème de sprites avec SGDK

[Kivutar]

Bonjour,

Je suis en train d'ajouter une seconde entité dans mon jeu en plus du personnage principal. Et j'ai un crash au moment du SPR_update je crois.

J'utilise une version un peu vieille de SGDK, celle fournie dans gendev.

Mon code est comme ça:

J'ai deux sprites:

Code:

SPRITE player_sprite "assets/player.png" 6 6 FAST 5
SPRITE coin_sprite "assets/coin.png" 2 2 FAST 5

Code:

Sprite* sprites[2];
u32 sprite_ind = 0;

Je partage ce tableau et cet entier dans mes entités avec un extern.

J'utilise PAL2 et PAL3

Code:

    VDP_setPalette(PAL2, player_sprite.palette->data);
    VDP_setPalette(PAL3, coin_sprite.palette->data);

Dans le constructeur de mon personnage, je fais ça:

Code:

    self->sprite_ind = sprite_ind++;
    SPR_initSprite((Sprite*)&sprites[self->sprite_ind], &player_sprite, fix32ToInt(self->x), fix32ToInt(self->y), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
    SPR_setAnim((Sprite*)&sprites[self->sprite_ind], PLAYER_ANIM_STAND);

Et idem pour ma seconde entité, le "coin":

Code:

    self->sprite_ind = sprite_ind++;
    SPR_initSprite((Sprite*)&sprites[self->sprite_ind], &coin_sprite, fix32ToInt(self->x), fix32ToInt(self->y), TILE_ATTR(PAL3, TRUE, FALSE, FALSE));
    SPR_setAnim((Sprite*)&sprites[self->sprite_ind], 0);

Et puis tout à la fin de mon while(1), j'appelle:

Code:

SPR_update((Sprite*)sprites, sprite_ind);

Et là c'est le drame:



Par contre si je force à 1:

Code:

SPR_update((Sprite*)sprites, 1);

Ca ne crashe plus, mais évidement mon sprite n'est pas envoyé au VDP.

[Hpman]

J'ai l'impression que tu refourgues des Sprite** aux fonctions au lieu de Sprite* ?

[Kivutar]

Mh non je pense pas. En tout cas si je retire ce & plus rien ne fonctionne. Je pense que l'ancien SGDK attends ces pointeurs.

[Tryphon]

Ton sprites est un tableau de Sprite*, donc c'est un Sprite**.

Dans SPR_update, tu le castes en Sprite*...

Je dis pas que c'est faux, mais ça me met très mal à l'aise. Comme je n'utilise pas le sprite engine, je ne sais pas exactement ce qui est attendu, mais à mon avis, y'a déjà un truc qui pue là...

[Hpman]

Tableau de Sprite*, donc écrire

SPR_setAnim((Sprite*)&sprites[self->sprite_ind], PLAYER_ANIM_STAND);

refile bien un Sprite** (l'adresse du Sprite*).

Il faut écrire  SPR_setAnim(sprites[self->sprite_ind], PLAYER_ANIM_STAND); pour filer un Sprite* à la fonction.

[Kivutar]

En effet, vous avez raison... Je me demande même comment ça a pu fonctionner jusque là..

Bon du coup j'ai réussi à avoir quelque chose qui fonctionne en faisant un tableau de Sprites au lieu d'un tableau de pointeurs.

Code:

Sprite sprites[2]

puis

Code:

&sprites[self->sprite_ind]

Et là c'est bon.

Par contre di je fais

Code:

Sprite* sprites[2]

Et

Code:

sprites[self->sprite_ind]

Ca crashe encore, sans que je comprenne pourquoi. Peut être la façon don't j'utilise extern. C'est dommage car je trouve cette notation plus lisible.

[Hpman]

Bah il est initialisé à quelque chose ton tableau de pointeur? Parce que dans les bribes de l'exemple on est pas trop sûrs 

[Stef]

Aie aie... tu es sur une vieille version de SGDK, je te conseilles de passer à la dernière, l'API pour le Sprite Engine a un peu changé mais c'est plus performant et plus stable aussi :p

Maintenant tu dois utiliser la méthode SPR_addSprite(..) ou SPR_addSpriteEx(..) qui te retourne directement un Sprite*
J'avoue ne plus bien me souvenir de l'ancienne implémentation avec SPR_initSprite(..)

[Kivutar]

J'ai réussi en mettant à jour gendev, qui a maintenant la nouvelle version de SGDK. Et je peux alors utiliser SPR_addSprite et ça m'a aidé pour mon tableau de pointeurs.

[Stef]

Normalement c'est quand même plus simple avec le nouveau Sprite engine :)
Tu programmes sous linux ? c'est quelle version de GCC qui vient avec Gendev ?
Enfin je dirais... tant que ça marche :p

[Kivutar]

Oui sur Arch Linux. Et c'est GCC 6.3.0.

[Stef]

OK, donc tu es dans la même situation que la version de base :-)

[Tryphon]

En effet, vous avez raison... Je me demande même comment ça a pu fonctionner jusque là.

Tu viens de découvrir le grand bonheur du C

Le coup de traficoter le code jusqu'à ce qu'il compile (ce qu'on fait tous dans des langages plus évolués) est le meilleur moyen de s'arracher les cheveux avec un code qui compile mais qui plante. Tu ne peux malheureusement pas te passer de bonnes séances de prise de tête sur le thème "quoi est un pointeur sur quoi ?", sauf quand t'es un pro du C je suppose, mais c'est pas encore mon cas...

[Kivutar]

Oui pourtant ça fait 2 ans que j'en fais tous les jours mais c'est toujours pas rentré dans ma tête

Je comprends bien que mon argument était un ** à cause de mon &.

Par contre je vois pas comment ça a pu marcher pendant des jours comme ça.

Et pourquoi c'est à l'ajout du second sprite que le problème s'est manifesté.

Ni en quoi le nouveau SGDK m'a permis d'utiliser un tableau de pointeurs alors qu'avec l'ancier SGDK je n'y arrivais pas.

Que de mystères.

[Hpman]

Avec un mauvais pointeur tu as donc une mauvaise adresse et utilises un emplacement plus ou moins pifométrique de la RAM.
Ça va fonctionner jusqu'a ce que le compilateur loge une autre variable à cet emplacement, censé être libre.

[philip]

Le pire c'est quand on a ce genre de message d'erreur sur la console réelle, c'est ma hantise. La MD n'aime pas qu'on lui donne l'ordre de lire un tableau hors limites, soit une sortie de tableau... un émulateur lui peut laisser passer.

[Stef]

C'est surtout que les émulateurs n'émulent pas toutes les exceptions du CPU (car bien souvent un programme évite d'en générer sinon c'est qu'il y a un problème :p).

Comme le dit Hpman, souvent ça marche par chance car tu pointes sur un endroit aléatoire en mémoire qui n'est pas utilisé... mais dés que cet endroit sera utilisé par autre chose tu auras des problèmes.