Re: Sgdk - Sega Megadrive / Genesis Development Kit

[tetsuro]

Je ne sais pas si c'est ça mais déjà il faut mettre :

Code:

#include <genesis.h>

Et c'est :

Code:

return 0;

Certains compilateurs aiment :

Code:

int main(void)

Perso je trouves Code::Blocks plus simple que ton affaire de compiler en lignes de commandes :)

[drfloyd]

qu'est ce que c'est chiant vos langages

Venez sur Bex, Blitz ou QB64

[Invité]

Oui je sais Tetsuro, mais j'ai pas réussi à compiler quoique ce soit avec CodeBlocks ...


Demain je m'y remettrai à tête reposée.
C'est pas si compliqué ... Dernièrement je suis assez fatigué et tendance à m'énerver trés facilement, dieu que les sports de combat me manquent ... Heureusement, j'ai mes haltères.


Si tu as le temps, vu que tu m'as l'air d'être une personne posée, réfléchie et trés sympa, pourrais tu en MP, me donner la manière dont tu as pu paramétrer CodeBlocks et ensuite pu compiler et créer un .Bin ?
Ca serait super sympa ... Merci d'avance copain. :)

[tetsuro]

d'accord, t'es sur quel Windows ?

[Invité]

Windows 8.1 version Pro.


Ca ne presse pas ... J'ai tout mon temps. :)

[tetsuro]

D'accord je vais te faire un petit tuto, je trouves que si tu veux faire du C plus tard Code::Blocks est parfait car multiplateformes, mis à jour régulièrement, et tu sera inévitablement confronté à lui pour divers tutos C, SDL, SDGK, etc.. dans le future. Le plaisir de coder sous Code::Blocks avec SDGK en vaut la peine, enfin c'est mon point de vue et mon utilisation.

[Invité]

Merci beaucoup.
En fait, j'ai commencé avec le Basic dès 1980, aprés un petit peu d'Assembleur sur mon CPC avec du Z80 ( LDA X, etc ... ), aprés du Pascal et du C en Faculté.
Par la suite, j'ai poursuivi avec Visual Basic 6 pour mes tous premiers jeux PC ... et aprés .... QB64 et ensuite ... BasiegaXorz sur Megadrive ( et accessoirement un TOUT petit peu d'assembleur 68K ).


Voila en gros mon "CV" !

[tetsuro]

Pour les variables d'environnements  : 

1 - Dans Rechercher, lance une recherche et sélectionne : Système (Panneau de configuration)
2 - Clique sur le lien Paramètres système avancés.
3 - Clique sur Variables d'environnement.
4 - Dans la section variable utilisateur, tu fais "Nouvelle" et tu entres (bien sur tu mets ton propre chemin d'où tu as dézippé ton sdgk) :

Nom de variable : GDK
Valeur de la variable : C:/Users/Habri/Desktop/Prog/Megadrive/sgdk112

5 - OK
6 - Dans la section variable utilisateur, tu fais encore "Nouvelle" et tu entres :

Nom de variable : GDK_WIN
Valeur de la variable : C:\Users\Habri\Desktop\Prog\Megadrive\sgdk112

Ensuite dans Code::Blocks les configurations à remplir :

Tu vas à :
Settings > Compiler > Onglet "Toolchain executables" tu mets les mêmes paramètres que sur mon screen :



A partir de là tu es censé pouvoir compiler ton Hello World  qui va générer la rom.bin qui se trouvera dans ton dossier de projet, dans un dossier out généré par la compilation.

Dernière petite manipulation cerise sur la gâteau, une fois que tu aura bien vu que tout fonction, la manipulation suivante va te créer un template, comme ça quand tu voudra créer d'autres projets MD plus tard tu n'aura plus qu'à sélectionner ce template qui ouvrira un projet déjà tout prêt à compiler pour la MD et avec le code minimal que tu désire.

Donc une fois que ta compilation fonctionne et que tu aura décidé du code minimal à laisser dans ton main.c tu fais :
1 - File > Save Projetc as Template...
2 - Tu entres le nom que tu désire pour ton template moi c'est "Megadrive" et OK.

Pour ré-ouvrir ton template, à l'ouverture de Code::blocks tu fais :
1 - Create a new project sur la fenêtre principale
2 - Une fenêtre s'ouvre tu as un menu à gauche avec "users templates"
3 - Tu sélectionne ton template et Go.

NB: La manipulation que te donne Stef plus bas n'est pas pour Code::Blocks...

Je laisse ici plutôt qu'en MP, si ça peut aider d'autres

[Invité]

En faite pour bien configurer Code::Block il faut savoir utiliser GCC

[Stef]

Les variables d'environnement c'est important, ne pas les oublier !
Ensuite il faut executer cette commande pour compiler ton projet :

Code:

%GDK_WIN%\bin\make -f %GDK_WIN%\makefle.gen

Tout en étant dans le répertoire de ton projet.
Et normalement ca te sort un fichier rom.bin en sorti si tout se passe bien =)

[dub]

Bonsoir,

J'ai donc tapé le code d'un Hello World :

Sous NotePad++ :

#include
// Ici j'ai spécifié le chemin de la librairie à utiliser ...


int main()
{
    VDP_drawText("Hello Genny World!", 10, 13);

    while(1)
    {
        //read input
        //move sprite
        //update score
        //draw current screen (logo, start screen, settings, game, gameover, credits...)

        //wait for screen refresh
        VDP_waitVSync();
    }
    return (0);
}

Déjà, as-tu compilé le sgdk pour que ça marche suivant le tuto de Stef ?

Après, tu peux pas lancer la compil comme ça.

Tu laisses "#include " tel quel sans chemin et c'est dans le makefile que tu indiques les chemins.

Je te donne le projet qui marche, je t'ai mis les bons chemins d'après tes infos, tu n'as qu'a lancer le batch make_md.bat

C'est pas le plus pro, mais ça marche sans que tu ajoutes des variables d'environnement.

https://dl.dropboxusercontent.com/u/27435968/hello2.zip

C'est le makefile "makefile.gen" qui gère les besoins en compilation.
Après suivant le version du sgdk que tu utilises, certaines lignes dans mon code sont pas obligatoire.

le batch :

Code:

SET GDK=C:/sgdk
SET GDK_WIN=C:\sgdk
SET PATH=%PATH%;%GDK_WIN%\bin

rm out/*.bin
rm out/*.out
rm out/*.o
rm out/src/*.o

%GDK_WIN%\bin\make -f %GDK_WIN%\makefile.gen
pause


Et Notepad++, c'est top


:oops:Oups, j'avais pas ouvert la dernière page avec les réponses ... Bon, moi je passe en mode bourrin en déclarant mes variables à l'arrache mais comme je change d'ordis tous les temps.

[Stef]

Non mais ta solution est très bien dub, ainsi tu n'as même pas besoin de déclarer les variables d'environnement à l'avance

[Invité]

Merci beaucoup Dub pour ton aide.
Je regarderai ta source chez moi â tête reposée. :)

[Invité]

Une foi que tu arrives à compiler correctement un exemple qui fonctionne, tu peux passer à l'intégration de code blocks,si np++ ne te plait pas .

Et Notepad++, c'est top 

Perso j'ai rajouté la police dina qui aide à la lisibilité du code .

[ichigobankai]

les familles de fonts type courrier (aka police à chasse fixe / monospace) sont parfaites (voir essentielles ?) pour coder, histoire d'avoir les données bien alignées.

Après on peut coder en Gothic ou Comic Sans MS pour ceux qui aiment ^^

[philip]

@vetea
Dans le dossier apps (sur ta partition C) tu décompresse sgdk dans le dossier gendev. 

Il faut configurer 2 variables d'environnement :

GDK
C:/apps/gendev

Et la deuxième dans variable système :

GDK_WIN
C:\apps\gendev

Attention à l'anti slash pour cette dernière.

[Top l'âne]

Coucou, je m'en viens soumettre une petite curiosité.

Je bosse sur de l'affichage.

J'ai un PNG source de 8x112pix, soit exactement une colonne de 14 tiles, pour du background.

Je le passe par rescomp pour obtenir une structure IMAGE.

Je charge le tileset avec un VDP_loadTileSet();
Puis j'affiche avec un VDP_fillTileMapRectInc();

Et très curieusement, les deux dernières tiles de ma colonne refusent de s'afficher. (code vierge pour le test, aucune interférence possible)

Je fais une autre essai, cette fois je passe par Rescomp pour créer deux structures distinctes à partir de ce même PNG. Un TILESET et une PALETTE.

Même procédé.
VDP_loadTileSet();
VDP_fillTileMapRectInc();

J'ai bien l'affichage complet de mes 14 tiles.


Une explication à ce mystère?
Globalement, y a t'il nécessité d'observer des dimensions particulières de tilesets pour optimiser le travail?
Concrètement et pour l'exemple, si j'ai une source de 16x8tiles, ai-je un intérêt à fragmenter cette image en 8 images de 4x4tiles?

[dub]

C'est bizarre, chez moi ça passe. Je sais que ça aide pas

Mon code :

Code:

VDP_loadTileSet(bga_barre.tileset,ind,0);
VDP_fillTileMapRectInc(PLAN_A, TILE_ATTR_FULL(PAL1, FALSE, FALSE, FALSE, ind), 1, 1, 1, 14);


IMAGE bga_barre "gfx/barre.png" 0


Tu peux faire un screen de ton vdp ?

[Stef]

Vous savez qu'il y a des fonctions de plus haut niveau ? :) Genre :

Code:

VDP_drawImage(PLAN_A, bga_barre, 0, 0);

Et si tu comptes afficher la barre plusieurs fois ,dans ce cas il faut effectivement charger le tileset avant (pour ne pas le charger plusieurs fois en VRAM):

Code:

// ind pointe sur le premier SLOT VRAM user
ind = TILE_USER_INDEX;
VDP_loadTileSet(bga_barre.tileset, ind, 0);
VDP_setMap(VDP_PLAN_A, bga_barre.map, TILE_ATTR_FULL(PAL1,
   FALSE, FALSE, FALSE, ind, 0, 0);
// on pointe sur le prochain slot VRAM libre
ind += bga_barre.tileset->numTile;

Sinon pour répondre à ça :

Une explication à ce mystère?
Globalement, y a t'il nécessité d'observer des dimensions particulières de tilesets pour optimiser le travail?
Concrètement et pour l'exemple, si j'ai une source de 16x8tiles, ai-je un intérêt à fragmenter cette image en 8 images de 4x4tiles?

Normalement rescomp optimise ton image pour toi, s'il y a des tiles répétés ou flippés la structure image générée va en tenir compte. Le plus simple c'est de donner une grosse image PNG à rescomp que tu définis en ressource IMAGE et ensuite tu joues avec les fonctions VDP_loadTileSet(..) et VDP_setMap() voire VDP_setMapEx(..) =)

[Top l'âne]

Merci les amis.

Dub, mon code est identique au tiens, à ceci près que je valide une compression auto dans le rescomp (-1).

Et pour reprendre Stef, les deux tiles qui ne s'affichent pas sont justement des doublons d'une des tiles du schéma.
(les tiles 13 et 14 devraient être identiques à la tile 12).

@Stef, effectivement j'ai laissé de côté le drawImage(); par choix.
Disons que c'est plus clair pour moi de clairement découper le boulot (chargement/affichage).
Pour tout dire, dans la même optique, j'avais même dans l'idée d'exploiter le VDP_Sprite, plutôt que le Sprite_Engine... Mais bon faudrait quand même que ça avance cette affaire.^^

Ceci dit, je ne me suis encore jamais penché sur les VDP_setMap(), puisque tu le suggères, je vais m'y attarder.

je n'ai pas eu le temps de revenir sur ce phénomène hier soir, attendu que je me bagarre avec un autre bug autrement ennuyeux et avec lequel je sens qu'il va falloir que je vous tanne.

Brièvement, j'ai un écran titre qui envoie le stage en pressant Start.
Depuis le stage, je retourne l'écran titre en pressant A.
Je me suis aperçu qu'en effectuant quelques switchs de la sorte, le programme plante.

J'ai commenté la quasi intégralité de mon code en ne laissant que ces deux écrans et les contrôles.
(parfait ça tourne)
Puis je remets les process en marche au coup par coup pour isoler le problème.
Et, là, stupeur, le simple fait de déclarer mes variables dans la source du stage entraine le plantage.
Concrètement je déclare ce genre de trucs:

des structures:
Sprite sprite[31];
SpriteData spriteData[31];

des flottants:
fix32 tile_scroll_data[28] = {0};

Rien de fabuleux me semble t'il.
Vu le peu de code encore actif à cet instant, j'ai dans l'idée que ma programmation modulaire est peut être en cause.
Des directives de préprocesseur mal agencées pourraient elles avoir ce genre de conséquence pensez-vous?
(en l'état, 4 .c et les .h respectifs c'est pas la démence non plus et il me semblait avoir été aussi carré que possible)

[Top l'âne]

Vu le peu de code encore actif à cet instant, j'ai dans l'idée que ma programmation modulaire est peut être en cause.
Des directives de préprocesseur mal agencées pourraient elles avoir ce genre de conséquence pensez-vous?

Donc non... Puisque je viens de coller l'intégralité de mon code dans un main.c pour voir, et ça tourne exactement de la même manière. :p

[dub]

Si tu peut mettre que le bout de code "simple"  avec les variables qui plantent. On pourrait tester et voir si on trouve le problème.

[65c02]

tu peux avoir l'adresse de ta variable ?
ce serait bien de vérifier qu'elle est en ram et pas en rom

[Stef]

S'il code en C y'a peu de chance que ça vienne de là :p

Kane> Tu les déclares en global tes structures sprites ou localement dans des fonctions ? car 31 Sprites + 31 SpriteData (je ne sais pas ce que tu mets dedans), ça fait peut être gros pour de l'allocation sur la pile (de mémoire SGDK réserve 2 KB pour la pile) et tet que tu écrases une variable qui empiète dedans...

[Top l'âne]

J'ai essayé de les poser en global aussi. Dans ce cas le bug survient plus tardivement... Mais quand même.^^

Mon SpriteData n'est pas énorme pour l'instant.

Voilà, je vous laisse le code que j'ai synthétisé dans un unique main.c avec quelques exemples de déclaration en commentaire qui suscitent le bug:

#include
#include "resources.h"


typedef struct BoundingBox BoundingBox;

typedef struct BoundingBox
{
    fix32 x;
    fix32 y;
    s16 w;
    s16 h;
};

typedef struct SpriteData SpriteData;

typedef struct SpriteData
{
    fix32 posx;
    fix32 posy;
    fix32 movx;
    fix32 movy;
    s8 state;
};



void titleScreen(u16 window);
void mainGame(u16 window);


int main()
{

    JOY_init();


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

    titleScreen(WPLAN);

    return 0;
}



void titleScreen(u16 window)
{


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

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

   
    while(TRUE)
    {
        if(JOY_readJoypad(JOY_1) & (BUTTON_START))
        {
            VDP_resetScreen();
            VDP_init();

            mainGame(WINDOW);
         
        }

        VDP_waitVSync();
    }



}


void mainGame(u16 window)
{



    u16 i = 0, j = 0;
    u16 timer1 = 0;

    s8 xorder = 0, yorder = 0, attackOrder = 0, timerOrder = 0;

   //Sprite sprite[31];
   //fix32 tab[20];
   //SpriteData spriteData[31];


    VDP_drawText("GAME", 10, 10);


 

    while(TRUE)
    {

     if(JOY_readJoypad(JOY_1) & (BUTTON_A))
        {
           
            VDP_init();

           
            titleScreen(WPLAN);
        }

    VDP_waitVSync();


          
    }





}

[Stef]

Y'a un petit problème de design dans ton code... En gros ce que tu fais ça marche en assembleur en faisant des jmp, mais là en C les appels de fonction (ainsi que les arguments et les variables locales) s'empilent sur la pile, du coup si tu t'amuses à faire beaucoup d'échange entre titleScreen et mainGame, tu vas exploser ta pile. La vitesse à laquelle ça arrive dépends directement du nombre de variable locales que tu déclares dans les dites fonctions... j'imagine qu'avec tes tableaux de Sprite ça devait exploser très vite ! Là il y a beaucoup moins de variables du coup il faut surement pas mal d'échanges avec de constater le problème.

[philip]

@CK
Il vaut mieux utiliser un seul while(1) au démarrage de ta boucle principale :

Code:

#include <genesis.h>

// et autres fichiers .h



int main( )
{

// déclaration variables entre autre chose

    u16 value; // pour le joypad

    u16 datest;u16 dbtest; // variable de test debug
    u16 lcha;u16 lchb;u16 lchc;
    u16 lchstart;




    // ************************************************************************************************************************************************************
    // ***** Boucle principale ************************************************************************************************************************************
    // ************************************************************************************************************************************************************

    //if (value & BUTTON_UP)
    //if (value & BUTTON_DOWN)
    //if (value & BUTTON_LEFT)
    //if (value & BUTTON_RIGHT)
    //if (value & BUTTON_A)
    //if (value & BUTTON_B)
    //if (value & BUTTON_C)

while(1)
 {

    value = JOY_readJoypad(JOY_1); // valeur du joypad joueur 1

    if (lcha==1)
        {
        if (!(value & BUTTON_A))
            {
            lcha=0;
            }
        }
    if (lchb==1)
        {
        if (!(value & BUTTON_B))
            {
            lchb=0;
            }
        }
    if (lchc==1)
        {
        if (!(value & BUTTON_C))
            {
            lchc=0;
            }
        }




 VDP_updateSprites(highestVDPSpriteIndex, TRUE);
 VDP_waitVSync();


    // ************************************************************
    // ************************************************************
    // Score :



 }
 return 0;
}

[dub]

Y'a un petit problème de design dans ton code... En gros ce que tu fais ça marche en assembleur en faisant des jmp, mais là en C les appels de fonction (ainsi que les arguments et les variables locales) s'empilent sur la pile, du coup si tu t'amuses à faire beaucoup d'échange entre titleScreen et mainGame, tu vas exploser ta pile. La vitesse à laquelle ça arrive dépends directement du nombre de variable locales que tu déclares dans les dites fonctions... j'imagine qu'avec tes tableaux de Sprite ça devait exploser très vite ! Là il y a beaucoup moins de variables du coup il faut surement pas mal d'échanges avec de constater le problème.

Quand tu parles d'empilage, tu veux parler du fait qu'il appel la même fonction à l'intérieur de celle-ci à l'infinie :

Code:


titleScreen(){
   var local
   mainScreen(){
      titleScreen(){
      ajout des même var local
         mainScreen(){
             ....
         }
      }
   }

}


Dans ce cas, comme dit philip. 1 boucle while avec des sous functions (et une boucle while dedans si on veut y rester).

[Top l'âne]

Ah... Merci infiniment les gars.

Je pense avoir bien saisi le fond du problème, je vais donc revoir mon approche avec l'aide de vos tuyaux.

J'étais un peu charrette hier soir en venant poster mon code, je n'ai pas relevé cette notion de "pile" mais j'aimerai bien quelques précisions sur le sujet.

[philip]

Il vaut mieux déclarer tes variables, mais aussi tes procédures (avec éventuellement des variables locales si besoin) avant la boucle principale.
exemple:

Code:

    static void newobjets(u16 id, u16 etat, u16 memrx, u16 x,u16 y, u16 nb)
    {
    moburbs[nb].id = id;
    moburbs[nb].x = x;
    moburbs[nb].y = y;
    moburbs[nb].etat = etat;

    }



    #include <asectionit.h>
    #include <asection21.h>





    // ************************************************************************************************************************************************************
    // ***** Boucle principale ************************************************************************************************************************************
    // ************************************************************************************************************************************************************

    //if (value & BUTTON_UP)
    //if (value & BUTTON_DOWN)
    //if (value & BUTTON_LEFT)
    //if (value & BUTTON_RIGHT)
    //if (value & BUTTON_A)
    //if (value & BUTTON_B)
    //if (value & BUTTON_C)

while(1)

[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.