Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Top l'âne]

Hop, j'ai plié un code qui m'évite de produire des boucles à l'infini.
Un premier test intuitif vite fait pour voir:

Code:

int main()
{

    JOY_init();
    u8 screenSelect = 1;

    VDP_setScreenHeight224 ();
    VDP_setScreenWidth320 ();
    VDP_setPlanSize(64, 32);


    while(1)
    {
        if(screenSelect == 1)
            titleScreen(WPLAN);
        else if(screenSelect == 2)
            mainGame(WPLAN);

        if(screenSelect == 1)
            screenSelect = 2;
        else if(screenSelect == 2)
            screenSelect = 1;

    }

    return 0;
}

Je prends bien soin de sortir des boucles "intro" et "game" pour revenir proprement dans le main.
Intégré au code définitif, ça tourne. :)

L'erreur me parait évidente à présent, merci messieurs.

je vais tâcher de faire ça propre Philip.

[dub]

Hop, j'ai plié un code qui m'évite de produire des boucles à l'infini.
Un premier test intuitif vite fait pour voir:

Code:

int main()
{

    JOY_init();
    u8 screenSelect = 1;

    VDP_setScreenHeight224 ();
    VDP_setScreenWidth320 ();
    VDP_setPlanSize(64, 32);


    while(1)
    {
        if(screenSelect == 1)
            titleScreen(WPLAN);
        else if(screenSelect == 2)
            mainGame(WPLAN);

        if(screenSelect == 1)
            screenSelect = 2;
        else if(screenSelect == 2)
            screenSelect = 1;

    }

    return 0;
}

A l'arrache, je pas fais de test mais ça devrait marcher comme ça :

Code:

void titleScreen(u16 window)
{


    VDP_drawText("A-PROJECT", 5, 3);

    VDP_drawText("press START", 4, 6);

   
    while(screenSelect == 1)
    {
        if(JOY_readJoypad(JOY_1) & (BUTTON_START))
        {
            VDP_resetScreen();
            VDP_init();

            screenSelect = 2;
          
        }

        VDP_waitVSync();
    }



}


int main()
{

    JOY_init();
    u8 screenSelect = 1;

    VDP_setScreenHeight224 ();
    VDP_setScreenWidth320 ();
    VDP_setPlanSize(64, 32);


    while(1)
    {
        if(screenSelect == 1)
            titleScreen(WPLAN);
        else if(screenSelect == 2)
            mainGame(WPLAN);

        
    }

    return 0;
}


Comme ça tu devrais pouvoir rester dans ta boucle while secondaire tant que tu n'appuies pas sur Start. Et tu fais pareil pour ton mainGame() avec screenSelect = 1

[Top l'âne]

Parfait, c'est justement ce que j'ai avais envisagé pour micro-optimiser le code, pointer sur screenSelect depuis mes fonctions d'intro et de jeu.

Merci de me mâcher le boulot. :)


Je me sens plus à l'aise de cette manière qu'en calant le VDP_waitVSync(); dans la boucle du main comme l'a présenté Philip.
D'ailleurs j'avais déjà vu ça il y a quelques temps quand j'avais jeté un oeil au bêta de Sega_swirl, à l'époque j'avais pas bien saisi la manoeuvre.

[tetsuro]

Y'aura du monde à mettre sur les Crédits

[dub]

Merci les gars, mais c'est pas la peine. L'important c'est d'aider.

Même si le C est un langage assez stricte, on a tous nos habitudes de codage. Tout est bon, l'important, c'est la rapidité d'exécution. 

Dans la boucle, comme le dit philip, il vaut mieux mettre un VDP_waitsync() quand même, on ne l'utilise pas tout le temps, mais quand on boucle dans le while principal, ça peut éviter un glitch à l'écran.

N'hésitez pas à poster quand il y a un soucis de compréhension ou autre, et bientôt c'est vous qui expliquerez aux autres.

[philip]

Ta proposition est correct dub. Mais à l'usage, le bouton start est assez délicat (tout dépend de ce que l'on veut proposer), je me suis pris un peu la tête avec, la solution : attendre que le joueur relache ce bouton, pour effectivement valider la volonté du joueur.

Pour mettre un jeu en pause, voyez l'usine à gaz:

Code:

   if (value & BUTTON_START) // gestion de la mise en pause du jeu par le joueur
      {
      if (gspause==0) gspause=1;
      if (gspause==2) gspause=3;
      }
   if (!(value & BUTTON_START))
      {
      if (gspause==1) gspause=2;
      if (gspause==3) gspause=0;
      }





if (gspause==0) // jeu !
{

[Stef]

Il y a un "JOY Event Handler" dans SGDK pour gérer facilement les événements venant des manettes (dont un relachement de bouton), tu te compliques vraiment la vie là :)

[philip]

Il y a un "JOY Event Handler" dans SGDK pour gérer facilement les événements venant des manettes (dont un relachement de bouton), tu te compliques vraiment la vie là :)

J'ai testé, mais si on lache le bouton start, cela redemarre aussitôt avec mon exemple :

Code:

   u16 gspause;
    void handleJoyEvent(u16 joy, u16 changed, u16 state)
    {
    if ((joy == JOY_1) && (changed == BUTTON_START) && (state == 0))
        {
        if (gspause == 1)
            {
            gspause = 0;      
            }    
        }
    }

puis dans la boucle principale :

Code:

   if (value & BUTTON_START)
        {
        if (gspause == 0)
            {
            gspause = 1;      
            }    
        }
    JOY_setEventHandler(handleJoyEvent);

La solution, un peu plus complexe :

Code:

    u16 gspause;
    void handleJoyEvent(u16 joy, u16 changed, u16 state)
    {
    if ((joy == JOY_1) && (changed == BUTTON_START) && (state == 0))
        {
        gspause += 1;
        if (gspause == 4)
            {
            gspause = 0;     
            }   
        }
    }
   
   
    // puis dans la boucle principale :
    if (value & BUTTON_START)
        {
        if ((gspause == 0) || (gspause == 2))
            {
            gspause += 1;
            }   
        }
    JOY_setEventHandler(handleJoyEvent);

[dub]

Je t'ai fait un exemple tout simple.

Quand tu appuies sur un bouton tu changes la valeur de la pause, quand tu relaches rien ne se passe.

Code:

#include <genesis.h>

u8 gsPause;

void joyEventGame(u16 joy, u16 changed, u16 state)
{
 // START button state changed
    if (state & changed & BUTTON_START)
    {
  if (gsPause == 0)
  {
   gsPause = 1;
  } else {
   gsPause = 0;
  }
    }
}

int main()
{
 u16 posX = 0;
 gsPause = 0;
    JOY_init();

    VDP_setScreenHeight224 ();
    VDP_setScreenWidth320 ();
    VDP_setPlanSize(64, 32);
    //titleScreen();
 JOY_setEventHandler(joyEventGame);
 
 while(TRUE)
 {
 
  if (gsPause == 0)
  {
   posX++;
   if (posX > 320) posX = 0;
  }
  
  VDP_drawText("GAME", posX, 10);
 }
    return 0;
}


Pour Citizen kane, j'utilise la dernière version du sgdk, mais ca devrait faire pareil avec l'ancien.

[tetsuro]

Coucou à tous,

On veut afficher du texte pour les scores ou dialogues par exemple. J'ai analysé quelques roms avec "Gens Kmod" et je vois que dans Sonic 1 et Twinckle Tale les textes sont affichés via des tuiles 8x8 sur le plan sprites, mais dans Castle Of Illusion les textes sont affichés en "plan A" mais si on décoche "Window" ça retire aussi les textes...

- 1 : C'est quoi ce plan "Window" ? Il sert à quoi ? On ne comprend pas son utilité avec Kane, certains jeux l'utilisent, d'autres non,  dans certains tutos ils disent que ce plan servait à afficher les scores, vies etc, mais pour l'instant les jeux que j'analyse affichent tous les scores, vie, textes, via le "plan A".

- 2 : Une question que je me pose, quand on envoie par exemple une "image.png" de 8x8 à SDGK, est-ce qu'il "converti" cette image en tableau de coordonnées de couleurs hexadécimale en ASM tel que celui-ci ? :
Lettre H:
   dc.l 0x11000110
   dc.l 0x11000110
   dc.l 0x11000110
   dc.l 0x11111110
   dc.l 0x11000110
   dc.l 0x11000110
   dc.l 0x11000110
   dc.l 0x00000000
Donc si oui, est-ce que toutes les images sont traitées de cette façon par SDGK ? Si non y aurait-il des avantages ou inconvénients à éditer le texte en Héxa ou en "tuiles.png" ?

- 3 : Vous affichez du texte comment vous sur Megadrive ? Nous on a pensé à faire toutes les lettres en 8x8 sur une sprites sheet en ligne de 8x26=208, donc une "image.png" de 8x208 et on déplacerait le curseur mémoire pour appeler telle ou telle lettre à afficher, ça vous parait bon ?

Merci d'avance pour votre aide

[dub]

Pour le 2., je ne sais pas comment le sgdk stock en interne car en vérité c'est peut important pour moi.
Par contre, c'est plutôt comme ça normalement :
dc.l 0x1AB00110
  dc.l 0x11000110
  dc.l 0x11000110
  dc.l 0x11111110
  dc.l 0x11006110
  dc.l 0x11000110
  dc.l 0x11000110
  dc.l 0x00000000

Les chiffres en Hexa indiquent la couleur donc 0=transparente et après de 1 à F pour les couleurs de la palette.

[dub]

Pour la font, en fait ça dépend des besoins. On peut faire avec tes 3 manières.
En sprites mais ça bouffe de l'affichage en horizontal si tu en as trop, tu va avoir du clipping. Donc plutôt utiliser avec un font 16*16.

De manière général, on utilise le PlanA pour afficher des tiles des fonts. Et si tu as un scrolling dans le planA, tu utilise le WINDOW pour afficher tes tiles. Le WINDOW utilise les l'endroit du planA pour afficher des tiles. Donc si tu scroll tout le planA, tout sera scrollé sauf la partie Window. A toi de définir la taille et la position. Surtout utiliser en rpg ou pause mais on peut le voir comme un HUD comme dans mario 3 en bas par que ce plen n'est pas transparent.
Ce qu'il faut retenir, c'est que les plan A et WINDOW se partage le même layer.

Pour la font, tu as ce qu'il faut dans sgdk et tu peux ajouter ta propre font et utiliser une palette pour l'améliorer.

Code:

VDP_setTextPalette(PAL1);
      VDP_loadFont(&myfont, 1);

VDP_setTextPlan(PLAN_A);
VDP_drawText("HIGHSCORE", 20, 8);

Je vais regarder si je trouve une image exemple.



J'avais oublié pour l'ajout dans le fichier ressource : TILESET myfont "sprite/font.png" 0

[tetsuro]

Merci dub pour ton aide, c'est top.

Le code que je montre est bien de l'héxa c'est car le 1 est le rouge et le 0 la transparence, c'est un H en rouge. Du coup je vois que c'est une palette prédéfinie par défaut c'est ça ? Si oui c'est quoi cette palette ? On peut changer ces couleurs préfixées ?

Je n'ai pas compris quand tu parles d’afficher un font en 16x16. Effectivement ils sont en 16x16 dans Sonic 1 mais en 8x8 dans Castle Of Illusion.

Je sais qu'il y a un VDPdrawtext(), mais on veut une police personnalisée.

Pour la font, tu as ce qu'il faut dans sgdk et tu peux ajouter ta propre font et utiliser une palette pour l'améliorer.

Tu fais ça ? Et tu utilise l'image que tu as partagée ? C'est ta font personnalisée ou tu l'a récupérée ?

[dub]

OK. Donc t'as bon, c'est bien en hexa avec 2 couleurs dans ton cas.

Tu peux choisir ta palette avec VDP_setTextPalette(PALX); Dans ce cas, ça prendra les couleurs de la palette choisi. Y a pas de palettes prédfinie, quand tu charges une image en png, tu places les couleurs dans une palette et donc cette font va prendre la même palette que ton image.

C'est une font basique que j'ai récupéré je ne sais plus où. Mais c'est une font personnalisée, tu peux y mettre la police que tu veux ou même des smiley si tu veux. On appelle ça une police bitmap, j'en utilise dans mes programmes depuis un paquet d'années. Donc rien vous empêche de la modifier.

Si tu affiches la valeur de A en nombre entier , tu auras 65 suivant le codage ASCII, c'est pour ça qu'on utilise cette forme de tableau pour la police bitmap
https://en.wikipedia.org/wiki/ASCII
Ca évite de faire des calculs pour trouver la position en mémoire (sauf pour du 16*16, dans ce cas faut personnaliser aussi)


Quand je parle de font en 16*16 pour Sonic, je voulais dire des sprites de 16*16 pour afficher des nombres sur le sprite layer. Comme les 2 plans de sonic bouge et qu'ils veulent pas un WINDOW non transparent. Leur seul solution est d'afficher le score avec des sprites. Alors tant qu'à faire autant claquer du 16*16 ou alors du8*8 quand on veut que ce soit moins envahissant.

J'espère que j'ai bien répondu à tout, j'ai tendance à m'étaler.

Si tu veux un exemple avec un font perso en 8*8, je pourrais trouver ça.  

[Stef]

Il y a un "JOY Event Handler" dans SGDK pour gérer facilement les événements venant des manettes (dont un relachement de bouton), tu te compliques vraiment la vie là :)

J'ai testé, mais si on lache le bouton start, cela redemarre aussitôt avec mon exemple :

Code:

...

Ca me semble bien complexe tout ça ^^
Bon déjà tu as besoin d'initialiser qu'une seule fois le Joy Event Handler donc je te conseille de mettre cette ligne de code :

Code:

JOY_setEventHandler(handleJoyEvent);

Une seule fois à l'init de ton programme.
ensuite il faut comprendre comment fonctionne ce satané Joy Event Handler :)

Code:

void handleJoyEvent(u16 joy, u16 changed, u16 state)

Comme tu peux le voir la fonction reçoit 3 paramètres.
Le premier paramètre 'joy' défini quel joypad a généré l'evenenement (entre JOY_1 et JOY_8 avec les multipad).
Le second paramètre 'changed' permet de savoir quels sont les boutons dont l'état à changé (que ce soit un pressed ou released).
Le troisième paramètre 'state' donne l'état courant des boutons (1 pour pressé, 0 sinon).

Du coup avec ces 3 paramètres tu peux absolument tout tester :)

* si tu veux juste tester que le bouton START est actuellement pressé:

Code:

if (state & BUTTON_START)

* si tu veux juste tester que le bouton START est actuellement relaché:

Code:

if (!(state & BUTTON_START))

* si tu veux tester que le bouton START a changé d'état (vient d'être pressé ou relaché) :

Code:

if (changed & BUTTON_START)

* si tu veux tester que le bouton START vient d'être pressé :

Code:

if ((changed & BUTTON_START) && (state & BUTTON_START)

A noter que la version du dub marche très bien aussi pour tester qu'un bouton vient d'être pressé


* si tu veux tester que le bouton START vient d'être relaché :

Code:

if ((changed & BUTTON_START) && !(state & BUTTON_START))

Pour les histoires de font, dub a bien tout expliqué... Par défaut les fonctions SGDK  VDP_drawText(..) utilisent une font definie en tiles de 8x8 et dessinent dans les plans (plan A, plan B ou window). Tu peux redéfinir la font de SGDK avec la méthode que dub a indiqué, j'ai l'impression que la font qu'il a posté est justement celle de SGDK que tu peux trouver ici :
https://github.com/Stephane-D/SGDK/blob/master/res/image/font_lib.png

La window est une partie fixe du plan A, elle est utile pour justement gérer un HUD.

[dub]

Oui, effectivement, je l'ai bien trouvé sur ton git. Je télécharge tellement de données que je sais plus d'où ca vient.

[Top l'âne]

Tetsu a pris les devants pour venir demander des infos sur l'usage des polices, c'est cool, je vois des infos qui font plaisir à lire.^^

Par rapport au rendu que nous recherchons, Sonic est un bon exemple justement. Puisque nos plans A & B seront quasi systématiquement sujets à scrolling.
J'imaginais donc devoir travailler les polices au travers de sprites ce qui m'ennuie un peu car je devrais me priver de quelques process utiles du VDP (typiquement celui qui module la valeur d'une variable en texte pour le scoring^^).

Or donc, je suis bien heureux d'apprendre qu'il est possible de lancer un affichage texte sur le WINDOW.
Tout à ma joie nouvelle je me disais que c'était aussi simple qu'un VDP_setPlanText(PLAN_WINDOW);

Mais le PLAN_WINDOW n'est pas accepté comme argument. Et à la lecture du doxy, je ne trouve rien qui me le permettrait.

[tetsuro]

Désolé si Kane et moi avons postés en même temps et à la suite, c'est un hasard, nous ne sommes pas à côté géographiquement. Et kane est plus dans le code que moi pour le moment.

- Window est forcément "non transparent" ?

- Sij'ai tout compris pour personnaliser les polices j'ai donc à récupérer la font map et modifier les polices en gardant les positions déjà établies ?

- Du coup on utilise Window si on veut un hud non transparent, ou on charge la font map en sprites si ont veut l'afficher en transparence? Le problème qu'a Kane c'est que si on affiche en transparence le score eh bien il scroll. Mais dans Sonic 1 les scores ne scrollent pas...

Merci pour votre aide précieuse et surtout votre patiente.

[dub]

Pour répondre aux deux en même temps.

Tu n'as pas le plan window directement avec ta version du sgdk, faudrait migrer sur la dernière. Plus précisément, on peut pas utiliser drawtext sur un plan window dans ta version du sgdk.

Le plan window n'est pas transparent d'après mes tests et d'après ce que je sais. Alors vous allez être obligé : soit de sacrifier une ligne de tiles du plan A qui ne scrollera pas, soit utiliser des sprites.

Et oui, le plus simple est de garder le Template de la font et de la modifier aux même positions si tu veux utiliser drawtext.

[philip]

@stef et dub
merci !


@ Citizen Kane & Tetsuro
Pour mes jeux j'utilise des sprites pour les scores et autres, ce qui est le cas de beaucoup de jeu comme sonic justement.

J'utilise un tableau pour les 10 chiffres de 0 à 9 (ta planche d'image des chiffres dans la vram, disons que tu décide de la mettre à 704) :
u16 unite;
u16 chiffresvram[10];
chiffresvram[0] = 704; // position vram chiffre 0
chiffresvram[1] = 736; // position vram chiffre 1
etc...

Il faut agir directement sur la vram avec du VDP_waitDMACompletion(); pour commencer

 et la copie d'un emplacement en vram du chiffre (issu de ta planche), vers l'emplacement réservé à ton sprite avec VDP_doVRamDMACopy (chiffresvram[unite],position vram de ton sprite,32);


puis un autre VDP_waitDMACompletion(); // par sécurité

tout cela bien sûr, après la commande VDP_waitVSync();

[Stef]

Tetsu a pris les devants pour venir demander des infos sur l'usage des polices, c'est cool, je vois des infos qui font plaisir à lire.^^

...

Mais le PLAN_WINDOW n'est pas accepté comme argument. Et à la lecture du doxy, je ne trouve rien qui me le permettrait.

Tu es sur la dernière version de SGDK ? Car c'est un ajout assez récent en fait (effectivement avant SGDK ne gérait pas la window pour toutes les fonctions).

Edit: purée encore devancé par dub   Merci

Sinon par rapport au plan WINDOW, il peut être transparent, ce n'est pas le problème... Le vrai problème c'est qu'il remplace le plan A, du coup là tu as la window, le plan A ne s'affiche pas. C'est pour cette raison que bon nombre de jeux mettent la window en opaque. D'autres jeux (comme Street of Rage 2) utilise la window pour le HUD (barre de vie & timer) et en transparence mais le level est intelligemment designé pour que le plan A ne soit jamais visible à la place de la window :)

[Top l'âne]

Test d'affichage texte par sprites ok.
Je ne me suis pas pris la tête pour le moment.
Un simple sprite sheet pour les nombres mis en place via le sprite_engine.

Par ailleurs j'ai clôturé ce bug des switchs d'écran en ajoutant le "JOY Event Handler".

L'essai sous everdrive parait concluant.
En testant un usage abusif du "start" toutes les secondes/demies secondes, le soft reste stable. Cool!
En frittant le "start" comme un sourd j'arrive quand même à faire disjoncter l'everdrive sans passer par la case "illegal instruction"...^^
Mais le cas échéant j'ai dans l'idée que ça doit se soigner en intercalant entre chaque écran un espace d'attente pour refuser l'accès au controller.

Encore merci à tous. :)

[fourchette]

Bonjour à tous,

Je me suis mis depuis peu à SGDK en espérant adapter un petit jeu de réflexion sur Megadrive mais j'ai quelques soucis que je n'arrive pas à résoudre, peut être certains d'entre vous ont déjà été confrontés à l'une de ces problèmes.

1/ pour le menu de départ, j'ai 3 lignes de texte (de 5 lettres, 8 lettres, 7 lettres respectivement), chaque lettre étant un sprite 16x16. Hors seuls les 16 premiers sprites s'affichent. Est-ce que j'aurais dépassé une limite de sprites ?

Le code pour remplir la première ligne :

Code:

for( i=0; i<5; i++ )
  line0[i] = SPR_addSprite( &fontBigSpr, posx+16*i, posy, TILE_ATTR(PAL2, TRUE, FALSE, FALSE) );
 
SPR_setAnim(line0[0], 0);
SPR_setAnim(line0[1], 2);
SPR_setAnim(line0[2], 5);
SPR_setAnim(line0[3], 3);
SPR_setAnim(line0[4], 15);

Et la déclaration de la ressource :

Code:

SPRITE   fontBigSpr "font_big.bmp"    2 2 0 0

2/ J'ai un sprite "software" de 80x16 et si je le positionne en partie à l'extérieur de l'écran, à droite, et que je le déplace à gauche, seule les sprites hardwares qui sont déjà affichés continuent de s'afficher mais pas ceux en dehors de l'écran.

J'ai essayé d'illustrer mon problème :
(noir= écran, blanc=hors écran, jaune=sprites)



Le code correspondant :

Code:

posx = 316;
posy = 100;
sprite = SPR_addSprite( &resSpr, posx, posy, TILE_ATTR(PAL1, TRUE, FALSE, FALSE) );

while( 1 )
{
  SPR_setPosition( sprLogo, posx--, posy );
  SPR_update();
  VDP_waitVSync();
}


Et voici mon initialisation en début de programme pour chaque cas :

Code:

VDP_setScreenWidth320( );
VDP_setScreenHeight224( );
 
VDP_setPlanSize( 64, 32 );
VDP_setScrollingMode( HSCROLL_PLANE, VSCROLL_PLANE );
 
SPR_init(16, 256, 256);

Si quelqu'un a une idée...?

[philip]

Salut, je crois que la limite d'affichage horizontal pour les sprites, c'est 320 pixels de large. Donc les sprites qui ne s'affichent pas, c'est le résultat de ton code. Mais comme j'utilise une gestion bas niveau pour mes sprites, je ne peut pas commenter ton code.

Ci-dessous, un outil précieux pour vérifier tes sprites avec KMOD 0.7.3, il faut passer par le menu :
CPU/Debug/Genesis/VDP-Sprites

http://gendev.spritesmind.net/forum/viewtopic.php?f=7&t=2264

Une fenêtre s'affiche avec les sprites numéroté de 0 à 79 avec leurs position X et Y et leur taille, bon debug.

[Stef]

Il y a un bug dans la gestion des sprites dans le dernier SGDK qui peut amener à ça. Tu prix le corriger en forçant la visibilité de tes sprites avec SPR_setVisibility(spr, ALWAYS) ou un truc dans le genre. Ce bug sera corrigé dans la prochaine version.

[fourchette]

@philip
Tu aurais des sources libres/disponibles contenant ta gestion bas niveau des sprites ?

@stef
Merci, ça résoud mon problème n° 2

Et pour mon problème n° 1, c'est juste que je suis trop con, j'ai mis 16 comme nombre de sprites dans mon SPR_INIT() donc forcément...

[Top l'âne]

@philip
Tu aurais des sources libres/disponibles contenant ta gestion bas niveau des sprites ?

Il s'agirait d'utiliser les fonctionnalités du VDP_sprite plutôt que celles du Sprite_engine.

Mes deux premières démos étaient agencées dans ce sens.
Un Space Invaders et un shooter horizontal, y a pas forcément grand chose dedans, mais je partage mes sources bien volontiers.
Si intéressé tu peux me MP ton mail et je t'envoie les projets CB concernés. :)

[fourchette]

A priori, je ne suis pas encore assez malade pour pouvoir envoyer des MP.

Je continue d'avancer doucement sur l'apprentissage du SGDK, et ainsi du portage qui m'intéresse. Mais quel enfer l'optimisation de la gestion des palettes de couleur, à partager entre sprites/tiles, en partant d'un jeu existant qui n'a pas été conçu de cette manière. Je passe plus de temps à ça qu'a coder le moteur.

[Top l'âne]

Clair, la gestion des palettes c'est un boulot à temps plein.^^

Effectivement pas de Mp pour toi pour le moment, mais j'ai j'ai retrouvé un projet qu'on a évoqué ici il y a peu, un portage MD de Mega Swirl, pour l'heure à l'état de bêta, mais ça pourrait t'intéresser:

https://github.com/ne0ndrag0n/Mega-Swirl

Dans le board.c, tu peux commencer par jeter un oeil au void initBoard()

[philip]

@philip
Tu aurais des sources libres/disponibles contenant ta gestion bas niveau des sprites ?

J'attend une réponse de stef justement sur un petit soucis avec les sprites sur sa dernière version de sgdk, sinon j'ai laissé ce code exemple en 2012 sur le fofo de spritesmind, la partie sprite est valable jusqu'à la version 1.01 je pense.

example plan A&B&sprites:
tilestravaux6_2.zip
http://www.mirari.fr/C5U9

[fourchette]

Merci à tous les deux, je vais regarder ça.