SgdK Megadrive - Démo d'une gestion de YOrder

[Invité]

Coucou,

Longtemps que je voulais me lancer dans la création d'une telle routine sur une Megadrive.
Ne voulant pas trop mettre les mains dans des routines en full ASM, j'ai tenté, avec le Sgdk, de réaliser ça !

Bon bien sûr, c'est pas génial, les cadors du forum trouveront toujours mieux à faire, mais qui ne tente rien n'a rien et à ce propos, ce sont surtout les débutant qui osent poster, à méditer.



Vous pourrez voir dans cette petite vidéo, ce que cela donne.
Ici, le calcul se fait toutes les 30 frames.

Bon alors, comment ça marche ???


Et bien, ayant discuter avec Stef sur cette feature, ce dernier m'a parlé qu'une telle routine serait vraiment un plus, car le Sgdk ne le permet pas.
En fait, la liste est crée au moment de la déclaration :

Code:

Sprites[No1].SpriteA= SPR_addSprite(&Exemple1, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
Sprites[No2].SpriteA= SPR_addSprite(&Exemple1, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
Sprites[No3].SpriteA= SPR_addSprite(&Exemple1, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
Sprites[No4].SpriteA= SPR_addSprite(&Exemple1, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));

Ici, le Sprites[No1] aura le focus sur les 3 autres, le No2 sur les 2 suivants etc ...
On ne peut pas changer la priorité une fois la liste crée, enfin, je n'y suis jamais arrivé même avec l'aide de Stef.

Donc l'idée, est la suivante :
1/ Copier les données essentielles dans un tableau tampon.
2/ Détruire tous les sprites.
3/ Faire le tri Y
4/ Reconstruire la liste de sprite en tenant compte du tri.

On pourra faire appel à cette routine via une tempo programmable : Tempo 

Code:

   while(TRUE)
    {

        Tempo++;
        if (Tempo>30)
        {
            GestionSprite();
            Tempo=0;
        }


        // Affichage Sprite
        for(i=10;i--;)
        {
            RoutineAffichage(i);
        }

        SPR_update();
        VDP_waitVSync();
    }
}

Maintenant, on va voire notre routine :

Code:

void GestionSprite()
{

    u8 TamponID=0;
    fix16 TamponY;

    // Init Traitement
    for(i=0;i<9;i++)
    {
        // On détruit tous nos sprites.
        SPR_releaseSprite(Sprites[i].SpriteA);
        // Init Tableau Tampon
        SpritesTampon[i].ID=i;
        SpritesTampon[i].CoordY=Sprites[i].CoordY;
    }

    // On va effectué le tri Y des 4 premiers sprites
    for (i=0;i<5;i++)
    {
        for (j=i+1;j<5;j++)
        {
                if (SpritesTampon[j].CoordY>=SpritesTampon[i].CoordY)
                {
                    // ID
                    TamponID=SpritesTampon[i].ID;
                    SpritesTampon[i].ID=SpritesTampon[j].ID;
                    SpritesTampon[j].ID=TamponID;
                    // CoordY
                    TamponY=SpritesTampon[i].CoordY;
                    SpritesTampon[i].CoordY=SpritesTampon[j].CoordY;
                    SpritesTampon[j].CoordY=TamponY;
                }
        }
    }

    // Construction liste
    for (i=0;i<5;i++)
    {
        u8 IDZ=SpritesTampon[i].ID;
        if (IDZ==0) Sprites[IDZ].SpriteA= SPR_addSprite(&Exemple1, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
        if (IDZ==1) Sprites[IDZ].SpriteA= SPR_addSprite(&Exemple2, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
        if (IDZ>=2) Sprites[IDZ].SpriteA= SPR_addSprite(&Exemple3, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
    }

    //Ombres
    Sprites[5].SpriteA= SPR_addSprite(&OmbrePapi, Sprites[5].CoordX, Sprites[5].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
    Sprites[6].SpriteA= SPR_addSprite(&OmbrePapi, Sprites[5].CoordX, Sprites[5].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
    Sprites[7].SpriteA= SPR_addSprite(&OmbrePapi, Sprites[5].CoordX, Sprites[5].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
    Sprites[8].SpriteA= SPR_addSprite(&OmbrePapi, Sprites[5].CoordX, Sprites[5].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));

    SPR_update();
}

Dans le cadre de mon exemple, les 5 premiers sprites seront traités, les suivants sont les ombres, donc à afficher en tout dernier sans traitement.
On peut aussi tenir compte de la hauteur d'un sprite ou d'une autre donnée pour le traitement.

On utilise un tableau tampon SpritesTampon pour réaliser le traitement de liste.

Bon ici, cela touche un nombre réduit de sprite, j'ai eu la flemme de faire le test sur un nombre plus important, mais je pense que cela ne serait pas trop préjudiciable.
Il faut doser la tempo en fonction du nombre de sprite.

L'utilisation de pointeurs pourraient aussi faciliter la vitesse de traitement ... Je ne suis pas encore bien familiarisé avec ces concepts.

Le seul défaut, c'est que les animations sont initialisées à chaque appel de routine avec le Sprite Engine.
Il faudra sans doute passer par une gestion d'un plus bas niveau .. A moins que je me sois gouré quelque part !

Donc si la routine peut être améliorer, débugger, ou autre, n'hésitez pas à arranger ça.

Voici le projet complet en .zip
https://www.dropbox.com/s/c6mot08o6wl2kqw/Outil%20Sprite.zip?dl=0

Il y a quelques routines maisons concernant la gestion d'affichage, animation, Pathfinding IA, etc ...
Utile aussi pour les débutants !
J'en utilise quelques unes pour mon Papi Commando Tennis qui gère une trentaine d'éléments sans ralentissements.

A bientôt.

[Tryphon]

Comment est défini ton SpritesTampon ? Je vois pas la déclaration.

C'est quoi exactement ta question ? Tu veux optimiser ça ? Y'a pas mal de choses accélérables mais ce n'est pas simple.

[Invité]

Tout est dans la source complète :
https://www.dropbox.com/s/c6mot08o6wl2kqw/Outil%20Sprite.zip?dl=0

Je ne pose aucune question, je propose une solution qui peut être certainement améliorée.

[Tryphon]

Ah OK.

Y'a plusieurs choses améliorables, mais c'est plus ou moins difficile et parfois on quitte le niveau débutant. J'ai pas trop le temps de m'y atteler pour l'instant mais si je code un jeu en vue de dessus je ferai un topo.

Ce qui me vient à l'esprit :

* l'algo de tri peut être amélioré (il est en n^2, ça veut dire que si tu doubles le nombre d'objets à trier, tu quadruples le temps de tri) ; mieux encore, vu qu'en général on ne fait que permuter deux objets, on doit pouvoir aller beaucoup plus vite en partant du tableau de la frame précédente

* SGDK utilise déjà une table de sprites en RAM, on doit pouvoir la modifier directement. De plus, on peut ne modifier que le link et ne pas toucher au reste ; mais je sais pas à quel point c'est facile en utilisant le Sprite Engine (je ne m'en sers pas)

* y'a des optimisations au niveau code : par exemple c'est plus rapide d'avoir un pointeur sur l'objet courant d'un tableau plutôt que d'accéder à un élément par tableau[i]

Mais tant que ça marche, laisse comme ça

[Tryphon]

Par contre, je me permets juste de rebondir sur ça :

et à ce propos, ce sont surtout les débutant qui osent poster, à méditer.

Je pense que c'est plutôt une question de temps

[Invité]

* SGDK utilise déjà une table de sprites en RAM, on doit pouvoir la modifier directement. De plus, on peut ne modifier que le link et ne pas toucher au reste ; mais je sais pas à quel point c'est facile en utilisant le Sprite Engine (je ne m'en sers pas)

* y'a des optimisations au niveau code : par exemple c'est plus rapide d'avoir un pointeur sur l'objet courant d'un tableau plutôt que d'accéder à un élément par tableau[i]

Coucou,

* Ah ça serait trop cool de pouvoir modifier la priorité d'ordre d'affichage en modifiant juste la table sans avoir à {détruire - reconstruire} !!
Je tâcherai de tester tout ça, quitte à refaire une version 2.0 après !

* Ouiiii le pointeur sur un tableau est plus rapide !! Mais j'ai encore mes habitudes "Basic" ... ^^
D'autant plus qu'en ASM, tu utilise les pointeurs d'adresse sans t'en rendre compte.
Bref, une gymnastique à prendre encore. :)

[Invité]

Vous pourrez voir dans cette petite vidéo, ce que cela donne.
Ici, le calcul se fait toutes les 30 frames.

Perso je trouve le rendu très bon 
J'aurai jamais cru avec 30 frames de délai .

je pense que ça:

2/ Détruire tous les sprites.

C'est inutile, vu que tu le fais lors de la reconstruction de la liste .
Sinon comme le dit tryphon, la MD dispose d'un atout pour les priorités, le link et je pense qu'il faut absolument l'utiliser, car il est fait pour ça .

[Invité]

Merci Touko !!

En fait, j'ai réglé la tempo en fonction du rafraichissement des animations ( mécanique du Sprite Engine et sa méthode en "Streaming" ).

Et non, tu dois détruire tes sprites car à la reconstruction d'une nouvelle, ils sont ajoutés à l'ancienne !

Avec SgdK tu peux jouer avec les priorités Sprites/BG oui, sans aucun soucis !!
Mais concernant les priorités entre Sprite, je ne crois pas que le Sprite Engine ne le permette dixit Stef suite à nos conversations en privé à ce sujet.
Mais vraiment, ça serait GENIAL de pouvoir le faire en jouant juste avec le LINK via l'instruction :

u16	SPR_setSpriteTableIndex (Sprite *sprite, s16 value)
	Set the VDP sprite index to use for this sprite.

A moins que l'on utilise :

void	VDP_setSpriteLink (u16 index, u8 link)
	Set sprite link (use sprite list cache).
VDPSprite *	VDP_linkSprites (u16 index, u16 num)
	Link sprites starting at the specified index. Links are created in simple ascending order (1 --> 2 --> 3 --> ...)

[Invité]

Et non, tu dois détruire tes sprites car à la reconstruction d'une nouvelle, ils sont ajoutés à l'ancienne !

Ah c'est une limite du sprite engine alors !!
C'est bizarre que tu puisses pas lui donner un index de début de table 
et avec spr_set() qui je pense est faite pour modifier un sprite en particulier(donc se positionner dans la table), y'a pas moyen ??

[Tryphon]

Non, c'est pas si bizarre. Un sprite du Sprite Engine, ça peut être formé par plusieurs sprites "hard". La routine update du sprite engine recrée certainement la SAT de 0 à chaque fois, donc l'utilisation du link n'est pas pertinente ici.

Faudrait clairement développer son propre gestionnaire de sprites "hard" (donc limité à 32x32) pour tirer partie du link, ou alors son propre Sprite Engine dans lequel la liste des sprites ne varierait pas d'une frame à l'autre, ce qui provoquerait pas mal de contraintes (toutes les frames d'animation auraient la même taille).

C'est un problème intéressant.

[Hpman]

Si le SE refait la sprite table à chaque frame, on doit pouvoir faire un Z-order en manipulant la table activeSprites et les status flag des sprites non ?

[Invité]

On attend les conseils de Stef !!
En tout cas, discussion intéressante.

[Stef]

Merci Vetea d'avoir partagé ton code :) En effet il n'y a psa encore de fonction dans le Sprite Engine de SGDK pour trier facilement les sprites sur le Y order, ce qui est dommage car c'est quelque chose qu'on souhaite souvent avoir... Ta méthode, même si elle n'est pas la plus rapide a le mérite de fonctionner et d'autres pourront en profiter, surtout que ce n'est pas un truc vraiment trivial !


Sinon oui SGDK utilise déjà une table de pointer pour les sprites en interne, justement en prévisoin de permettre le tri (et Y sorting en autre). Dans sprite_eng.c on a ça :

Code:

// active sprites list, we use an array of pointer to allow sorting
// [0..(visibleSpriteNum-1)] = visible sprites
// [visibleSpriteNum..(spriteNum-1)] = not visible sprites
Sprite **activeSprites;
// number of active sprite
u16 spriteNum;

Je les ai pas mis en static pour qu'on puisse y accéder directement de l'extérieur. Mais en réalité ce n'est pas si simple : si on modifie l'ordre de la liste il faut également veiller à reconstruire correctement les champs link entre les différents sprites (en s'inspirant de ce que fait la méthode SPR_release(..) qui doit refaire les liens après la suppression d'un sprite).
Aussi j'ai ajouté une méthode générique de comparaison type quicksort dans SGDK il y a peu :

Code:

void qsort(void** data, u16 len, _comparatorCallback* cb);

Avec un callback pour définir la méthode de tri. Alors c'est très pratique mais c'est tout sauf quicksort
Faudrait que j'utilise un autre algo que quicksort qui peut être terriblement long dans le cas d'une liste quasiment déjà triée par exemple (ce qui est un comble) ^^
J'espère ajouter une vrai fonctionnalité de tri des sprites dans la prochaine version de SGDK avec même peut être un Y sorting activable de base.

Edit:
Je n'avais pas lu tout les messages mais je complète donc..
L'ancien Sprite Engine reconstruisait la SAT à chaque SPR_update(..), ce n'est plus le cas avec le nouveau SE qui tente de la reconstruire partiellement ou quand c'est nécessaire. Du coup le link peut être utilisé mais bien sûr vu que le SE permet l'utilisation de meta sprite on doit modifier le link du dernier hard sprite du meta sprite (j'ai un pointeur interne qui va directement dessus). En regardant le code de SPR_release(..) on peut mieux comprendre comment ça fonctionne mais ce n'est pas toujours très trivial. Je trouve le code du SE assez complexe (et donc lourd) pourtant je l'ai déjà réécrit une fois pour essayer de le garder assez simple :-(

[Hpman]

Y'a un papier quelque part qui explique comment tourne SE ou faut se farcir tout le code? 

[Invité]

Merci Stef pour ces précisions.
Ma méthode va être améliorée avec l'ul'utilisation de pointeur sur mes tableaux pour un traitement plus rapide.
Le seul gros hic, c'est que les animations sont resetées a chaque fois, le streaming est réinitialisé. 
Une fois que j'aurai résolu ça, j'aurai ma routine maison pleinement fonctionnelle.
Je pourrai ll'utiliser sur Papi Tennis et d'autres futurs projets.

Le principal, cc'est que le concept de base fonctionne !!

[Invité]

Coucou,

Voila, j'ai utilisé mes jolis pointeurs associés à mes tableaux ( qui sont des structures ! ), avec un peu de difficulté pour lancer la machine cérébrale ... 
Le déclic est venu grâce à mes souvenirs en ASM avec l'utilisation des pointeurs d'adresses a0-a7 que j'avais pu faire.

Bref, ça fonctionne !!

Code:

void GestionSprite()
{

    u8 TamponID=0;
    fix16 TamponY;
    u8 *id=&SpritesTampon[0].ID;
    fix16 *CY=&SpritesTampon[0].CoordY;

    // Init Traitement
    for(i=0;i<9;i++)
    {
        // On détruit tous nos sprites.
        SPR_releaseSprite(Sprites[i].SpriteA);
        // Init Tableau Tampon
        *(id+i)=i;
        *(CY+i)=Sprites[i].CoordY;
    }

    // On va effectué le tri Y des 4 premiers sprites
    for (i=0;i<5;i++)
    {
        for (j=i+1;j<5;j++)
        {
                if (*(CY+j)>=*(CY+i))
                {
                    // ID
                    TamponID=*(id+i);
                    *(id+i)=*(id+j);
                    *(id+j)=TamponID;
                    // CoordY
                    TamponY=*(CY+i);
                    *(CY+i)=*(CY+j);
                    *(CY+j)=TamponY;
                }
        }
    }

    // Construction liste
    for (i=0;i<5;i++)
    {
        u8 IDZ=*(id+i);
        if (IDZ==0) Sprites[IDZ].SpriteA= SPR_addSprite(&Exemple1, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
        if (IDZ==1) Sprites[IDZ].SpriteA= SPR_addSprite(&Exemple2, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
        if (IDZ>=2) Sprites[IDZ].SpriteA= SPR_addSprite(&Exemple3, Sprites[0].CoordX, Sprites[0].CoordY, TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
    }

    //Ombres
    Sprites[5].SpriteA= SPR_addSprite(&OmbrePapi, Sprites[5].CoordX, Sprites[5].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
    Sprites[6].SpriteA= SPR_addSprite(&OmbrePapi, Sprites[5].CoordX, Sprites[5].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
    Sprites[7].SpriteA= SPR_addSprite(&OmbrePapi, Sprites[5].CoordX, Sprites[5].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
    Sprites[8].SpriteA= SPR_addSprite(&OmbrePapi, Sprites[5].CoordX, Sprites[5].CoordY, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));

}

Je suis carrément heureux d'avoir pu utiliser mes premiers pointeurs sur ce format là !
Si j'ai fait une grosse connerie, n'hésitez pas à me corriger.

Par contre, je n'ai toujours pas résolu ce problème d'initialisation d'animation.
Si la tempo de traitement est faible, on se retrouve avec des sprites pratiquement sans animation !   

Je crains qu'avec cette routine, il me faille utiliser les routines sprites de bas niveau ...

[Invité]

Tu fais aussi du tri sur les ombres ??

[Invité]

Nonnnn !!  
Si tu regardes bien le code, je ne traite que les éléments nécessitant le traitement.
Les ombres ne sont pas traitées, et leur liste est crée en dernier.

[Invité]

ok, parce que je voyais pas l'intérêt visuellement parlant, mais apparemment toi non plus  

[Stef]

Y'a un papier quelque part qui explique comment tourne SE ou faut se farcir tout le code? 

Hélas il faut se farcir le code :-/
Mais j'aurais du effectivement faire une doc explicative, ça m'aurait grandement servie aussi
A la base j'avais une idée assez claire et simple du sprite engine mais au fur et à mesure le code s'est complexifié et parfois j'arrive à me perdre un peu dedans
Quand j'aurai le temps j'essaierai de poser ça à plat et d'écrire une doc pour comprendre son fonctionnement (le reste du SDK est relativement simple, seul le sprite engine a besoin de ça je pense).

[Invité]

Ça serait genial Stef !!!
Franchement ma solution fonctionne mais reset les animations au moment de l'appel de la routine puisque on detruit et recréer une nouvelle table de sprite.
C'est dommage mais en faisant des appels programmés a des moments clés, ça passe.
J'essaierai d'intégrer la routine avec Papi Tennis. Je vous tiendrai au courant.

En tout cas, post utile.

Prévoir un autre pour une routine de rotation des Tiles/Sprites ...

[Hpman]

Y'a un papier quelque part qui explique comment tourne SE ou faut se farcir tout le code? 

Hélas il faut se farcir le code :-/
Mais j'aurais du effectivement faire une doc explicative, ça m'aurait grandement servie aussi
A la base j'avais une idée assez claire et simple du sprite engine mais au fur et à mesure le code s'est complexifié et parfois j'arrive à me perdre un peu dedans
Quand j'aurai le temps j'essaierai de poser ça à plat et d'écrire une doc pour comprendre son fonctionnement (le reste du SDK est relativement simple, seul le sprite engine a besoin de ça je pense).

Ah c'est dommage, vu de l’extérieur ça à l'air bidouillable en triant la liste de sprite et magouillant quelques flags, mais je sent qu'on casse tout si on fait que ça 

[Invité]

Coucou tout le monde,

J'ai totalement revu mon code d'origine !

Cette fois ci, je peux créer facilement une liste de Sprites avec :
- ID
- Coordonnées {X,Y} Aléatoires.
- Vitesses.
- Directions.

Pour l'algorithme de traitement, j'utilise des pointeurs pour chaque ID & Coordonnées Y.

Dans l'exemple ci dessous, je traite 16 sprites { Sprites & leurs ombres } simultanément.
( Au dela de 16, lors du traitement, ça plante et tout l'écran glitche. )



Comme vous le voyez, la rapidité est au rendez vous et ça file nickel !

A bientôt !

Rappel :
Le lien du projet se trouve dans le premier message !!

[philip]

Merci pour le partage, et avec les ombres c'est fortiche quand même.

( même si je pense ne jamais me lancer dans un jeu en vu de dessus), je vais  télécharger ton fichier pour essayer de comprendre ce sprite engine, un jour, peut-être... hum.

Pour la limite à 16 sprites, avec un bug méchant, c'est étrange, peutêtre une sortie de liste ou de tableau ?...

[Invité]

Merci Philip.
Oui un jeu de dessus, c'est une approche particulière. Faudra d'ailleurs que je me lance sur de la 2D de côté, pour réaliser un jeu de plateforme, beat'm'all, ...
Quant à ce bug, ça vient de la destruction/reconstruction de la table. 
Le traitement de l'algorithme ne fait rien planter si on vire le traitement de la table.

[Invité]

Bonsoir à tous,

Je viens de plancher sur une variante pour éviter le chevauchement des sprites gérés par l'IA.
Il s'agit d'un algorithme de Pathfinding qui va traiter pour chaque unité sa distance relative par rapport à toutes les autres.
Si cette distance est inférieure à une certaine valeur ( ici 32 px ), alors celui ci va choisir la meilleure direction à prendre, c'est à dire, une direction sans qu'une autre unité vienne empiéter sur sa future trajectoire.

Dans cette vidéo, il y a 20 objets de traités ( ombres comprises ) !
En jouant avec la tempo de traitement de l'algorithme on peut aisément pousser le nombre à plus.


Le terrain fait 320x224 px

Comme vous pouvez le voir, le résultat est vraiment marrant à voir !!
Et tout ça sur un simple 68000 !!  
Ca sert à pas grand chose, mais j'aime bien me casser la tête avec ces algorithmes d'IA. 

A bientôt !

[Stef]

Haha, bien joué, c'est très marrant cette démo et ça tourne très bien
Je sais pas si tu calcules tes collisions toutes les X frames ou si tu découpes le calcul sur X frames. Le 2eme cas serait encore plus efficace : si tu as 20 sprites, tu calcules la collision pour 2 sprites à chaque frame, ainsi en 10 frames tu as calculé les collisions pour tout les sprites et ça réparti la charge équitablement sur toutes les frames. Beaucoup de jeux où la dynamique est assez lente font ça :)

[Invité]

Merci Stef !!
Ouiiii excellente idée !!
En fait je passe tous mes sprites en revue toutes les X frames, mais ton idée est excellente, 65c02 m'en avait parlé d'ailleurs.

[Invité]

Ca sert à pas grand chose, mais j'aime bien me casser la tête avec ces algorithmes d'IA.   

Bravo, ça marche super bien, et puis c'est le genre d'algo qui peut facilement être utile dans un jeu(PPC 2 ??) , donc non c'est pas pour rien .

[Invité]

Merci Touko !
Oui, l'algo est utilisable partout ( comme tout bon algo ^^ ), mais peut être encore optimisé.
Je diffuserai la source en rentrant chez moi.

Et puis, pourquoi pas, le retranscrire en 100% ASM 68000 !!!
CA serait un super exercice, mais je ne sais pas comment intégrer une fonction pur ASM dans un projet en C avec SgdK.