Re: Sgdk - Sega Megadrive / Genesis Development Kit

[fourchette]

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

[fourchette]

Bonjour,

Une petite question concernant le "sprite engine" : si je fais un SPR_addSprite et plus tard un SPR_releaseSprite (suivi de SPR_update et VDP_waitVSync), normalement le sprite ne s'affiche bien plus à l'écran et les ressources associées sont bien libérées ?

J'ai l'impression que la fonction SPR_releaseSprite ne fonctionne pas bien chez moi (SGDK 1.21), suite à l'appel de cette fonction, le sprite continue de s'afficher et dans certains cas, j'ai même l'impression qu'elle , j'ai eu droit à des plantages sur l'émulateur. Je me débrouille sans, pour l'instant, car je n'ai pas besoin de modifier les sprites à la volée, j'utilise un SRP_reset et je cache les prites quand j'en ai besoin, mais pour plus tard ça risque de me poser problème.

Autre chose pas forcément en rapport avec le SGDK : comment faites vous pour passez d'un écran à un autre (en redessinant tous les tiles) sans que l'on voit les changement de tiles à l'écran ?

[dub]

Pour le SPR_releaseSprite, je n'ai pas testé. Faut voir avec Stef, mais peut-être qu'il faut faire un release quand il n'est plus à l'écran ou vérifier que tu n'as pas un SPR_setVisibility qui force la visibilité.

Si tu veux changer toutes les tiles, le plus simple c'est de le faire entre un VDP_setEnable(0); et un VDP_setEnable(1);
Tu coupes l'affichage du VDP, tu affiches tes tiles et tu relances l'affichage du VDP.

[philip]

Autre chose pas forcément en rapport avec le SGDK : comment faites vous pour passez d'un écran à un autre (en redessinant tous les tiles) sans que l'on voit les changement de tiles à l'écran ?

Juste avant de réaliser ce changement de tiles, mettre la ou les palettes à 0, ou encore une transition à 0 avec VDP_fadeAll entre deux VDP_waitDMAComplation();

[Stef]

fourchette> Effectivement y'a un soucis sur le SPR_release(..) qui n'efface pas le sprite (même s'il est bien libéré en terme de ressource). Je vais corriger ça :)

[Top l'âne]

Salut les potos,

je viens glaner quelques infos concernant un point qui m'est parfaitement flou.

Concrètement, j'ai procédé à divers ajouts de fond pour l'environnement gameplay de Alien Hates Japan. Un système de vagues plus évolué, des tirs ennemis, la mort du vaisseau...
J'ai observé immédiatement une instabilité du prog. Du freeze à l'illegal instruction et qui arrive de manière trop chaotique pour que je puisse en identifier une cause.

J'ai fouillé en aveugle et j'ai corrigé le problème en encadrant systématiquement mes appels au VDP avec des SYS_disableInts/enableInts();

Par exemple je fais des appels en cours de jeu pour modifier une palette pour un nouvel ennemi, ou en sortie de boucle pour l'init du VDP.

Bref, je ne sais pas ce que sont exactement ces interruptions qui menacent d'interférer avec le VDP.

[Invité]

Pour la modification de la palette , je pense que cela doit se faire pendant le Hblank ou le Vblank en général
On tout cas c'est le cas pour la plupart des consoles , je pense que la MD suit cette logique.

Sinon ben ça peut être plus pervers un mauvais pointeurs

[Stef]

Salut les potos,

je viens glaner quelques infos concernant un point qui m'est parfaitement flou.

Concrètement, j'ai procédé à divers ajouts de fond pour l'environnement gameplay de Alien Hates Japan. Un système de vagues plus évolué, des tirs ennemis, la mort du vaisseau...
J'ai observé immédiatement une instabilité du prog. Du freeze à l'illegal instruction et qui arrive de manière trop chaotique pour que je puisse en identifier une cause.

J'ai fouillé en aveugle et j'ai corrigé le problème en encadrant systématiquement mes appels au VDP avec des SYS_disableInts/enableInts();

Par exemple je fais des appels en cours de jeu pour modifier une palette pour un nouvel ennemi, ou en sortie de boucle pour l'init du VDP.

Bref, je ne sais pas ce que sont exactement ces interruptions qui menacent d'interférer avec le VDP.

Ca c'est peut etre un des points les plus complexes à appréhender quand tu développes sur ce genre de console.
A la fin de chaque frame tu as une interruption verticale (V-Int) qui te permet d'executer du code sensible pendant le VBlank.
SGDK utilise la V-Int pour transférer des données vers le VDP (tiles et table de sprite et tout ce qui a été empilé dans la queue DMA). Mais du coup il faut bien faire attention à "protéger" les accés VDP de ta boucle principale sinon une V-Int peut interrompre ton traitement sur le VDP en cours de route et la routine SGDK va complètement corrompre tes écritures ce qui peut carrément aboutir à un plantage...
Et pour protéger ton code il faut effectivement temporairement desactiver les interruptions comme tu l'as fait.
En gros tu dois protéger tout ce qui est susceptible d'être modifié par la routine V-Int de SGDK, bien sûr tu peux aussi placer du code dans la V-Int (en utilisant la méthode SYS_setVIntCallback(..)) ainsi tu es sur qu'il est safe pour accéder au VDP.
Aussi au fur et à mesure j'essai de protéger certaines routines de SGDK mais pour des raisons de performances je ne peux pas le faire systématiquement à chaque appels de méthodes.

[Top l'âne]

A la lumière de cette réponse, j'imagine que je dois peut être également protéger les appels au Sprite_engine...?

C'est quoi le DMA? (jusqu'alors, dans le doute, j'ai toujours ignoré les relations éventuelles avec le DMA)

@kannagi: même pas peur.^^
Je me sens plutôt à l'aise avec l'utilisation des pointeurs. Déjà y en a pas tant que ça dans mon code, et pour cette raison j'avais dans l'idée que justement, une erreur de pointeur devait se repérer assez facilement... A tort peut être. :p
Néanmoins c'est un point sur lequel j'ai tâché d'être rigoureux.

[Invité]

Le DMA Direct Memory Access , c'est une accélération matériel pour copier des donners (ROM/RAM/VRAM en général) , et la plupart du temps le DMA est plus rapide qu'un copie classique.
Sauf sur Neo Geo le DMA est plus long comme transfert que une copie normal (et donc le DMA ne sert a rien sur Neo Geo \o/).

Pour les pointeurs oui si tu en utilise pas beaucoup cela réduit les erreurs , mais oui t'as bien raison d’être rigoureux parce que les erreurs de pointeurs sont plus difficile a dénicher

Pour ma part sur SNES pour régler ce soucis (de changer la palette en cours du jeu) j'utilise un buffer (pour les sprites , pour les palettes pour tout ) , tu devrait faire pareil , comme ça du peut changer la palette en cours de jeu sans trop de soucier du VBlank.

[Hpman]

Sauf sur Neo Geo le DMA est plus long comme transfert que une copie normal (et donc le DMA ne sert a rien sur Neo Geo \o/).

Neo geo -CD-, le DMA n'existe pas dans les hardwares cartouche 

[Invité]

Autant pour moi , je pensais que le DMA existait aussi sur la version cartouche

[Stef]

A la lumière de cette réponse, j'imagine que je dois peut être également protéger les appels au Sprite_engine...?

Théoriquement je protège déjà les fonctions qui ont besoin de l'être (SPR_update(..) seulement de mémoire) =)

[Top l'âne]

Oui c'est ce que je me suis dit après coup. Je m'étais replongé dans le sample sprite pour l'occasion pour n'y trouver aucune parade lors des appels du SPR.

Bref, j'ai le plaisir d'annoncer que j'ai peaufiné une première ébauche de moteur hier soir.
J'avais rencontré un nouveau problème lors de la mise en place des chargements de différents levels visiblement lié à un abus du VDP_init();

Ebauche moteur complète donc, gestion du vaisseau, des ennemis, du chargement de maps et des particularités de gameplay que nous avons décidé avec Tetsu.
Et stable, pour ce que j'ai pu en tester pour l'instant avec Regen. :)

J'espère qu'on vous présentera une nouvelle démo prochainement.

Encore merci à tous. :)

[Top l'âne]

Et stable, pour ce que j'ai pu en tester pour l'instant avec Regen. :)

Et pas si stable que ça en fin de compte. Mouarf j'ai du faire face à un crash récurent en bout de code, il a fallu lutté.^^

Rappel des faits, mon code se profilait grossièrement de la sorte, avec un main qui ne sert qu'à désigner les pages de jeux, puis chaque page de jeu qui s'ouvre sur un VDP_init/SPR_init et se ferme sur un SPR_end:


int main() {

int check = 0;
while(TRUE) {
if(check == 0) intro();
else if(check == 1) stage1();
else if(check == 2) stage2();
VDP_waitVSync();
}}



void stage1() {
VDP_init();
SPR_init();
while(continuer) {
VDP_waitVSynch();
}
SPR_end();
}



J'avais supposé qu'un VDP_init devait également réinitialiser le sprite_engine?
Mon emploi du sprite_engine semble t'il hasardeux? Je pense principalement à la manière de le clôturer? (là je le présente en sortie de boucle, mais j'ai essayé de le coller à différents endroits, sans plus de succès)
Le SPR est il simplement sujet à caution? (avant dernière version de SGDK)


Je ne savais pas trop dans quelle mesure je devais incriminer mon code, mais j'avais dans l'idée que le SPR posait problème aussi, parce que en plus du crash systématique, j'avais aussi des bugs d'affichages fréquents, uniquement liés aux sprites (clignotements typiquement).

Donc après une batterie de tests à n'en plus finir, j'ai modifié mon approche du code en m'inspirant de ce que j'ai vu ici ou là, et j'ai rapatrié l'exécution de mes stages de jeu directement dans le main.
A l'heure actuelle j'initialise le SPR une fois avant la boucle de jeu et basta, je ne le ferme jamais, je me contente d'update/masquer les sprites  entre chaque stage.

Visuellement résultat identique (mais une très légère perte de vitesse d'exécution).
Test hardware sur 30 minutes 100% stable.

[Stef]

En fait ça dépend sur quelle version de SGDK tu te trouves. Le sprite engine a été quasiment réécrit "from scratch" récemment, il est encore un peu immature et j'ai corrigé quelques bugs avec la dernière version de SGDK (on doit être à la 1.22).
Mais sinon en effet, en théorie tu peux très bien initialiser une seule fois le Sprite engine pour tout le jeu, et tu peux utiliser SPR_reset() pour libérer et effacer tout les sprites. Pareil pour le VDP_init(), il vaut mieux faire un VDP_reset() pour effacer tout les plans.

[fourchette]

Bonjour à tous,

Je débute au niveau du son et j'ai un petit soucis que je ne comprends pas. Après avoir lancé une musique, dès que je lance un effet sonore, la musique se coupe (testé sur plusieurs émulateurs). Le code peut se résumer à

Code:

SND_startPlay_XGM (mus);
// ...
SND_startPlay_2ADPCM(sfx, sizeof(sfx), SOUND_PCM_CH1, FALSE);

Le rescomp.res correspondant :

Code:

WAV     sfx     sound.wav    1
XGM     mus     music.vgm    1

Le VGM est issue du jeu F-15 Strike Eagle II.

Est-ce que j'oublie quelquechose dans le code ? le XGM et le WAV utilisent-ils des ressources communes ?

[dub]

J'ai pas testé cette fonction, mais tu devrais regarder autour du "SOUND_PCM_CH1". Si tu envois sur le même channel, ça doit logiquement couper.

Soit tu utilises : SOUND_PCM_CH_AUTO , ou alors sound_pcm_ch1 et sound_pcm_ch2. Tu dois avoir 4 channels en tout si tu regardes la doc : http://www.retropc.net/mm/md/doc/html/sound_8h.html

[Stef]

Bonjour à tous,

Je débute au niveau du son et j'ai un petit soucis que je ne comprends pas. Après avoir lancé une musique, dès que je lance un effet sonore, la musique se coupe (testé sur plusieurs émulateurs). Le code peut se résumer à

Code:

SND_startPlay_XGM (mus);
// ...
SND_startPlay_2ADPCM(sfx, sizeof(sfx), SOUND_PCM_CH1, FALSE);

Le rescomp.res correspondant :

Code:

WAV     sfx     sound.wav    1
XGM     mus     music.vgm    1

Le VGM est issue du jeu F-15 Strike Eagle II.

Est-ce que j'oublie quelquechose dans le code ? le XGM et le WAV utilisent-ils des ressources communes ?

En fait il faut utiliser le même driver, là en gros tu lances le driver XGM pour jouer ta musique, ensuite tu joues un WAV avec le driver ADPCM 2 channels (ce qui interrompt le driver XGM).
Je te conseille de rester donc 100% avec XGM qui te permet de jouer de la musique et du PCM, il faut donc déclarer ta ressource WAV pour utiliser le driver XGM :

Code:

WAV     sfx     sound.wav    5
XGM     mus     music.vgm    1

et ensuite utiliser les bonnes fonctions pour ça :

Code:

SND_setPCM_XGM(id, sfx, sizeof(sfx));

ensuite :

Code:

SND_startPlayPCM_XGM(id, priority, channel);

id permet d'identifier le sample, pour un bruitage il doit être >= 64.
Par exemple si tu as 2 SFX :

Code:

SND_setPCM_XGM(64, sfx1, sizeof(sfx1));
SND_setPCM_XGM(65, sfx2, sizeof(sfx2));

Ensuite pour les jouer :

Code:

SND_startPlayPCM_XGM(64, 1, SOUND_PCM_CH1);
SND_startPlayPCM_XGM(65, 1, SOUND_PCM_CH2);

[fourchette]

Merci Stef, ça fonctionne comme ça.

Sinon qu'elle est le meilleur format pour le son (bruitage, musique) et quels sont les meilleurs outils pour les créer, en particulier les bruitages ? je trouve que le wav ne rend pas particulièrement bien de manière générale.

[Stef]

Si tu utilises le driver XGM, alors tu n'as pas le choix, ça sera du WAV, à mon sens c'est le mieux que tu puisses avoir, je ne comprends pas quand tu dis que ça ne rend pas bien. Tu as un problème de volume ?
Pour assurer le meilleur rendu possible il faut "préparer" tes samples à l'avance avec des outils dédiés. XGM utilise un échantillonnage à 14 Khz donc il faut resampler les WAV à 14 Khz avant avec un outil dédié (wavosaure par exemple mais tu en as plein d'autres) pour leur garantir la meilleur qualité. SGDK fait un resampling automatiquement mais sans aucun traitement et ça rend pas terrible.

[fourchette]

Par "ne rend pas bien", j'entends que le son digitalisé, de manière générale, ne sonne pas bien à mon oreille, comparé aux bruitages et musiques composés spécifiquement pour les puces de la Megadrive (ce que je suis incapable de produire). Et cela même en ressamplant au préalable. Je vais quand même continuer dans cette voie, c'est plus simple pour moi.

Quels sont les outils pour créer des bruitages pour la megadrive ? j'ai vu Deflemask et tfmmaker pour les musiques, il me semble.

[uran]

Bonjour,

je découvre tous juste SGDK et j'ai un petit soucis à la compilation lors de l'ajout d'un second sprite à mon essai, la sortie de la compilation me donne ça : 

Resource: SPRITE shoot "sprite/shoot.png" 1 1 FAST 0 BOX

--> executing plugin SPRITE...

Image 'res/sprite/shoot.png':

2 bpp PNG not supported

make: *** [res/sprite.s] Error 1

rm res/sprite.s

Je comprend bien que mon image doit être en 8bpp pour être compatible avec rescomp, mais .. je ne sais pas pourquoi celle-ci est en 2bpp et que les autres que j'ai faites semble être en 8bpp.
J'utilise Gimp2 pour faire mes sprites au bon format ( 16 couleurs indexées et dimensions en multiple de 8 pixels).

Pouvez-vous m'aiguiller ou je pêche ?
Voici le sprite à l'échelle 1 ! (il fait 8 pixels de côtés)



Merci
Yann

[dub]

Ca fait un moment que je suis pas passé

Effectivement, gimp te transforme en 2bpp car seulement 4 couleurs. Tu seras obligé d'en rajouter à la main même si elles sont pas utilisées. Tu peux regarder dans Gimp avec "fenêtre -> fenêtre ancrable -> Palettes des couleurs indexées"

https://dl.dropboxusercontent.com/u/27435968/shoot110.zip
Celle là devrait être bonne. Je te l'ai zippé car j'ai l'impression qu'en insérant une image directe dans le navigateur ça transforme aussi l'image en 2bpp

[uran]

C'est ce qui me semblait mais je n'étais pas sur.
Merci dub.

ps: erreur 404 sur le lien. Mais je vais me débrouiller

[Stef]

Normalement SGDK supporte les images 8bpp et 4bpp. Et effectivement si ton image fait 4 couleurs ou moins gimp va te faire un 2bpp, dans ce cas il faut manuellement rajouter couleurs dans la palette même si elles ne sont pas utilisées.

[dub]

Oups, erreur copier-coller, j'ai corrigé

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

[uran]

Et une couleur de plus, et c'est bon.

[uran]

Oups, erreur copier-coller, j'ai corrigé

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

Ha oui en fait tu as saturé le reste de la palette avec une couleur déjà existante, pas une nouvelle couleur. -_- je retiens pour la prochaine fois.

merci

[Invité]

Bonjour a tous,
J'aurai une question simple :
Quels sont les homebrew MD développés avec le SGDK qui ont été publiés et mise en vente ?
Merci bien.

[ichigobankai]

Aucun à ma connaissance - du moins ca n'a pas été écrit,
cependant je ne sais pas avec quel(s) outil(s) a été fait Oh Mummy Genesis (de 1985 alternativo),
ainsi que Uwol : Quest for money.