Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

ok, je vais faire cela, merci :)

[Invité]

Suite a une nouvelle méga géante du Brésil, il va être possible que je travaille sur une nouvelle version de Papi sur MD avec Sgdk ( pas Bex !!! )  ...
Du coup, ça sera plus simple côté portage Snes pour la suite.
Wait and see !
Je vous tiens au courant.

[Tryphon]

Barone ? Pyrone ?

[troudki]

Hello à tous..
quel est impact de la compression FAST ou BEST avec rescomp sous la version 1.3 pour les sprites et images ? Pourquoi le unpackBufferSize du SPR_init est limité à 256 tiles ?
La conversion de nos projets sous 1.3 marche un peu sur émulateur mais plante souvent sur console.

[Stef]

Que veux-tu dire par impact sous la version 1.3 ? Normalement c'est la même chose que pour les versions précédentes.
FAST = taux de compression moyen mais décompression rapide
BEST = meilleur compression possible mais décompression lente

La taille de unpackBufferSize est celle que tu spécifies et 256 tiles par défaut (si tu mets 0).
Utilisez-vous une version "custom" de la lib ? Ou vous êtes complètement passé sur SGDK 1.30 ?

[troudki]

pas de version custom de la lib. On est passé de la 1.12 à 1.3 en adaptant le nouveau sprite engine mais avec compression NONE tout s'affiche , avec compression FAST on ne voit que des sprites et pas les images sur les plans.
c'est quoi les valeurs max sur les paramètres d'init de sprites (SPR_init)?

[Stef]

Tout dépend de combien de sprites vous voulez afficher en même temps mais ça par exemple c'est possible mais c'est beaucoup :
SPR_init(80, 800, 768);

Je dirais que des valeurs classiques c'est plutot :
SPR_init(80, 400, 300);

Vous avez tant de (gros) sprites que ça à la fois à l'écran ?
Si les tiles des plans manquent, c'est que les sprites bouffent dessus (vous donnez trop aux sprites).

[Invité]

Y'a un truc que je comprends pas avec la gestion des joysticks.
J'ai fais ce code pour attendre l'appui sur START ou A, je ne sors jamais de la boucle while, une idée du pb. 1 seul waitVsync, c'est trop court peut être .. quand est effectuée la mise à jour des données du joystick ?

Code:

bOK=0;
 while (bOK==0) {
 // Get pad
 pad0 = JOY_readJoypad(JOY_1);
 
 // Wait for pad
 if ( (pad0 & (BUTTON_START | BUTTON_A)) ) {
  bOK=1;
 }
 
 VDP_waitVSync();
 }

[Tryphon]

Ça m'a l'air correct. Un VSYNC c'est largement suffisant. La mise à jour est immédiate (c'est un port en mémoire qui est lu), donc quand tu lis avec JOY_readJoypad c'est bon (le seul délai que tu dois respecter est quand tu dois lire 2 fois de suite le port en mémoire, par exemple pour avoir l'état des 6 boutons d'un pad 6 boutons, mais ce délai est très très court, beaucoup plus qu'à peu près n'importe quelle instruction C).

Mais comment sais-tu que tu sors ou pas de la boucle ? Ton code n'affiche rien dans la boucle, rien en dehors...

[Invité]

Je ne sors pas de la boucle car juste après j'ai un autre écran. Je n'ai mis que le code de l'attente d'une touche après affichage de mon écran.
J'ai continué de tester et en modifiant les optims de GCC de -O3 à -O1, ça passe dans tous les cas... étonnant non , GCC optimiserait il de trop   ?

[Tryphon]

Faudrait voir le code de JOY_readJoypad. Peut-être que GCC ne détecte pas que la valeur de retour peut changer (vu qu'on lit une adresse fixe, celle du port manette, qui est modifié extérieurement) et du coup zappe l'appel.

Si c'est le cas, c'est du ressort de Stef (certainement un volatile ou chais pas trop quel mot-clef à rajouter pour que GCC comprenne que ça peut changer).

[Invité]

Oui, dans joy.c de SGDK, joyState est déclaré uniquement en static et non en volatile. Est-ce que GCC a des problèmes en optim O3 dans ce cas là ?

[Hpman]

C'est un souci d'interface chaise-clavier 

Code:

bOK=0;
while(!bOK) {
   // Get pad
   pad0 = JOY_readJoypad(JOY_1);

   // Wait for pad
   if ( (pad0&BUTTON_START) || (pad0&BUTTON_A) ) {
      bOK=1;
   }
   VDP_waitVSync();
}

[Invité]

pké ? tu vois une connerie ^^

[Hpman]

J'ai corrigé le code, la tu testes un appui sur start et A.

[Invité]

bah non, vu que je teste pas la valeur et juste que c'est différent de 0, mon code marche aussi :)
donc pas de connerie dans mon code pour moi !

[Hpman]

Ah oui je suis pas réveillé 

La conclusion est donc: SORCELLERIE!

Plus sérieusement fait lui afficher la valeur de pad0 dans la boucle pour commencer.

Au passage tu peux faire l'économie de bOK:

Code:

do {
 VDP_waitVSync();
 pad0 = JOY_readJoypad(JOY_1);
} while(!(pad0&(BUTTON_START|BUTTON_A)));

[Invité]

LE pb, c'est que quand j'ajoute le KLog_U1("pad ",pad0), le code fonctionne en -O3, c'est pour cela que je penche effectivement sur un pb d'optim de GCC.
Bien vu pour bOK, on peut économiser cette variable.

[Hpman]

Mets un breakpoint dans exodus sur ta fonction attente et regarde ce que fout le CPU/les valeurs

Edit: sinon tente ça pour voir, je sais pas trop ce que le compilateur va en faire 

Code:

pad0 = (volatile u16)JOY_readJoypad(JOY_1);

[Invité]

Tu es sur que c'est joy_1 et pas joy_0 ??

tu devrais afficher le pad0 à l'écran pour voir sa valeur .

quand est effectuée la mise à jour des données du joystick ?

Normalement pendant le vblank de chaque frame .
Les ports de lecture des pads sont en général lents, donc tu le lis 1 fois (pendant le vblank), et tu stockes dans une variable/pad pour y accéder plus facilement et plus rapidement dans ta boucle principale .

[Invité]

Oui touko, certain du truc. Dans joy.h de SGDK on a cela :

Code:

#define JOY_1          0x0000
#define JOY_2          0x0001
#define JOY_3          0x0002
#define JOY_4          0x0003
#define JOY_5          0x0004
#define JOY_6          0x0005
#define JOY_7          0x0006
#define JOY_8          0x0007
#define JOY_NUM        0x0008
#define JOY_ALL 0xFFFF

Et comme indiqué, en -O1, cela fonctionne parfaitement même sur une vrai console.
Je penche plus sur le volatile qu'il faudrait utiliser dans la déclaration, je vais faire des tests.

[Stef]

C'est sur que c'est un problème d'opti et de volatile. GCC 6.3 optimise plus, surtout en -O3 et possible qu'un 'volatile' manque ici ou là (j'avais le soucis avec la variable vtime)...

Edit:
Bon entre temps j'ai regardé, et oui ce sont toutes mes variables d'états des joypad qui devraient être en volatile car je les modifie pendant sur le Vint.
Avec ta boucle, GCC inline le code, voit que joystate ne peut pas changer, il optimise le truc et boum !
Je vais corriger ça, entre temps il faudrait que tu le forces à casser son opti ou à passer à -O1.

[Hpman]

Ça passe pas avec  le cast (volatile u16) devant la fonction?

[Stef]

Ça passe pas avec  le cast (volatile u16) devant la fonction?

A essayer mais je n'y crois pas trop, je crains qu'il considère le résultat de la fonction comme volatile mais continuer à optimiser l'accès à joyState[] :-/

[Invité]

ET bien au moins, on a trouvé un fix à faire pour une nouvelle version de SGDK
Et je reste en O1 comme indiqué en attendant la nouvelle version

[Invité]

Juste pour info, à mon avis, il y a un bug dans le commentaire doxygen de la fonction VDP_drawImageEx du fichier vdp_bg.h.

Code:

 *  \param loadpal
 *      Load the bitmap palette information when non zero.
 *      Accepted values are:<br>
 *      0 = don't load palette.<br>
 *      1 = HIGH PRIORITY TILE.<br>
 *      0:

Le 1 me semble suspect :)

[Stef]

Nouvelle version de SGDK, à télécharger ici :
https://github.com/Stephane-D/SGDK/wiki/Download

Corrections de quelques bugs remontés ici même + ajout de flag 'always on top' pour qu'un sprite puisse toujours apparaitre au dessus des autres même lorsqu'on utilise le Y sort :)

[Invité]

Youpi !! Génial !!    

Merci Stef !!

[Invité]

J'ai du mal à saisir comment fonctionne VDP_setVerticalScrollTile par rapport à VDP_setHorizontalScrollTile.
Qu'est-ce que l'on doit déclarer comme tableau pour faire fonctionner le scrolling vertical uniquement sur une partie de l'écran ?

[Stef]

J'ai du mal à saisir comment fonctionne VDP_setVerticalScrollTile par rapport à VDP_setHorizontalScrollTile.
Qu'est-ce que l'on doit déclarer comme tableau pour faire fonctionner le scrolling vertical uniquement sur une partie de l'écran ?

Tu veux faire fonctionner le scrolling vertical juste sur une partie de l'écran ?
C'est possible sur MD mais je me demande pourquoi tu as besoin de ça avec ton portage sachant que sur SNES tu n'as pas cette capacité (pas directement en tout cas) ??

Tu as 3 modes de scrolling horizontal :
- plan complet
- scrolling par tile (bloc de 8 pixels)
- scrolling par ligne (chaque ligne a son propre scrolling)

La table de scrolling horizontal se trouve en VRAM et elle sera lu par le VDP selon le mode de scrolling :
- plan complet --> première entrée lue et appliqué à chaque ligne (table[0] appliqué à chaque ligne)
- tile --> 1 entrée sur 8 lues (table[0] appliqué aux lignes 0 à 7, table[8] appliqué aux lignes 8 à 15...)
- line --> 1 entrée pour chaque ligne (table[0] appliqué à ligne 0, table[1] appliqué à ligne 1...)

C'est la même logique pour le scrolling vertical sauf qu'il n'y a que 2 modes :
- plan complet
- scrolling par 2 tiles (bloc de 16 pixels)

Les fonction VDP_setVerticalScrollTile et VDP_setHorizontalScrollTile vont te permettre de mettre à jour une partie des tables de scrolling en VRAM à partir d'un tableau en mémoire centrale (que tu auras donc rempli toi même)  en considérant qu'on est en mode de scrolling tile. Il faut donc d'abord régler le mode de scrolling avec la méthode VDP_setScrollingMode(...).

[Invité]

Merci de ta réponse.
Pour le mode horizontal, j'avais bien compris comment faire. C'est le vertical qui me pose problème.
Qu'appelle tu "scrolling par 2 tiles" ?
Mon but est que le halo de lumière soit scrollé aussi bien en horizontal qu'en vertical quand Sydney saute.