Re: Sgdk - Sega Megadrive / Genesis Development Kit

[F.L]

Oui t'inquiete, c'est juste un probleme de synthaxe, la logique est la meme!
Et puis quand on a dompté  bex, on peut tout faire 

[Invité]

Si j'y arrive, si j'arrive a refondre mon code de Papi Tennis avec Sgdk en C, alors je pourrai mourir tranquille.
Et oui Bex est très loin d'être simple ... Le Basic affiché est juste un leurre.

[Invité]

Gens KMod est très pratique pour ses fonctionnalités de debugging, mais il ajoute quelque bug facheux qui n'étaient pas présents dans la version d'origine, 

Oui par exemple comix zone merde dés qu'on lance le jeu,l'intro fonctionne .

Mais il est très pratique pour comprendre comment certains effets ont été fait ou voir pas mal de choses sur le VDP ..
Il se lance aussi plus vite que gens 

Etant donner que j'ai commencé à trifouiller le Hardware de la MD avec le l'assembleur 68000, ça devrait aller.
Par contre j'ai toujours un blocage mental avec le C, la feuille blanche à ne pas savoir que mettre, bref des verrous à débloquer et c'est ça pour moi le plus dur. 

Tu peux essayer de faire des trucs simples en basic, et les convertir en C dans la foulée .
exemple afficher du texte, un sprite,un fond,etc ..

[Invité]

Et voilà, je suis officiellement un utilisateur de Sgdk !!

J'Avais posé quelques questions bateaux à Stef en PM, autant en faire profiter la communauté :

1/ Peut on intégrer du code Asm dans le listing C et donc inclure des petites routines maison ? Et comment ?
2/ Peut on définir manuellement ses 4 palettes ?
3/ Peut on declarer ses Tiles/Sprites manuellement ( comme en asm/bex ) et les charger par la suite a la volee via une adresse Vram ?

VVoilà c'est tout pour le moment.

[Stef]

Tu as raison ! Du coup je copie/colle ici (en remettant les questions dans le même ordre) :

1) Oui tu peux mélanger ASM et C, tu peux regarder le code source de l'unité 'joy' pour voir la syntaxe (cherche le mot clé 'asm'):
https://github.com/Stephane-D/SGDK/blob/master/src/joy.c

Mais la syntaxe est complexe si tu souhaites accéder à tes variables C depuis l'assembleur inline.
Je te conseille plutot de séparer ton code C de ton code assembleur. Des fichiers .c pour le code C et des fichiers .s pour le code assembleur. Là encore tu peux regarder dans le code source de SGDK pour t'inspirer et voir comment c'est fait. Un exemple avec maths3D :
https://github.com/Stephane-D/SGDK/blob/master/src/maths3D_a.s


2) Oui bien sur :)
Mais avant de répondre je vais t'expliquer un peu comment est structuré SGDK :
La librairie est découpée en plusieurs unités, chacune d'elle est dédiée à une tâche en particulier.
Par exemple toutes les unités 'vdp_xxx' gère tout ce qui se rapporte au VDP (processeur vidéo).

Pour les palettes tu as donc l'unité vdp_pal, la partie déclaration se trouve toujours dans le fichier .h :
https://github.com/Stephane-D/SGDK/blob/master/inc/vdp_pal.h

Ca te permet de voir les fonctions existantes d'une unité et surtout leur documentation (au format doxygen).
Il est donc important de scruter ces fameux fichiers .h (dans le répertoire 'inc' de SGDK) pour voir toutes les fonctions et la documentations associée =)

Normalement quand tu télécharges SGDK, tu as un répertoire 'doc' qui correspond à la documentation au format HTML.
Tu peux ainsi la garder ouverte quand tu codes ! Mais le top c'est encore de paramétrer correctement code::blocks pour qu'elle apparaisse automatiquement quand tu codes

J'en reviens donc à ces palettes :
Si tu regardes le contenu du fichier vdp_pal.h tu verras la fonction suivante :

Code:

VDP_setPaletteColor(u16 index, u16 value);

Qui permet de redéfinir une couleur parmi les 64 (4 palettes de 16 couleurs).
Si tu veux redéfinir la couleur 3 de la palette 0 :

Code:

VDP_setPaletteColor((0*16) + 3, RGB24_TO_VDPCOLOR(0xF0F0F0));

Si tu veux redéfinir la couleur 7 de la palette 2 :

Code:

VDP_setPaletteColor((2*16) + 7, RGB24_TO_VDPCOLOR(0x808080));

Le RGB24_TO_VDPCOLOR c'est une petite macro / fonction qui permet de transformer une couleur RGB888 (format classique, photoshop etc...) en RGB333 (format MD).


Bien sur tu peux aussi utiliser ces fonctions pour définir plusieurs couleurs ou une palette d'un coup avec un tableau de valeurs :

Code:

void VDP_setPaletteColors(u16 index, u16* values, u16 count);
void VDP_setPalette(u16 num, u16 *pal);

3) Tu peux le faire oui mais très honnêtement c'est vraiment pas pratique de faire ainsi.
Je te conseille de rapidement passer par 'rescomp' (le compilateur de ressource) qui à partir d'une image PNG sera capable de te générer une structure 'Image' qui sera bien plus pratique à utiliser dans SGDK via des fonctions de plus haut niveau. Il y a un fichier 'rescomp.txt' dans le répertoire 'bin' de SGDK qui explique comment fonctionne rescomp, le type de ressource qu'il supporte... :)

Sinon l'équivalent des DC.L en C c'est juste un tableau de u32 soit :

Code:

u32 data[] = {
   0x12345678, 0x87654321, 0x00000000n 0xFFFFFFFF
};

On utilise '0x' plutot que '$' en C pour dire que tu donnes une valeur hexadecimale.
Le problème de faire ainsi est que tu devras utiliser des méthodes de plus bas niveau pour charger tes données graphisques en mémoire vidéo, mais ça reste possible bien sur :

Code:

VDP_loadTileData(const u32 *data, u16 index, u16 num, u8 use_dma);

Pour commencer et faire quelques tests ça peut être utile certes mais vraiment je te conseille vite de t’intéresser et de comprendre comment fonctionne rescomp, en t'inspirant par exemple de ce qui est fait dans le sample 'Sprite' et en regardant le contenu du répertoire 'res' de celui-ci :)

[Tryphon]

J'étais en train d'écrire ma réponse

Bon bien sûr c'est 1000x mieux expliqué par l'auteur himself.

[Stef]

Tu aurais du garder la tienne, peut être qu'elle complétait la mienne sur certains points

[Invité]

Merci beaucoup Stef !!

En fait, la question 3/ me ramène à la manière dont je gérais mes planches avec Bex ... J'utilisais une foule d'outils ainsi que certain que j'avais crée pour me faciliter la tâche.
On peut dire que je faisais du bas niveau avec Bex !
Avec tes outils "Tout en un", je comprend mieux la grand succés de ton DevKit !! 
Je vais bien étudier et tester tout ça ... Mais surtout, c'est d'avoir un minimum de contrôle sur mes ressources graphiques, surtout quand on doit charger dynamiquement une planche ou une palette pendant la Vblank pour avoir un maximum de diversité à l'écran.
Mais ne brûlons pas les étapes !

J'ai le défaut d'avoir un certain niveau qui interfère avec l'apprentissage d'un nouveau DevKit/Technologie, faut freiner la bête !
Mais je suis très motivé et surtout, j'ai pas mal de beaux projets déjà sur le feu et donc, des choses concrètes à faire.
PApi COmmando Tennis sera un bon exercice d'apprentissage car :
- Pas de TileMapping.
- Scrolling vertical sur un plan de 512x512
- Un seul plan à utiliser ( peut être 2 pour du Zorder de base )
- Peu de calcul à faire en temps réel.

Je vous ferai part de mes avancées sur le post de Papi Tennis ! :)
Bonne soirée et merci encore. :)

[Stef]

Pas de quoi ! J'ai hâte de voir tes premiers résultats

[uran]

Bonsoir,

Existe-t-il un moyen d'avoir un résumé des ressources mémoires utilisées avec SGDK?
Genre une jauge donnant la quantité de ROM occupée, une pour la RAM, une pour la VRAM, etc

Je ne sais pas si je suis super clair dans ma demande, c'est un outil dont j'ai l'habitude pour microcontroleur au boulot :)

[Stef]

Pour la RAM et la VRAM, tu peux utiliser les fonctions MEM_getFree() et VRAM_getFree(..). Pour cette dernière il faut passer par le système d'allocation dynamique à partir de "region VRAM" mais ça reste possible. Après ça te sort juste des chiffres, à toi de voir comment les afficher ensuite :p
Pour la taille de la ROM, il n'y a pas de fonction pour ça mais ça doit être possible via la variable _stext :)

[uran]

Pour la RAM et la VRAM, tu peux utiliser les fonctions MEM_getFree() et VRAM_getFree(..). Pour cette dernière il faut passer par le système d'allocation dynamique à partir de "region VRAM" mais ça reste possible. Après ça te sort juste des chiffres, à toi de voir comment les afficher ensuite :p
Pour la taille de la ROM, il n'y a pas de fonction pour ça mais ça doit être possible via la variable _stext :)

A la place de la jauge , j'utiliserais un kdebug juste après les initialisations .

[Tryphon]

Perds pas de vue que tu ne libères pas la VRAM : tu réécris par dessus. Donc la notion de VRAM libre est assez floue.

En fait, sur une console, tu n'es pas vraiment obligé de libérer la RAM non plus... (mais bon, en C, c'est difficile de gérer la RAM autrement).

[Invité]

Coucou,
J'aurai une autre question relatif aux sons/bruitage.
Puis je utiliser le même processus que Bex via les outils de Stef :
1/ On part sur du .WAV
2/ Traitement du son pour avoir un .RAW en 8 bits Unsigned à 14khz.
3/ Utilisation du .Raw dans le code par la suite.

Merci ! :)

[Tryphon]

Là je passe mon tour, le son c'est vraiment un aspect de la programmation MD qui me terrorise

[uran]

Coucou,
J'aurai une autre question relatif aux sons/bruitage.
Puis je utiliser le même processus que Bex via les outils de Stef :
1/ On part sur du .WAV
2/ Traitement du son pour avoir un .RAW en 8 bits Unsigned à 14khz.
3/ Utilisation du .Raw dans le code par la suite.

Merci ! :)

Hello,

Juste pour partager mon expérience sur SGDK122.
Le premier essai que j'ai fait a été de bidouiller l'exemple "sprite" donné avec.
Je me suis retrouvé avec Megaman à la place de Sonic et les musiques et bruitages d'autres jeux. C'est assez simple à prendre en main !
Je suis parti du .wav que j'ai converti en 8bits unsigned 14KHz comme tu le décris, je l'ai déclaré dans un fichier "sound.h" et "sound.res",  je l'initialise avec "SND_setPCM_XGM(SFX_BLAST, megaman_blast_sfx, sizeof(megaman_blast_sfx));" par exemple et je l’appelle avec la fonction "SND_startPlayPCM_XGM(SFX_BLAST,1, SOUND_PCM_CH2);"

Et pour les musiques, c'est quasi pareil avec la fonction SND_startPlay_XGM(sonic_music); après déclaration dans les fichiers sound.h et .res .
Ca en a été bluffant de simplicité !

[Stef]

Coucou,
J'aurai une autre question relatif aux sons/bruitage.
Puis je utiliser le même processus que Bex via les outils de Stef :
1/ On part sur du .WAV
2/ Traitement du son pour avoir un .RAW en 8 bits Unsigned à 14khz.
3/ Utilisation du .Raw dans le code par la suite.

Merci ! :)

Avec rescomp tu peux juste utiliser un WAV, il transforme tout pour toi dans le bon format.
Il faut juste déclarer la ressource selon l'utilisation que tu veux en faire.

Si tu regardes le fichier rescomp.txt :
https://github.com/Stephane-D/SGDK/blob/master/bin/rescomp.txt

Tu peux trouver ceci pour les ressources de type WAV :

Code:

WAV
---
Take a .wav sound file as input and transform it to in binary format usable with one of the SGDK PCM driver.

Syntax:
WAV name wav_file [driver [outrate]]

    name            variable name
    file            path of the .wav file (will be automatically converted to 8 bits signed PCM at needed rate)
    driver          specify the Z80 driver to use:
                        0 / PCM (default)
                            Single channel 8 bits signed sample driver.
                            It can play a sample (8 bit signed) from 8 Khz up to 32 Khz rate.
                            Method to use: SND_startPlay_PCM(..)
                        1 / 2ADPCM
                            2 channels 4 bits ADPCM sample driver.
                            It can mix up to 2 ADCPM samples at a fixed 22050 Hz rate.
                            Method to use: SND_startPlay_2ADPCM(..)
                        2 / 3 / 4PCM
                            4 channels 8 bits signed sample driver with volume support.
                            It can mix up to 4 samples (8 bit signed) at a fixed 16 Khz rate.
                            with volume support (16 levels du to memory limitation).
                            Method to use: SND_startPlay_4PCM_ENV(..)
                        4 / VGM
                            VGM music driver with 8 bits PCM SFX support.
                            It supports single PCM SFX at a fixed ~9 Khz rate while playing VGM music.
                            Method to use: SND_playSfx_VGM(..)
                        5 / XGM
                            XGM music with 4 channels 8 bits samples driver.
                            It supports 4 PCM SFX at a fixed 14 Khz rate while playing XGM music.
                            Methods to use: SND_setPCM_XGM(..) and SND_startPlayPCM_XGM(..)
    outrate        output PCM rate (only used for Z80_DRIVER_PCM driver)
                        By default the default WAV output rate is used.


Réellement dans 95% des cas tu vas utiliser le driver XGM du coup tu vas déclarer ta ressource ainsi :

Code:

WAV explode_sfx "explode_sfx.wav" 5
ou
WAV explode_sfx "explode_sfx.wav" XGM

Le 5 est équivalent à XGM (pour signifier qu'on va utiliser le driver XGM pour jouer ce bruitage).
Je te conseille tout de même d'avoir des fichiers WAV qui sont déjà optimisés à 14 Khz car le resampling utilisé par rescomp est très simple et peut bien dégrader la qualité finale du sample.

[Invité]

Merci de ce retour cher ami !
C'est ce que je pensais donc puisque le driver Z80 de Stef sous Bex est le même.

[Invité]

... Et merci Stef pour les précisions !!
J'Ai toute un panel d'outil pour bien travailles mes sons. Étant musicos, c'est important !
En particulier l'excellent Wavosaur avec qui on peut tout faire !

[Stef]

Hello,

Juste pour partager mon expérience sur SGDK122.
Le premier essai que j'ai fait a été de bidouiller l'exemple "sprite" donné avec.
Je me suis retrouvé avec Megaman à la place de Sonic et les musiques et bruitages d'autres jeux. C'est assez simple à prendre en main !
Je suis parti du .wav que j'ai converti en 8bits unsigned 14KHz comme tu le décris, je l'ai déclaré dans un fichier "sound.h" et "sound.res",  je l'initialise avec "SND_setPCM_XGM(SFX_BLAST, megaman_blast_sfx, sizeof(megaman_blast_sfx));" par exemple et je l’appelle avec la fonction "SND_startPlayPCM_XGM(SFX_BLAST,1, SOUND_PCM_CH2);"

Et pour les musiques, c'est quasi pareil avec la fonction SND_startPlay_XGM(sonic_music); après déclaration dans les fichiers sound.h et .res .
Ca en a été bluffant de simplicité !

Normalement tu peux même rester avec le format WAV si tu préfères, rescomp le prend en charge aussi. Par contre il vaut mieux qu'il soit déjà à 14 Khz si tu comptes utiliser le driver XGM.
Ensuite tu as juste besoin d'éditer le fichier .res pour déclarer correctement ta ressource, le fichier .h est généré tout seul (en fonction du nom de la ressource dans le fichier .res), tu n'as pas à t'en occuper

[uran]

Je précise tout de même un petit truc où je me suis fait piéger en jouant avec les sons, c'est que j'ai du , à chaque changement du son, supprimer l'ancien "sound.o", sinon le nouveau n'était pas "recompilé". Je pense que ce doit être le cas pour chaque ressources utilisant rescomp.
Après je n'ai pas trouvé de doc la dessus (bon je n'ai pas beaucoup cherché non plus j'avoue ..)

[Invité]

En fait avec Sgdk, c'est plus simple de créer son projet qu'avec Bex !

[uran]

En fait avec Sgdk, c'est plus simple de créer son projet qu'avec Bex !

t'auras mis le temps à comprendre dis donc ...
De mon côté, il n'y a que l'intégration dans code::block chez moi où ça veut pas :| ..

[Invité]

Que veux tu .. A mon âge !

[Stef]

Je précise tout de même un petit truc où je me suis fait piéger en jouant avec les sons, c'est que j'ai du , à chaque changement du son, supprimer l'ancien "sound.o", sinon le nouveau n'était pas "recompilé". Je pense que ce doit être le cas pour chaque ressources utilisant rescomp.
Après je n'ai pas trouvé de doc la dessus (bon je n'ai pas beaucoup cherché non plus j'avoue ..)

Ah oui en fait quand tu modifies une des ressources il faut modifier le fichier .res (tu rajoutes un espace que tu enlèveras par la suite par ex) juste pour forcer la recompilation et ainsi régénère les fichiers .o qui en dépendent (et donc le fichier sound.o)

[Invité]

Coucou,

Bon pour le moment, mes compétences techniques SGDK se limitent à afficher "Coucou, SGDK tu me fais peur !"
Pas si mal !
En fait, il y a tellement de chose, de fonctions, de trucs en tout genre bref un tel charabia que ça me fout le vertige .. Et en plus, depuis 2 jours, j'ai justement des vertiges de position plutôt chiant, ça tombe bien. 

Bon, on va oublier la conversion de Papi Tennis pour l'instant, j'ai pas trouvé la bonne clé .. Je ne sais même pas si je vais y arriver, j'arrive pas à synthétiser comment intégrer tout ce travail à avoir un plan d'ensemble.

Bref, c'est pas gagné.

[F.L]

vétéa, n'oublie pas de prendre une clé usb avec sgdk dessus, qu'on s'amuse un peu. je prends mon pc portable, ça va coder sec
a tout à l'heure l'ami

[Invité]

Arggg ... Non François !!!!
Je prends juste tes petits cadeaux !
Avec SGDK, je ne sais rien faire ...

Je prendrais mes prod' en Bex .. Enfin juste les ROM, car le code ça serait trop long ! 
A tout à l'heure ! :)

[troudki]

hello
Je suis en train de passer doucement sur la version 1.22a de SGDK..
1er test pas concluant dans la toolschain.. en compilant l'exemple sprite , je ne vois pas rescomp compiler les images.
Mon env de dev sous virtualbox : Windows XP SP3 + Java 1.7.0_79
need help:(

Code:

-------------- Build: debug in sprite (compiler: SEGA SGDK)---------------

Running command: make.exe -f C:\SGDK\makefile.gen debug
C:/SGDK/bin/mkdir -p src/boot
C:/SGDK/bin/mkdir -p out
C:/SGDK/bin/mkdir -p out/src
C:/SGDK/bin/mkdir -p out/res
C:/SGDK/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -IC:/SGDK/inc -IC:/SGDK/res -BC:/SGDK/bin -O1 -ggdb -DDEBUG=1 -c src/boot/rom_head.c -o out/rom_head.o
C:/SGDK/bin/ld -T C:/SGDK/md.ld -nostdlib --oformat binary -o out/rom_head.bin out/rom_head.o
C:/SGDK/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -IC:/SGDK/inc -IC:/SGDK/res -BC:/SGDK/bin -O1 -ggdb -DDEBUG=1 -c src/boot/sega.s -o out/sega.o
C:/SGDK/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -IC:/SGDK/inc -IC:/SGDK/res -BC:/SGDK/bin -O1 -ggdb -DDEBUG=1 -c res/gfx.s -o out/res/gfx.o
C:/SGDK/bin/rescomp res/sound.res res/sound.s
rescomp v1.5
Resource: XGM sonic_music "music/sonic1.vgm"
--> executing plugin XGM...
Executing C:\SGDK\bin/xgmtool "res/music/sonic1.vgm" "res/music/sonic1.bin" -s
Resource: WAV sonic_jump_sfx "sfx/S1_jump.wav" XGM
--> executing plugin WAV...
Executing C:\SGDK\bin/wavtoraw "res/sfx/S1_jump.wav" "res/sfx/S1_jump.tmp" 14000
Resource: WAV sonic_roll_sfx "sfx/S1_roll.wav" XGM
--> executing plugin WAV...
Executing C:\SGDK\bin/wavtoraw "res/sfx/S1_roll.wav" "res/sfx/S1_roll.tmp" 14000
Resource: WAV sonic_stop_sfx "sfx/S1_stop.wav" XGM--> executing plugin WAV...
Executing C:\SGDK\bin/wavtoraw "res/sfx/S1_stop.wav" "res/sfx/S1_stop.tmp" 14000
C:/SGDK/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -IC:/SGDK/inc -IC:/SGDK/res -BC:/SGDK/bin -O1 -ggdb -DDEBUG=1 -c res/sound.s -o out/res/sound.o
C:/SGDK/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -IC:/SGDK/inc -IC:/SGDK/res -BC:/SGDK/bin -O1 -ggdb -DDEBUG=1 -c res/sprite.s -o out/res/sprite.o
C:/SGDK/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -IC:/SGDK/inc -IC:/SGDK/res -BC:/SGDK/bin -O1 -ggdb -DDEBUG=1 -c src/main.c -o out/src/main.o
src/main.c: In function `main':
src/main.c:83: error: `bgb_image' undeclared (first use in this function)
src/main.c:83: error: (Each undeclared identifier is reported only once
src/main.c:83: error: for each function it appears in.)
src/main.c:85: error: `bga_image' undeclared (first use in this function)
src/main.c:111: error: `sonic_sprite' undeclared (first use in this function)
src/main.c:113: error: `enemies_sprite' undeclared (first use in this function)
make: *** [out/src/main.o] Error 1
rm res/sound.s
Process terminated with status 2 (0 minute(s), 0 second(s))
6 error(s), 0 warning(s) (0 minute(s), 0 second(s))

[uran]

Tu fais appel dans ton code à 'bgb_image', 'bga_image', 'sonic_sprite' et 'ennemies_sprite'  sans les avoir déclaré avant.

Ils doivent apparaitre dans les fichiers sprite.res et sprite.h avec leur chemin respectif.


par contre sur la 1ère ligne

Code:

Running command: make.exe -f C:\SGDK\makefile.gen debug

Pourquoi as-tu debug à la fin ?

Pour le compiler j'ai

Code:


D:\sgdk\sample\sprite>build

D:\sgdk\sample\sprite>D:/sgdk\bin\make -f D:/sgdk\makefile.gen
D:/sgdk/bin/mkdir -p src/boot
D:/sgdk/bin/mkdir -p out
D:/sgdk/bin/mkdir -p out/src
D:/sgdk/bin/mkdir -p out/res
D:/sgdk/bin/rescomp res/gfx.res res/gfx.s
rescomp v1.5

Resource: IMAGE bgb_image "gfx/bgb.png" -1
--> executing plugin IMAGE...
Executing D:\sgdk\bin/appack c "pack.in" "pack.out" -s
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with APLIB, original size = 12256 compressed to 4630 (37.7774 %)
Executing D:\sgdk\bin/appack c "pack.in" "pack.out" -s
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with APLIB, original size = 4480 compressed to 1051 (23.4598 %)

Resource: IMAGE bga_image "gfx/bga.png" -1
--> executing plugin IMAGE...
Executing D:\sgdk\bin/appack c "pack.in" "pack.out" -s
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with APLIB, original size = 5728 compressed to 1972 (34.4274 %)
Executing D:\sgdk\bin/appack c "pack.in" "pack.out" -s
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with APLIB, original size = 4480 compressed to 539 (12.0313 %)
D:/sgdk/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -ID:/sgdk/inc -ID:/
sgdk/res -BD:/sgdk/bin -O1 -fomit-frame-pointer -c res/gfx.s -o out/res/gfx.o
D:/sgdk/bin/rescomp res/sound.res res/sound.s
rescomp v1.5

Resource: XGM sonic_music "music/sonic1.vgm"
--> executing plugin XGM...
Executing D:\sgdk\bin/xgmtool "res/music/sonic1.vgm" "res/music/sonic1.bin" -s

Resource: WAV sonic_jump_sfx "sfx/S1_jump.wav" XGM
--> executing plugin WAV...
Executing D:\sgdk\bin/wavtoraw "res/sfx/S1_jump.wav" "res/sfx/S1_jump.tmp" 14000


Resource: WAV sonic_roll_sfx "sfx/S1_roll.wav" XGM
--> executing plugin WAV...
Executing D:\sgdk\bin/wavtoraw "res/sfx/S1_roll.wav" "res/sfx/S1_roll.tmp" 14000


Resource: WAV sonic_stop_sfx "sfx/S1_stop.wav" XGM--> executing plugin WAV...
Executing D:\sgdk\bin/wavtoraw "res/sfx/S1_stop.wav" "res/sfx/S1_stop.tmp" 14000

D:/sgdk/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -ID:/sgdk/inc -ID:/
sgdk/res -BD:/sgdk/bin -O1 -fomit-frame-pointer -c res/sound.s -o out/res/sound.
o
D:/sgdk/bin/rescomp res/sprite.res res/sprite.s
rescomp v1.5

Resource: SPRITE sonic_sprite "sprite/sonic.png" 6 6 FAST 5
--> executing plugin SPRITE...
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 438 (38.0208 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 450 (39.0625 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 460 (39.9306 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 494 (42.8819 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 524 (45.4861 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 504 (43.75 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 490 (42.5347 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 536 (46.5278 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 518 (44.9653 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 538 (46.7014 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 502 (43.5764 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 520 (45.1389 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 508 (44.0972 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 474 (41.1458 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 456 (39.5833 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 426 (36.9792 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 392 (34.0278 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 434 (37.6736 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 428 (37.1528 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 446 (38.7153 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 388 (33.6806 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 1152 compressed to 294 (25.5208 %)

Resource: SPRITE enemies_sprite "sprite/enemies.png" 6 4 FAST 5--> executing plu
gin SPRITE...
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 768 compressed to 488 (63.5417 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 768 compressed to 452 (58.8542 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 768 compressed to 552 (71.875 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 768 compressed to 572 (74.4792 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 768 compressed to 518 (67.4479 %)
Executing java -jar D:\sgdk\bin/lz4w.jar p "pack.in" "pack.out" -s
Packed with LZ4W, original size = 768 compressed to 592 (77.0833 %)
D:/sgdk/bin/gcc -m68000 -Wall -fno-builtin -Iinc -Isrc -Ires -ID:/sgdk/inc -ID:/
sgdk/res -BD:/sgdk/bin -O1 -fomit-frame-pointer -c res/sprite.s -o out/res/sprit
e.o
echo "out/res/gfx.o out/res/sound.o out/res/sprite.o out/src/main.o" > out/cmd_
D:/sgdk/bin/gcc -BD:/sgdk/bin -n -T D:/sgdk/md.ld -nostdlib out/sega.o @out/cmd_
 D:/sgdk/lib/libmd.a D:/sgdk/lib/libgcc.a -o out/rom.out
D:/sgdk/bin/rm out/cmd_
D:/sgdk/bin/objcopy -O binary out/rom.out out/rom.bin
D:/sgdk/bin/sizebnd out/rom.bin -sizealign 131072
rm res/sprite.s res/sound.s res/gfx.s

D:\sgdk\sample\sprite>

Remarque je ne sais pas si cela change grand chose au problème...

[Stef]

@troudki>
C'est assez bizarre tes résultats. En gros tu as déjà les fichiers .s des ressources c'est pour ça qu'il ne recompile pas tout.
Par contre vu l'erreur que tu obtiens c'est comme si les fichiers .h générés étaient corrompus ou incorrects, tu peux me montrer le contenu de l'un d'entre eux ?

Sinon je te conseille de ré essayer en faisant un clean avant :

Code:

make.exe -f C:\SGDK\makefile.gen clean

On ne sait jamais