Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Une fois les ressources modifiées, en général je modifie TRES souvent mes ressources ! Donc, faut être patient ...

[Tryphon]

Ou alors tu ne compresses pas tes ressources en phase beta ?

[Invité]

Soucis trouvé !

Il s'agit des anti-malwares/Anti-virus qui à chaque appel de Java, vont traiter et vérifier que tout est Ok.
En désactivant l'un d'eux ( MalwaresBytes Anti-Exploit ), je tombe à 1mn !! Youpi !! 

[JoanCZ]

Rebonjour,

Alors j'ai beau essayer, mais le code :

Code:

#include <genesis.h>
#include "sound.h"


int main()
{
    // disable interrupt when accessing VDP
    SYS_disableInts();
    // initialization
    VDP_setScreenWidth320();
    VDP_drawText("TEST MUSIQUE", 10,10);
    // start music
    XGM_startPlay(joan_music);
    // VDP process done, we can re enable interrupts
    SYS_enableInts();

   
   while(TRUE)
    {
      VDP_waitVSync();
    }

    return 0;
}

ne marche vraiment pas.... comme dit dans mes postes précédent, écran noir...
(mon vgm est celui de la démo sonic présente dans la sgdk

si quelqu'un peut essayer et voir ce qui va pas  


merci d'avance.

[fourchette]

en faisant ce qui suit ça marche mais je ne comprends pas pourquoi :

Code:

while(TRUE)
{
    XGM_isPlaying(); //FIX
    VDP_waitVSync();
}

[fourchette]

Depuis la dernière version du SGDK (peut être l'avant dernière aussi mais je n'ai pas testé), mon boot/rom_head.c est écrasé à chaque compilation, est ce je suis le seul à qui cela arrive ?

En attendant j'ai modifié le makefile.gen du SGDK comme suit :

Code:

$(SRC)/boot/rom_head.c: $(LIBSRC)/boot/rom_head.c
#    $(CP) $< $@
    if [ ! -f $@ ]; then $(CP) $< $@; fi;

[Stef]

J'essai de répondre aux divers problèmes rencontrés, désolé j'ai été déconnecté quelques temps...

@JoanCZ>
J'ai essayé de refaire le même exemple que toi et je n'ai pas de soucis particulier, à noter que je teste avec Gens ou Kega, tu m'as pas dit si tu avais le soucis sur la vraie MD ou pas ? Aussi tu as essayé avec un autre fichier VGM ?

@Vetea>Alors pour le soucis de compilation des ressources qui prend du temps, effectivement la compression ajoute pas mal de temps de compilation puisque les ressources sont (re)compressées à chaque modifications de celle-ci, une solution est de séparer en plusieurs fichiers .res histoire de ne recompiler que les fichiers modifiés  Je vois que tu as déjà réussi a pas mal accélérer le process en désactivant un de tes anti malware

@fourchette>je n'arrive pas à reproduire ton problème. En fait tu dois avoir une configuration assez étrange qui fait que make ne détecte pas correctement ton fichier ($SRC)/boot/rom_head.c du coup il l'écrase toujours avec celui inclus dans la lib... d'ailleurs c'est étrange car en ajoutant la condition d'existence avant tu élimines le problèmes, normalement tu ne devrais pas avoir besoin de ça

[fourchette]

Je n'ai pas été très explicite, mais j'ai rencontré le même problème que JoanCZ, avec différents VGM et sur 4 émulateurs dont mednafen et blastem. A priori ça se passe au niveau de la fonction XGM_startPlay qui bloque. J'ai résolu ça avec le bout de code indiqué sans comprendre pourquoi.

Concernant le problème du rom_head.c lors de la compilation, j'ai testé la commande cp manuellement et, effectivement, il écrase le fichier de destination bien qu'il existe déjà. Je suis plutôt étonné que ça ne l'ai pas fait dans les versions antérieures du SGDK, d'après sa documentation, ça semble être le comportement normal de cp.

Note : je travaille sous Win7 x86

[JoanCZ]

Bonjour,

Stef, pour info, je lance mon code sous Gens et également sur une vraie Megadrive, et ça plantait systématiquement...
Du coup fourchette a trouvé la solution, XGM_isPlaying(); règle bien le problème :)

merci ^^

[Stef]

Merci pour vos retours ! je vais investiguer ce problème de XGM_startPlay(..) suivi d'une boucle while() avec un waitVSync... c'est louche, surement un problème de synchro (init Z80 et accés VDP, je ne sais pas).

@fourchette> c'est normal que le cp fait la copie, ce qui n'est pas normal c'est que la commande en elle même soit executée :

$(SRC)/boot/rom_head.c: $(LIBSRC)/boot/rom_head.c

Normalement cette ligne signifie que pour produire le fichier $(SRC)/boot/rom_head.c alors tu as besoin de $(LIBSRC)/boot/rom_head.c mais en théorie 'make' exécute la commande uniquement si le fichier destination $(SRC)/boot/rom_head.c n'existe pas où si la dépendance $(LIBSRC)/boot/rom_head.c a été modifiée. Théoriquement si ton fichier est déjà là alors aucune des 2 conditions n'est rencontrée.. c'est ça que je ne comprends pas

[fourchette]

J'ai résolu mon problème pour le rom_head.c. J'utilisais celui fourni avec SGDK 1.22a qui diffère de celui du SGDK 1.30. En ajoutant la ligne manquante __attribute__((externally_visible)) devant la structure, plus de problème d'écrasement lors de la compilation. Par contre, je ne comprends pas en quoi cela influt sur le fait que le fichier soit écrasé ou pas...

[Invité]

Coucou !!

J'aurai une question concernant la fonction : XGM_setLoopNumber (s8 value)

Une fois que l'on joue notre musique (XGM_startPlay()), faut il mettre la fonction dans la boucle principale ou avant celle ci ?
Merci.

[Stef]

@fourchette> Je dois admettre ne pas bien comprendre pourquoi le fichier était systématiquement écrasé non plus, théoriquement ça devrait servir juste à l'optimiseur de GCC :-/

@vetea> Tu dois utiliser XGM_setLoopNumber(s8 value) *avant* de jouer lancer la musique, si tu l'utilises après le loop n'est pas garanti !

[Invité]

Super merci Stef !
Moi j'avais fait l'inverse !

[Invité]

Je reviens à la charge, et je poste ici, peut être que ma question pourra aider.
Donc, toujours concernant l'histoire du Loop.

En fait, je n'ai pas saisi la subtilité de la fonction.
Voici mon code type :

Code:

Void Musique()
{
    // Loop ?
   XGM_setLoopNumber(-1);
   XGM_startPlay(MenuMusic);
}


Donc, pour assurer efficacement le "Loop" de ma musique, il faut que je mette cette fonction dans la boucle principale ?

Code:

while(TRUE)
{
 ...
if (!XGM_isPlaying()) Musique();
 ...
}

Car avant la boucle, la musique ne va pas se reboucler.
Donc autant se passer de cette fonction, ça marche aussi bien ...
D'ou l'intérêt d'une telle fonction, à moins que ce soit moi qui l'utilise mal.

Merci !

[Stef]

Attention, la méthode XGM_setLoopNumber(..) ne fonctionne que si la musique a une instruction "loop" (pour savoir à quel endroit on loop dans la musique). Si la musique n'a pas de loop à la fin alors cette fonction ne fera rien et tu devras utiliser ton morceau de code pour looper manuellement :

Code:

if (!XGM_isPlaying()) Musique();

Si le loop est présent alors pas besoin de ça, ça loopera automatiquement =)

[Invité]

Ahhhh ok !! Merci !

[Invité]

Stef, suite ànotre discussion à la RGC sur mon problème de sprites mal raffrahis sur l'écran.
Je suis sur la dernière version de SGDK, la 1.1.
Et j'ai retesté quelques trucs pour mon pb de sprites.
Pour résumé, à l'heure actuelle, j'ai :

Code:

SPR_reset();
 SPR_clear();
 SPR_update();

Si j'enlève le reset, je vois les anciens sprites à l'écran, ils restent.
Et si j'ajoute un SPR_update(); j'ai quand même la rémanence des anciens sprites de l'écran précédent qui restent pendant une ou deux frames ...
Une idée ?
J'ai aussi passé ma routine d'update des maps en VBL grace au hook :

Code:

// Add callback for map refresh
 SYS_setVIntCallback(&myconsoleVblank);


mais cela ne change rien (mais ça marche toujours, c'est déjà ça ^^) ...
On le vois sur ce screenshot ou les sprites du titre restent malgré le reset / clear et update lors de l'init.

[troudki]

Quoi..STEF était à la RGC hier ????
sans passer sur le stand Z-team..

[Invité]

Meuh si, il était juste en face de toi, sur notre stand !
En tout cas, sympa ta prez troudki , j'ai bien aimé :)

[Stef]

Troudki> Rhhaa j'ai loupé beaucoup de choses cette année
C'est vous qui portez des classiques Amiga / Atari ST sur Megadrive ?? J'étais sorti manger et je suis revenu à la fin de la présentation (et donc j'ai pas tout cerné). Le problème c'est que je retiens mal (pas) les pseudos, puis j'avais pas assez dormi la veille :p j'étais vraiment en monde zombie cette année... Quel dommage, l'année prochaine faut vraiment que je prépare mieux ça

Alekmaul>
Je fais faire quelques tests mais juste pour être sur, tu es en version 1.31 tu veux dire non ?
Que les sprites restent c'est logique, par contre le SPR_clear() ça va juste modifier le link du sprite 0 pour effacer les autres sprites.
Par contre je me rends compte que si tu souhaites faire un vrai reset des sprites, il faut faire ainsi :
SPR_reset();
SPR_update();

Le SPR_clear() c'est pour effacer / cacher rapidement les sprites (sans faire de reset), au prochain SPR_update() tout se raffiche normalement
Je vais investiguer...

[Invité]

Alekmaul>
Je fais faire quelques tests mais juste pour être sur, tu es en version 1.31 tu veux dire non ?
Que les sprites restent c'est logique, par contre le SPR_clear() ça va juste modifier le link du sprite 0 pour effacer les autres sprites.
Par contre je me rends compte que si tu souhaites faire un vrai reset des sprites, il faut faire ainsi :
SPR_reset();
SPR_update();

Le SPR_clear() c'est pour effacer / cacher rapidement les sprites (sans faire de reset), au prochain SPR_update() tout se raffiche normalement
Je vais investiguer...

Oui, je suis en 1.31, le clavier a bouffé le 3 dans l'histoire ^^
reset + clear + update fait rien en tout cas, donc, j'attends ton avis avant de faire quelque chose

[Stef]

Je confirme qu'il y a un soucis à partir du moment ou tu rajoutes un sprite tout de suite derrière. Je vais continuer mon investigation..

[Stef]

@Alekmaul>
J'ai trouvé le problème... bon je ne peux pas corriger facilement ça mais c'est contournable. En fait ce qui se passe c'est que après ton reset & update, tu dois faire un (ou plusieurs) addSprite(..) qui intervient *avant* la prochaine interruption verticale qui devait mettre à jour les sprites (les effacer en l'occurence)...

Donc tu as plusieurs solutions :
- soit tu attends une frame après le reset/update (interruptions actives):
    SPR_reset();
    SPR_update();
    VDP_waitVSync();
    ....
    sprites[0] = SPR_addSprite(...)
- soit tu désactives les interruptions le temps de préparer tes sprites pour le prochain niveau :
    SPR_reset();
    SPR_update();
    ...
    SYS_disableInts();
    sprites[0] = SPR_addSprite(...)
    sprites[1] = SPR_addSprite(...)
    ....
    SPR_update();
    SYS_enableInts();

Normalement les 2 méthodes devraient corriger ton problème

[Invité]

OK Stef, merci de la recherche, je teste tout cela ce soir.
Mes SPR_reset & update sont déjà avec les interruptions désactivées, étrange ou alors cela vient de là.
Je tente sans désactiver les INT mais en ajouter une attente de VBL, je verrais bien :)

[Invité]

double post pour dire que :

Code:

   // Clear backgrounds & sprites
   SPR_reset();
   SPR_clear();
   VDP_waitVSync();

   SYS_disableInts();


est testé et approuvé, ça fonctionne nickel, plus de glitch de sprite rémanent sur l'écran !
Merci à toi Stef, je pars sur ce palliatif en attendant de voir si tu trouves une solution ou si juste tu mets une indication dans ton WIKI par rapport à ce pb

[Stef]

Bonne nouvelle, merci du retour :)

Bon je pense que ça sera peut être une indication quelque part (wiki ou autre) en attendant car le fix sera un pénible à implémenter...

[Stef]

@alekmaul> Bon j'ai trouve un moyen de fixer le problème pour de bon
Je n'ai pas encore fait de mise à jour officielle de SGDK mais si tu reprends le fichier vdp_spr.c (dans le répertoire src) sur github et que tu recompiles la librairie chez toi alors ça devrait corriger tout tes problèmes de "sprite ghosting" :) Et plus besoin de bidouiller avec les waitVSync()

[troudki]

Hello à tous..
Est ce que vous avez aussi archive corrompu sur la dernière version de SGDK sgdk131.7z récupéré de https://github.com/Stephane-D/SGDK/releases

[Invité]

@alekmaul> Bon j'ai trouve un moyen de fixer le problème pour de bon
Je n'ai pas encore fait de mise à jour officielle de SGDK mais si tu reprends le fichier vdp_spr.c (dans le répertoire src) sur github et que tu recompiles la librairie chez toi alors ça devrait corriger tout tes problèmes de "sprite ghosting" :) Et plus besoin de bidouiller avec les waitVSync()

cool ça, thanks a lot !
Je teste dés que je peux, un peu à fond sur d'autres sujets en ce moment (comme un autre taf et une salle de cinéma chez moi http://www.portabledev.com/category/homecinema/ ) !

[Stef]

Hello à tous..
Est ce que vous avez aussi archive corrompu sur la dernière version de SGDK sgdk131.7z récupéré de https://github.com/Stephane-D/SGDK/releases

Pas de soucis de mon côté

@alekmaul> Sympa ta petite salle homecinéma à la maison... c'est triste d'habiter en région parisienne :-/