Re: developper sur SNES avec pvsneslib !

[Invité]

mais dès que je dépasse la vingtaine ça commence à ralentir (entre les tests de collisions, les animations, etc)

En même temps 20 sprites animés qui doivent gérer les collisions entre eux,en C c'est pas anodin niveau ressource,encore plus sur snes .

[Invité]

Meuuuh si !! 


Le C est fantastique !!
Faut au maximum utiliser la force des pointeurs pour tout usage de tableau de structure.
Putain, c'est moi qui donne des conseils de prog ... °_°

[Invité]

Le C est les 65xxx c'est pas trop des copains, ça dépend aussi du compilo (en général pas top pour ces CPU), du coder, et pour finir y'a aussi l'archi de la snes qui vient compliquer les choses .

Mais j'ai pas l'impression que tu gères les collisions(ou alors de manière simplifiée ??) .

[Invité]

60 sprites animés et gérés c'est normal hein !
Mais c'est vrai, j'ai souvenir que Alek utilisait beaucoup l'ASM pour ses projets en plus du C du fait de l'Hardware a la ramasse et désastreux de la SNES ... Mais cela est une autre histoire à évoquer dans le post des rageux SNES vs MD.

[ichigobankai]

Le moins cher pour le pseudo alétaoire c'est des valeurs précalculées. D'une maniere général tout ce qui est prédictible devrait déjà etre maché pour gagner en perf.

Tu génères un binaire de 256 valeurs (0..255) pour boucler facilement via un char, valeur comprise en X et Y X et Y étant tes valeurs min/max)

Après juste a aller chercher la valeur dans le tableau et incrémenter la position pour la prochaine valeur à recup.

tu peux créer ces valeurs via un logiciel hexa (comme HxD) ou dans wla (mais vu que c'est en asm, pas sur que ce soit utile d'en parler...)

[Invité]

Avoir une valeur aléatoire n'est pas compliqué, la problématique c'est plus d'éviter d'avoir les mêmes valeurs aléatoires à chaque partie,surtout au début .
Pour moi il faut incrémenter la valeur de référence dans les commandes pad du ou des joueur(s) pour avoir un truc le plus aléatoire possible vu que les actions des joueurs ont peu de chances d'être toujours les mêmes .

l'Hardware a la ramasse et désastreux de la SNES

Le hardware n'est pas à la ramasse, il est juste mal pensé a cause des restes évidents de compatibilité nes .
Ce qui tape dans les ressources limitées du CPU qui a 2,6 mhz  n'en avait pas besoin, du coup tu dépenses des cycles inutilement sur des trucs qui sont natifs sur la MD et la PCE .

[Invité]

Mal pensé est une cause de la "Ramasse".
Néanmoins, je pense qu'utiliser des tableaux genre t[i] avec une boucle for peut être rédhibitoire.

Pour ma part, avec Papi Reload la somme très importante que j'ai à gérer, je procède comme ceci :
Sprite1_ est ma Structure et Sprites[x] le tableau de cette structure.
Sprite1_ Sprites[x];

Code:


  //Déclaration pointeur tableau
 u16 i=MaxObjet;
 Sprite1_* spr=Sprites;

    // Boucle Principale
 while (i--)
    {
        //Affichage des sprites
        RoutineAffichage(spr);
        // next sprite
        spr++;
    }

Faudrait faire des tests avec cette méthode pour voir si c'est un peu plus rapide.
Bon courage ! :)

[drludos]

Merci à tous pour vos conseils, je vais essayer tout cela pour voir si ça booste un peu le jeu !

Je note notamment le fait d'utiliser plutôt des pointeurs vers des structures dans un tableau, au lieu de copier la structure dans une variable locale, ainsi que vos diverses méthodes pour le random "moins gourmand" (après, celui de la lib est vraiment bon, car il génère des valeurs bien différentes).

Sinon oui, je sais très bien qu'utiliser du C sur SNES c'est déjà un gros handicap pour les performances. Je crois même que le 65816 est pire que le 6502 à ce niveau, surtout que le seul compilo disponible (tcc-816) est loin d'être parfait d'après ce qu'on peut lire sur les forums américains (où tout le monde de dit de faire de l'assembleur, ou d'oublier la SNES sinon).

Personnellement, c'est en voyant les réalisations d'Alekmaul avec sa lib que je me suis que quand même, les membres du forum SNESDev exagéraient un peu - même si c'est plus lent, il est possible de faire des petits jeux sympa en C sur SNES.

Maintenant que j'ai commencé, j'avoue que oui, ça se met vite à ramer. Surtout quand je vois ce que fait Vétéa avec Papi Reloaded sur Megadrive. Comme quoi, le "Blast processing" c'est pas qu'un mythe :p. Après, tout est relatif: par rapport à la GB, la SNES est un monstre de puissance pour moi :). En comparaison, sur GB, j'avais commencé un petit shoot: avec 5 ennemis et 3 projectiles à l'écran, qui bougent et collisionnent, mais ne sont pas encore animés, je sature déjà le CPU de la portable).

D'ailleurs, est-ce que vous savez s'il y a émulateur / débugger qui permet de connaitre la "charge CPU" de la SNES ? BGB permet de savoir ça pour la Gameboy, ce qui est hyper pratique pour savoir si ton programme rame ou non !

[Invité]

Sinon oui, je sais très bien qu'utiliser du C sur SNES c'est déjà un gros handicap pour les performances.

Disons que connaitre comment le compilo va te générer tel code en C peut te permettre de faire du code C le plus efficace .
Par exemple je pense qu'il vaut mieux éviter les switch/case en général, je sais pas si le compilo qui est dans la lib optimise ce genre de choses .

Surtout quand je vois ce que fait Vétéa avec Papi Reloaded sur Megadrive

Le 68000 de la Md tourne déjà à 7,6 mhz (vs 2,68 pour celui de la snes), ensuite c'est un CPU taillé pour le C contrairement au 65816, et pour finir le compilateur de SGDK est sans cesse amélioré, contrairement a ceux pour les 65xxx qui datent et sont en général peu performants .
Au final le résultat entre les 2 peut être assez conséquent .

D'ailleurs, est-ce que vous savez s'il y a émulateur / débugger qui permet de connaitre la "charge CPU" de la SNES ? BGB permet de savoir ça pour la Gameboy, ce qui est hyper pratique pour savoir si ton programme rame ou non !

En général on change la couleur de l'overscan avant et après une fonction,ou un bout de code pour avoir une idée .

Personnellement, c'est en voyant les réalisations d'Alekmaul avec sa lib que je me suis que quand même, les membres du forum SNESDev exagéraient un peu - même si c'est plus lent, il est possible de faire des petits jeux sympa en C sur SNES.

Un sdk ne peut s'améliorer que si des gens l'utilisent et font remonter les bugs,et puis contrairement a SGDK qui existe depuis pas mal d'années maintenant(depuis 2006 je crois), celui d'alek est qd même assez jeune,donc forcement il ne peut en aucun cas être aussi bon.

[ichigobankai]

Par exemple je pense qu'il vaut mieux éviter les switch/case en général, je sais pas si le compilo qui est dans la lib optimise ce genre de choses

C'est con moi j'aime bien (autant en php qu'en C)
Faut regarder l'asm en sortie pour savoir comment ton compilo gère cette fonction.

Normalement un switch/case "bien fait" devrait générer une belle jumptable.
Evidemment dans un switch/case il faut impérativement des valeurs successives à tester et non un gruyère

[Invité]

C'est con moi j'aime bien (autant en php qu'en C) 

Pas sur PC bien sur, moi aussi j'aime bien et je l'utilisais avec HuC,sauf qd j'ai vu l'impact que ça avait car le compilo ne faisait aucune optimisation .

Normalement un switch/case "bien fait" devrait générer une belle jumptable.

Justement le compilo de la PCE ne le faisait pas .

[drludos]

Un sdk ne peut s'améliorer que si des gens l'utilisent et font remonter les bugs,et puis contrairement a SGDK qui existe depuis pas mal d'années maintenant(depuis 2006 je crois), celui d'alek est qd même assez jeune,donc forcement il ne peut en aucun cas être aussi bon.

Loin de moi l'idée de critiquer la PVSNESLib - au contraire, je trouve ça absolument génial comme outil, surtout quand on voit la complexité de l'ASM 65816 et de l'architecture "atypique" de la SNES !
Je trouve notamment super pratique le "workflow" pour ajouter des graphismes (j'ai pas encore testé le son), mais comparé à celui de la GB par exemple, c'est plus simple. Il suffit de dessiner directement dans des fichiers BMP en 16 couleurs, et hop çaa te génère les sprites et les palettes tout seul, c'est extra!

Le seul point que j'ai encore du mal à saisir, c'est comment déterminer l'adresse dans la VRAM où envoyer les sprites et les tiles. J'ai l'impression qu'il y a des contraintes à respecter (alignement, zone haute ou zone basse), mais je ne sais pas encore lesquelles.

C'est vrai que la scène homebrew de la SNES est très chiche en comparaison de celle de la MD, et je pense que c'est avant tout du aux outils et à la complexité de la console (deux processeurs différents, CPU atypique et plus lent que sur la MD, etc.). Mais bon, quand je vois l'enthousiasme sur ce post (qui rassemble trois ou quatre projets mine de rien :p), on se dit que ça peut toujours démarrer :).

De mon coté, j'avance toujours à mon petit rythme. Quand j'aurai un prototype "montrable", j'en ferais un post séparé, mais j'ai déjà une petit base de jeu (deux joueurs qui bougent et peuvent tirer, des ennemis qu'on peut shooter, des compteurs de vie et de score). Merci donc à la PVSNESlib pour me permettre de faire cela, car sinon cela m'aurait été inaccessible.

---------

Au fait, j'ai rencontré un autre problème tout bête. Mon "proto-jeu" marche bien sur ma SNES PAL (testé avec SD2SNES), il marche aussi impeccable sur ZSNES. Par contre, sur Higan et BSNES-accuracy, ca affiche de la bouillie (on dirait qu'il ne trouve pas les palette, les sprites sont là, mais avec des couleurs complètement random).

Sur BSNES Classic normal et SNES9X ça marche, sauf que mes sprites de 32x32 ne s'affichent qu'à moitié (seul le haut est visible, pas le bas). Mon jeu mélangeant des sprites de 16x16 (small) et 32x32 (large), j'imagine que c'est du à une contrainte à respecter dans l'endroit où tu charges les données graphiques de tes sprites.

En effet, au début je chargeait un fichier de sprites en 16x16, un autre en 32x32, et un troisième en 16x16, et ce dernier ne s'affichait pas. Depuis que je charge (via oamInitGfxSet()) mes deux fichiers de sprites 16x16 d'abord, puis celui de 32x32 ensuite, tous les sprites 16x16 sont visibles. Mais ceux de 32x32 sont toujours coupés sur deux émulateurs (sur ZSNES et la vraie SNES j'ai pas ce pb).

Quelqu'un aurait-il des idées sur la source potentielle de ce problème ?
Ou à défaut, quelqu'un saurait-il quelles sont les "règles" à respecter pour déterminer les adresses mémoire où charger les données graphiques de sprites dans la VRAM ?

Merci encore pour votre aide !

[F.L]

concernant ton bug ,je pense que le plus important c'est que cela fonctionne bien sur ta snes. l'inverse aurait été plus embettant !

[hoit]

Hello tout le monde,

Content de trouver ce topic récent qui parle de pvsneslib :)
J'aimerais aussi développer avec cette lib mais j'ai pas mal de questions et de points qui sont encore flou.

Tout d'abord, merci pour le folder contenant toute l'install: je viens de le comparer avec le miens (car je n'utilise pas la dernière version) mais j'ai l'impression qu'il ne s'agit pas de la dernière non plus. Quand on regarde sur le site portabledev, le tuto jour 3 sur les sprites indique cette signature pour mettre une image en vram :
oamInitGfxSet(&gfxpsrite, (&gfxpsrite_end-&gfxpsrite), &palsprite, 0, 0x4000, OBJ_SIZE16);
mais celle de ton install (et de la mienne) attend un paramètre supplémentaire (la taille de palsprite) :
oamInitGfxSet(&gfxpsrite, (&gfxpsrite_end-&gfxpsrite), &palsprite, (&palsprite_end-&palsprite),0, 0x4000, OBJ_SIZE16);
Y a-t'il une version encore plus à jour ?

Pour mes 1ères lignes de code, j'ai voulu afficher un sprite de 32*32 que j'ai dessiné sous paint.
Je le charge avec :
oamInitGfxSet(&snakehead, (&snakehead_end-&snakehead), &snakeheadpal, (&snakeheadpal_end-&snakeheadpal), 0, 0x4000, OBJ_SIZE32);
puis oamSetEx(0, OBJ_SMALL, OBJ_SHOW); et enfin je l'affiche dans la boucle avec oamSetXY(...).
=> L'image ne correspond pas à ce que j'ai dessiné (et le résultat à l'écran est différent entre ton folder d'install et le miens).
Du coup pour bien comprendre, quel est l'intérêt de la palette et que contient-elle ?
Comment savoir à quelle adresse je dois écrire l'image en vram (le 0x4000) et d'où vient cette valeur ?

J'ai besoin de tirer un nombre aléatoire entre 2 valeurs, la lib ne propose qu'une fonction random sans arguments.
J'ai donc inclus stdlib.h puis
srand(time(NULL));
const int MAX = 100, MIN = 1;
int randomvalue = (rand() % (MAX - MIN + 1)) + MIN;
Le compilateur indique malgré tout "warning: implicit declaration of function 'srand'" (alors que l'include est bien fait).
Quelles libs C peut-on utiliser avec du code snes ?
Pour le nombre aléatoire, j'ai trouvé la réponse page précédente :
=> rand() & 3

La vitesse d'animation à l'écran est trop rapide (par exemple dans l'exemple de sprite animé ou de mario), comment ralentir le framerate proprement ?

Y-a-t'il une fonction pour nettoyer l'écran quand il y a du texte pour qu'il ne s'affiche plus sans avoir à repasser dessus ?

Enfin, une dernière question mais pas des moindres : comment faites-vous pour debugger le code ? Le debugger de no$sns est assez obscure...

Merci d'avance :)

[F.L]

Salut hoit et bienvenue au  club 
Alekmaul a dit recemment qu'il mettrait a jour pvsneslib. Il manque dd temps libre en ce moment. Esperons qu'il en trouve pour la fin d'année !
Pour tes questions, j'ai mis entre parentheses le dev sur snes pour qq semaines,il faut que j'optimise mon code,  alors je n'ai plus les codes en tete, desolé. Si qq d'autre ici peut lui repondre, ça serait sympa
A+

[hoit]

Merci :) pas de soucis, je vais attendre bien gentillement et je poursuis mes tests demain !
Bonne soirée


Allez je complète un peu le post précédent après quelques tests.
J'ai lu sur la page précédente que pour obtenir un nombre aléatoire entre 0 et 4, on peut faire un rand() % 4 mais que ce n'est pas optimisé.
Je viens de tester la solution de contournement proposé : rand() & 3 et ca retourne des valeurs entre 0 et 3. Evidemment en mettant rand() & 4 ca donne pas une valeur entre 0 et 4...
Par contre si je le fais en version modulo : consoleDrawText(1,1,"Random value=%u",rand()%4);
la fenêtre no$sns perd immédiatement le focus et repasse sur le debugger.
A quoi est-ce lié ?

Au cas où quelqu'un a le temps de regarder au moins pour le problème d'affichage de sprite, j'ai fais un code minimal qui montre le problème :
s000.tinyupload.com/?file_id=52344458183847874266

[drludos]

De mon coté aussi, pas eu le temps de continuer le dev depuis 15 jours. Je me suis remis un peu sur mon projet ce weekend, et je bute sur un nouveau chapitre : le son !

Pour faire simple, j'ai du mal à comprendre comment fonctionne le système audio de PVSnesLib. En prenant les exemples, j'arrive bien à jouer un son (la musique on verra plus tard, je commence par les sons), avec les commandes suivantes :

Code:


extern char shootSFX,shootSFX_end; //adresse du début et de la fin du fichier son au format BRR dans la rom, spécifié dans data.asm

//Variable utilisée pour stocker les params du son (brrsamples et un "struct" de la lib)
brrsamples SFXshoot;

//Charge le son en mémoire et sauve les params dans la struct associée
spcSetSoundEntry(15, 8, 6, &shootSFX_end-&shootSFX, &shootSFX, &SFXshoot);

//Joue le son chargé en mémoire
spcPlaySound(0);

Ce code marche, ce qui est super cool. Malheureusement, je n'arrive à jouer qu'un seul effet sonore à la fois ! En effet, pour jouer d'autres sons, j'ai remis ces mêmes lignes, en changeant le son "source" :

spcSetSoundEntry(15, 8, 6, &explosionSFX_end-&explosionSFX, &explosionSFX, &SFXexplosion);
spcPlaySound(0);

Problème : chaque nouveau son joué remplace instantanément l'autre, il n'y en a donc qu'un seul qui se joue à la fois. La SNES possède plein de voies sonores, mais je ne sais pas comment y accéder .

En regardant le code source de la librairie (/include/sound.h), je vois les fonctions :

Code:

/*! \fn  spcLoadEffect(u16 sfxIndex)
 \brief load sound effect into sm-spc. this function may take some time to execute
 \param sfxIndex sfx_id
*/
void spcLoadEffect(u16 sfxIndex);

/*! \fn  spcEffect(u16 pitch,u16 sfxIndex, u8 volpan)
 \brief Play sound effect (load with spcLoadEffect)
 \param pitch pitch (0-15, 8=32khz)
 \param sfxIndex effect index (0-15)
 \param volpan volume(0..15) AND panning(0..15) (volume*16+pan)
*/
void spcEffect(u16 pitch,u16 sfxIndex, u8 volpan);

Elle m'ont l'air adaptées à mon cas (chargement de plusieurs effets pour ensuite jouer l'effet sonore X en précisant son index). Mais je ne sais pas comment charger plusieurs effets sonore dans la mémoire !

En effet, la fonction "spcLoadEffect" prend elle aussi un index comme seul paramètre, je ne sais donc pas comment "charger" plusieurs effets sonore au format BRR depuis la ROM.

Quelqu'un a des pistes à ce sujet ?

@hoit: je regarde ton code pour voir si je peux t'aider avec mes maigres connaissances

[drludos]

Quelques éléments dont j'ai déjà la réponse (enfin, je crois :p)

Tout d'abord, merci pour le folder contenant toute l'install: je viens de le comparer avec le miens (car je n'utilise pas la dernière version) mais j'ai l'impression qu'il ne s'agit pas de la dernière non plus. Quand on regarde sur le site portabledev, le tuto jour 3 sur les sprites indique cette signature pour mettre une image en vram :
oamInitGfxSet(&gfxpsrite, (&gfxpsrite_end-&gfxpsrite), &palsprite, 0, 0x4000, OBJ_SIZE16);
mais celle de ton install (et de la mienne) attend un paramètre supplémentaire (la taille de palsprite) :
oamInitGfxSet(&gfxpsrite, (&gfxpsrite_end-&gfxpsrite), &palsprite, (&palsprite_end-&palsprite),0, 0x4000, OBJ_SIZE16);
Y a-t'il une version encore plus à jour ?

Je pense au contraire que ta version est plus à jour que celle du site : le tuto date de 2012 sauf erreur de ma part. Ma version aussi, comme la tienne, attends en paramètre la taille de la palette, et je pense que c'est la version la plus récente.
D'ailleurs, c'est un ajout intéressant, car tu peux ainsi charger plusieurs "planches de sprites" et plusieurs palette d'un seul coup avec cette fonction : il suffit de mettre le "palsprite_end" à la fin de ta série de fichier palette dans le data.asm.

Sans cela, il faudrait charger les palettes une par une avec des "dmaCopyCGram()" (car tu ne peux avoir qu'un seul "oamInitGfxSet()" dans ton fichier).

Pour mes 1ères lignes de code, j'ai voulu afficher un sprite de 32*32 que j'ai dessiné sous paint.
Je le charge avec :
oamInitGfxSet(&snakehead, (&snakehead_end-&snakehead), &snakeheadpal, (&snakeheadpal_end-&snakeheadpal), 0, 0x4000, OBJ_SIZE32);
puis oamSetEx(0, OBJ_SMALL, OBJ_SHOW); et enfin je l'affiche dans la boucle avec oamSetXY(...).
=> L'image ne correspond pas à ce que j'ai dessiné (et le résultat à l'écran est différent entre ton folder d'install et le miens).
Du coup pour bien comprendre, quel est l'intérêt de la palette et que contient-elle ?

Alors, je viens de regarder tes fichiers. Ton code m'a l'air OK, par contre, c'est ton fichier image qui a un problème : c'est un BMP en 256 couleur. Or, sur SNES les sprites sont de 16 couleurs au maximum. En plus, il faut forcément que la couleur transparente (le violet donc) soit la couleur 0 de ta palette.

N'utilise pas Paint, il génère des fichiers que la librairie ne peut pas traiter ensuite (en 256 couleurs avec un palette système windows). Personnellement, j'utilise GraphicsGale, qui te permet de facilement manipuler les palettes (en plus d'être un super logiciel de PixelArt) :
https://graphicsgale.com/us/

Le fichier .pal contient donc une "traduction" de la palette de ton fichier .bmp au format d'image de la SNES. La lib te fait ça toute seule, mais il faut quand même respecter deux conditions :
- Lui fournir des bmps de 16 couleurs maximum
- Que la couleur 0 de ta palette soit la couleur transparente.

Comment savoir à quelle adresse je dois écrire l'image en vram (le 0x4000) et d'où vient cette valeur ?

Pour le 0x4000, je tâtonne moi aussi. Mais, d'après ce que j'ai compris :

- La SNES à 64ko de mémoire vidéo. Les adresses mémoire vont donc de 0x0000 à 0xFFFF (64 ko).
Cette mémoire contient à la fois les tiles graphiques (patterns) et les tilemap. Tu est libre de choisir les endroit où tu envoie des données dans la mémoire (et donc de faire des bêtises :p)

- Pour bien faire, l'adresse de "début" de chargement des tiles, doit forcément être un multiple de 16ko. Donc ça te laisse uniquement comme choix :
- 0x0000 (0ko mais le système de texte de la lib se les attribue)
- 0x4000 (16ko: moi aussi je charge les sprite en 0x4000)
- 0x8000 (32ko)
- 0xC000 (48ko)

J'ai besoin de tirer un nombre aléatoire entre 2 valeurs, la lib ne propose qu'une fonction random sans arguments.
J'ai donc inclus stdlib.h puis
srand(time(NULL));
const int MAX = 100, MIN = 1;
int randomvalue = (rand() % (MAX - MIN + 1)) + MIN;
Le compilateur indique malgré tout "warning: implicit declaration of function 'srand'" (alors que l'include est bien fait).
Quelles libs C peut-on utiliser avec du code snes ?
Pour le nombre aléatoire, j'ai trouvé la réponse page précédente :
=> rand() & 3

Pour générer un nombre en X et Y, ton code est bon :
int randomvalue = (rand() % (MAX - MIN + 1)) + MIN;

Mais tu n'a pas besoin de srand() : la libraire initialise déjà le tirage aléatoire lors du "consoleInit()".

La vitesse d'animation à l'écran est trop rapide (par exemple dans l'exemple de sprite animé ou de mario), comment ralentir le framerate proprement ?

C'est simple, moi je fait un "compteur de frames", que auquel j'applique ensuite un modulo ou un bitmask pour ne bouger que toutes les 2 ou 4 frames.

Pour la SNES, la librairie dispose déjà d'un compteur de frame en interne : "snes_vblank_count" (un unsigned int16 je crois).

Pour bouger toutes les deux frames, tu fait donc :
if( snes_vblank_count % 2 ){
  //Bouge ton sprite
}

Tu peux mettre toutes les 3,4,5... frames pour un mouvement encore plus lent :)

Y-a-t'il une fonction pour nettoyer l'écran quand il y a du texte pour qu'il ne s'affiche plus sans avoir à repasser dessus ?

Si tu trouves, ça m'intéresse aussi :).

Enfin, une dernière question mais pas des moindres : comment faites-vous pour debugger le code ? Le debugger de no$sns est assez obscure...

Pour l'instant, je fais sans "débugger" : j'affiche les variables à l'écran via les fonctions d'affichage de texte de la lib. Ensuite, pour aller plus loin (inspecter la VRAM par exemple), j'ai utilisé le débuggeur de no$SNS, mais aussi un programme appelé vSNES, qui te donne plein d'infos à partir d'une savestate de ton jeu:
https://www.romhacking.net/utilities/274/

[drludos]

Alors, suite des aventures sur l'audio. J'ai écrit à Mukunda, l'auteur de la librairie SNESmod, qui est incluse dans PVSNESLib pour gérer la partie audio.

Il est très sympa et m'a répondu dans la foulée, malheureusement ça fait plus de dix ans qu'il a pas touché au code, et ne se rappelle plus le fonctionnement de sa libraire.

Il n'est même pas sur que la libraire gère le fait de jouer plusieurs effets sonores en même temps.

@Alekmaul, comment fais-tu donc dans tes jeux pour jouer plusieurs sons à la fois (dans Sydney Hunter ou même dans Uwol par exemple) ?

[hoit]

drludos, un grand merci pour cette réponse :)
Ca donne déjà pas mal d'éléments, je vais tester les différents points et reviens prochainement !


Edit 1 :
"D'ailleurs, c'est un ajout intéressant, car tu peux ainsi charger plusieurs "planches de sprites" et plusieurs palette d'un seul coup avec cette fonction"
=> j'ai modifié data.asm pour obtenir cela :
snakehead:
.incbin "head.pic"
.incbin "body.pic"
snakehead_end:

snakeheadpal:
.incbin "head.pal"
.incbin "body.pal"
snakeheadpal_end:

Avec un appel à oamInit, je pensais voir en vram (avec no$sns) les 2 images mais il n'y en a aucune
oamInitGfxSet(&snakehead, (&snakehead_end-&snakehead), &snakeheadpal, (&snakeheadpal_end-&snakeheadpal), 0, 0x4000, OBJ_SIZE32);

Si je reviens à la méthode plus "classique" (chaque image a sa section dans data.asm), j'ai :
oamInitGfxSet(&snakehead, (&snakehead_end-&snakehead), &snakeheadpal, (&snakeheadpal_end-&snakeheadpal), 0, 0x4000, OBJ_SIZE32);
oamSet(0,  100, 100, 3, 0, 0, 0, 0);
oamSetEx(0, OBJ_SMALL, OBJ_SHOW);
oamSetVisible(0, OBJ_SHOW);

dmaCopyVram(&snakebody, 0x4000/2+(&snakehead_end-&snakehead)/2,(&snakebody_end-&snakebody));
oamSet(4,  132, 132, 3, 0, 0, 0, 0);
oamSetEx(4, OBJ_SMALL, OBJ_SHOW);
oamSetVisible(4, OBJ_SHOW);

J'ai bien 2 images en vram d'après l'émulateur, mais c'est 2 fois la même (celle chargé avec oamInitGfx).
www.portabledev.com/smf/index.php?topic=313.0
Je me suis inspiré de ce que j'ai lu sur le forum francais de la lib mais je ne comprends pas pourquoi l'image n'est pas la bonne et pour quelles raisons les adresses sont divisées par 2. (le résultat est identique en chargeant par exemple la 2eme image en 0x8000).



Autre question : les caractères de la lib vont des codes ascii 32 à 127. Si j'ai besoin de caractères accentués, y-a-t'il une solution ?


Je reste preneur de toutes infos complémentaires :)

[drludos]

Je remonte ce sujet car j'ai continué (très lentement...) a avancer sur mon projet. J'espère vous en parler bientôt dans un post dédié.

*Le son sur SNES*
Finalement, après avoir demandé de l'aide sur le forum anglais SNESdev, sur lequel trainent pas mal de spécialistes, j'ai réussi à dépatouiller mes problèmes de sons. Pour ceux qui s'attaquent au son via PVSNESlib (et donc la librairie SNESmod) je confirme que:

• Si on utilise les fonctions de "streaming de son", on ne peut jouer qu'un seul son à la fois (en plus de la musique). La fonction spcPlaySound est une fonction de streaming.
  
• Pour avoir deux "voies" pour jouer des effets sonores, il faut utiliser les fonctions qui ne font pas du streaming de son (le son est stocké en entier dans la RAM du SPC700). La fonction spcEffect est une fonction pour jouer un son sans streaming.
  

Là où ça se complique, c'est que le fait de convertir des sons "WAV" en "BRR" (comme le montrent les exemples de PVSNESlib) ne marche qu'avec les fonctions de streaming. Pour jouer des sons via spcEffect, il faut tout simplement les encapsuler dans un fichier "IT" (module musical), en tant que samples, et les convertir comme une "musique" et non comme un son. Le son sera alors chargé dans la mémoire du Spc via une fonction dédiée (spcLoadEffect), puis jouable avec spcEffect. Merci beaucoup à KungFuFurby du forum SNESdev pour m'avoir aidé à comprendre tout cela, car aucune documentation ne l'explique (et même l'auteur de SNESmod ne savait plus s'en servir).

Donc maintenant, pour l'aspect sonore de mon jeu, c'est bon.


*Problème : répartition du code source sur plusieurs ROM banks*


Cependant, je rencontre à présent un nouveau problème : le code de mon jeu est trop gros !
Pour faire simple, mon jeu fait environ 2000 lignes de code à présent. Suite au dernier code que j'ai ajouté, la rom "freeze" maintenant dès qu'elle doit jouer un son. D'après les experts sur le forum SNESdev ça serait lié au fait que mon code dépasse la capacité d'une "bank" dans la rom (soit 32ko), et que le compilateur n'arrive pas à "couper" mon code sur deux "bank". Et comme le code qui gère le son se trouve à la fin du code source, il ne "rentre pas en entier", et donc quand je l'appelle, ça plante (car oui, on peut planter une SNES :p)

Pour l'instant, mon code est compris dans un seul fichier .c. Mais, il est organisé en plusieurs "fonctions" différentes, afin de permettre justement au compilateur de couper le code facilement entre plusieurs "banks" - mais visiblement ça ne suffit pas.

Est-ce que l'un d'entre vous aurait une solution pour palier à ce problème?

J'avais par exemple pensé à essayer de diviser le code en plusieurs fichiers .c, est-ce que cela peut permettre au compilateur de la PVSNESlib (tcc816 + WLA-DX) de bien répartir mon code sur plusieurs "bank" de la rom ?

@Alekmaul: toi qui a fait des jeux denses, quelle est la méthode pour éviter ce problème?

Merci pour vos lumières !

[Invité]

Je remonte ce sujet car j'ai continué (très lentement...) a avancer sur mon projet. J'espère vous en parler bientôt dans un post dédié.

@Alekmaul: toi qui a fait des jeux denses, quelle est la méthode pour éviter ce problème?

Merci pour vos lumières !

Oui, le SDK ne sait pas gérer des fichiers supérieur à 32Ko et il faut hélas, faire le travail soi même pour saucissonner le tout .
Il fait le travail lui même de répartir dans différentes banks, et si ça rentre pas, faut augmentr la taille de la rom dans le ficheir hdr.asm

Code:

.ROMBANKS 8                    ; 2 Mbits - Tell WLA we want to use 8 ROM Banks

...

  ROMSIZE $08                  ; $08 = 2 Mbits,  see WLA doc for more..



Idem pour le graphique et music.

Pour les musiques, aussi, attention, elles doivent être dans des banks qui sont à la suite des autres et déclarées comme cela par exemple si on a une musique > 32 ko, 64Ko dans mon exemple de fichier data.asm  :

Code:

; --------------------------  Sound + Music
.bank 5
.section "SOUNDBANK0" ; need dedicated bank(s)

__SOUNDBANK__0:
.incbin "soundbank.bnk" read $8000
.ends

.bank 6
.section "SOUNDBANK1" ; need dedicated bank(s)

__SOUNDBANK__1:
.incbin "soundbank.bnk" skip $8000 read $8000
.ends


[Invité]

Salut, sympa de voir qu'il existe un lib pour développer sur SNES, par contre je suis pas fan pvsneslib. Je trouve qu'on est trop loin de qualité et la simplicité du SGDK de Stef, après peut-être que c'est une question d'habitude.

pvsneslib est en quel langage, je n'ai pas reconnu le C ...

[drludos]

@Alekmaul: merci beaucoup pour ta réponse !

Pour la répartition des graphismes et du son, j'ai déjà fait ça manuellement via data.asm (j'ai deux banks de graphismes, une pour les BRR, et une autre pour la soundbank). Par contre, comment peut-on saucissonner manuellement le code dans deux banks?

Sauf erreur de ma part, les "banks" liées au code ne sont pas déclarées dans data.asm, donc comment dire au SDK "met moi telle partie de mon code dans la bank0, et le reste dans la bank1" ou un truc du genre?

Merci encore pour ton aide!


@shingosama: PVSNESLib est un super SDK, surtout étant donné que la SNES est une machine bien plus difficile à programmer que la Megadrive (surtout en C). Le SDK est en C, mais effectivement il y a un ou deux petits fichiers de config qu'il faut rédiger en ASM, mais heureusement Alek fourni déjà des exemples prêt à l'emploi, tu n'as donc qu'à les modifier si besoin :). Si tu veux faire un petit break du développement MD, n'hésites pas à télécharger l'archive du SDK "clé en main" que F.L. a posté dans les premières pages de ce topic, et à regarder l'exemple "LikeMario" pour voir un exemple de petit jeu codé avec ce kit.

[drludos]

Ok, j'ai finalement réussi à résoudre mon problème (et il était coton celui-là !).

Alors, en fait, le code est bien "coupé" automatiquement dans PVSNESlib. En gros, le code en C est transformé en code ASM par tcc816. Et, afin de permettre le "saucissonnage" du code dans la rom (qui ne possède que des banks de 32ko), tcc816 va automatiquement encapsuler chaque fonction du code C dans une ".section" en code ASM, avec l'attribut "superfree".

Ainsi, quand WLA-DX va assembler et linker ce code ASM pour en faire une rom, il sera libre d'organiser comme il le souhaite chacune de ces ".section" (c'est à ça que sert l'attribut "superfree" : le linker est libre d'arranger chaque section comme il veut). Dans ce cas, WLA-DX procède de manière très simple : il place d'abord les plus grosses ".section" dans la rom, en commençant par la bank 0. Il remplit ensuite les éventuels "trous" avec les plus petites ".section" si besoin.

Dans mon cas, à force de rajouter du code au jeu, je commençais à avoir pas mal de code, dont certaines fonctions étaient assez grosses (j'ai environ 2 banks et demi de code pour l'instant). C'est là qu'arrive SNESmod, la libraire utilisée par PVSNESLib pour gérer le son. Il se trouve que la libraire SNESmod ne fonctionne bien que si son code est stocké dans la bank 0 de la rom. Si elle se trouve dans une autre bank (1, 2, etc.) les fonctions "non streaming" (musique) marcheront, mais la fonction de streaming d'effet sonore fera planter la SNES (elle engendre une boucle infinie).

Or, dans PVSNESlib, la libraire SNESmod est elle aussi stockée dans une ".section superfree", ce qui fait que le linker peut la placer là ou il veut. Pour mon jeu, après l'ajout d'une nouvelle grosse fonction dans mon code, elle "piquait" la place restante dans la bank 0 à la section de SNESmod, car la taille totale du code de ma fonction devait finalement dépasser la taille totale du code de SNESmod. Faisant ainsi planter mon jeu !

Pour résoudre ce problème (le plus dur était de le trouver), je modifie simplement "à la main" le code ASM généré par tcc816, afin de forcer les plus grosses fonctions du code de mon jeu à être stockées dans des rombank > 0, pour laisser suffisamment de place libre dans la bank 0 afin que le code de SNESmod y soit stocké par le linker. J'ai même fait un petit script python pour automatiser le process :).

Du coup, je peux enfin continuer à rajouter du code dans mon jeu sans avoir peur de tout faire crasher - ça à l'air bête comme ça, mais je suis hyper content d'avoir enfin trouvé une solution à ce pb. Merci à vous tous (ainsi qu'aux membres du forum SNESdev) pour votre aide dans la correction de ce gros bug).

@Alekmaul: Quand tu aura l'occasion d'une prochaine MAJ de la lib, un moyen simple de corriger ce bug serait de déclarer le code de SNESmod pas en "superfree" mais de le stocker dans la bank 0, ça résoudrais tout problème à l'avenir (car là pour l'instant il faut déclarer manuellement chacune des fonctions de son projet pas en "superfree" pour éviter qu'elles aillent en bank 0 si on veut éviter ce bug).

Merci en tout cas pour ton aide, et pour avoir créé cette super librairie au départ !
SGDK n'a qu'à bien se tenir !

[Invité]

Je suis étonnais du fait que la bank 0 soit 'sur utilisée'. C'est plus côté RAM que SNESMOD, effectivement, je l'ai fait pointé sur la mémoire la plus rapide, dans au début de la WRAM. Je vais regarder, mais vu le code généré par Sydney Hunter (y'en a pas mal), j'ai peur que ton problème ne soit pas là.
SI tu peux m'envoyer le code par PM, je vais regarder.
Merci par contre de ta motivation de dépoussiérer pvsneslib, ça fait plaisir

[Stef]

@shingosama> Le développement de PVSNESLib a quand même commencé nettement plus tard que SGDK (ça fait plus de 10 ans pour SGDK il me semble ^^) et surtout la SNES est aussi bien plus complexe à programmer que la MD. Déjà tu ne peux pas utiliser GCC ce qui est quand même une grande faciliter pour SGDK, ensuite tu as tout ce système de banque de mémoire qui est un vrai enfer à gérer avec un compilateur C.
En fait la SNES c'est compliqué car c'est une console de la génération 16 bits donc on attends des jeux à un niveau "16 bits" dessus (avec plus de data et de code qu'un jeu 8 bits) mais tu as des contraintes de développement quasiment du niveau d'une machine 8 bits (mémoire par banque de 32K, utilisation des instructions 8 bits quand c'est possible pour accélérer le traitement, support C assez pauvre) 

[Invité]

Oui, tu as raison @Stef. Et ne pas avoir des nombres sur 32bits, ça demande de la gymnastique au cerveau dans certains cas ...

[drludos]

Je suis étonnais du fait que la bank 0 soit 'sur utilisée'. C'est plus côté RAM que SNESMOD, effectivement, je l'ai fait pointé sur la mémoire la plus rapide, dans au début de la WRAM. Je vais regarder, mais vu le code généré par Sydney Hunter (y'en a pas mal), j'ai peur que ton problème ne soit pas là.
SI tu peux m'envoyer le code par PM, je vais regarder.
Merci par contre de ta motivation de dépoussiérer pvsneslib, ça fait plaisir

Alors visiblement, ce serait plutôt lié à un bug de SNESmod.

Après avoir posté ma "solution" décrire aussi sur le forum SNESdev, KungFuFurby a trouvé la véritable origine du problème, un bug dans la gestion du streaming par SNESmod. Voici la correction qu'il propose :

A la ligne 1073:

Code:

lda digi_rates.w, x

Remplacer cette ligne par

Code:

lda.l digi_rates, x

(ou celle là peut marcher aussi)

Code:

lda digi_rates.l, x

source: https://forums.nesdev.com/viewtopic.php?f=12&t=17002&p=213441#p213334

A l'occasion, est-ce que tu pourras éventuellement appliquer ce patch à la PVSNESlib ?

En tout cas, merci à toi de tout le boulot que tu as déjà fait, car la lib permet vraiment à des débutants (comme moi) d'arriver à faire un petit jeu Super Nintendo, ce qui est rêve de gosse :). Quand on voit ce qu'il y avait avant ta lib (ASM obligatoire, rien de bien concret pour le son, outils de transformation d'images peu fonctionnels, etc.), j'imagine même pas le nombre d'heures que tu as du passer pour coder tout ces outils et ce framework de code ASM et C !

[Invité]

OK, je regarde tout cela ce week end. Merci à toi d'avoir fait progresser la lib !

[Invité]

OK, dispo ici, vous avez aussi le changelog

https://github.com/alekmaul/pvsneslib/wiki/Download

Et j'ai commencé un wiki comme celui de Stef pour SGDK (y'a pas de raison ^^) https://github.com/alekmaul/pvsneslib/wiki

Si quelqu'un veut aider, je suis plus que plus que preneur !