Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Oui c'est clair que ça doit être un travail monstrueux.

Pour moi, l'une des manières d'encourager des personnes comme Stef, qui prennent beaucoup de leur temps, pour créer des outils permettant à des passionnés comme nous de créer des jeux sur des consoles rétros, c'est, en plus des remerciements qui sont important, le soutien par un Don ( https://stephane-d.github.io/SGDK/ ) !

C'est très motivant, ça encourage l'auteur à mettre à jour et améliorer son devkit et en plus, c'est aussi un des nerfs de la guerre ( sinon le seul !  )

En plus, Stef est vraiment l'une des personnes que j'aimerai rencontrer le plus à la prochaine RGC. Il est doué, humble, simple et toujours disponible pour aider, donner des conseils avec cette pédagogie si rare chez les "nymformaticiens".
Je le serrerai volontiers dans mes gros bras !

Le Graal, sera le prochain jeu crée avec SgdK qui sera édité en physique, la meilleure des publicités !!
Papi Commando Tennis fera partie de ces prochains jeux, ainsi que de nombreux d'autres, surtout COD d'AlekMaul.

Encore merci Stef !

[Stef]

C'est vraiment très sympa de ta part Vetea Moi aussi je regrette qu'on ai pu se rencontrer à la dernière PGR mais on se croisera tot ou tard à une de ces conventions et promis on se fera un gros hug virile
Comme je te disais je ne fais pas ça pour l'argent même si c'est toujours agréable recevoir un don (quelque soit sa valeur) car ça montre que les gens apprécient ce que tu fais et ça te motive encore plus à continuer Mais vraiment c'est secondaire, je prends beaucoup de plaisir à faire ça (heureusement) :) Merci encore pour ta générosité et ta gentillesse =) Et j'ai hâte de voir tes prochaines productions en sortie physique

[Tryphon]

J'avais jamais vu qu'on pouvait faire un don

[Stef]

C'est assez récent en fait... Je l'ai ajouté car une personne tenait vraiment à me faire un don pour mon travail et ne savait pas comment s'y prendre (il était américain), du coup paypal état la solution la plus simple (même si bien sur ils te taxent au passage :p)

[Tryphon]

C'est une bonne idée

[Invité]

Petites remarques, je ne sais pas si c'est normal.
En utilisant KMod, dans les messages debug, je vois cela que je ne voyais pas avant : normal sans utiliser la librairie en mode débug ?

Code:


Message : MEM_init: heap = 16730574
Message : SYS_disableInts() info: inner call
Message : SYS_enableInts() info: inner call
Message : SYS_disableInts() info: inner call
Message : SYS_enableInts() info: inner call

Aussi, il semble que le premier sprite soit toujours réservé, en 0x0 et de taille 8x8, normal aussi ?


Et bon anniv Stef, si j'en crois le forum

[Invité]

J'avais jamais vu qu'on pouvait faire un don

Eh ,c'est un don en € hein,pas de ton corps 

[Tryphon]

Il sait pas ce qu'il perd

(enfin moi, je sais... Je pense qu'il préférera des € )

[TotOOntHeMooN]

Un euro contre un neuro !

[Invité]

Il sait pas ce qu'il perd

(enfin moi, je sais... Je pense qu'il préférera des € )

C'est beau la dévotion 

[Stef]

Petites remarques, je ne sais pas si c'est normal.
En utilisant KMod, dans les messages debug, je vois cela que je ne voyais pas avant : normal sans utiliser la librairie en mode débug ?

Code:


Message : MEM_init: heap = 16730574
Message : SYS_disableInts() info: inner call
Message : SYS_enableInts() info: inner call
Message : SYS_disableInts() info: inner call
Message : SYS_enableInts() info: inner call

Aussi, il semble que le premier sprite soit toujours réservé, en 0x0 et de taille 8x8, normal aussi ?

Oui tout ça est normal, en mode debug tu as quelque informations qui sont loggués dans la console pour t'aider à débugger
Les SYS_disableInts() / SYS_enableInts() "inner call" signifie simplement que tu as appelé plusieurs plusieurs fois de suite le SYS_disableInts() ce qui est possible si tu le fais dans une fonction et que la fonction appelante le fait aussi. Ce qui est important c'est d'avoir un SYS_enableInts() pour chaque SYS_disableInts()
Le sprite 0 est réservé par le SE, il est "perdu" en quelque sorte (ce qui te limite donc à 79 sprites hard en H40 et 63 sprites hard en H32). Je suis obligé de faire ça à cause du Y sort justement (qui était déjà prévu à la base), l'allocation des sprites hard se faisant en amont... Je réfléchis à une autre méthode afin de ne pas perdre ce sprite 0 : je génèrerai la SAT entièrement à chaque SPR_update(..) avec du code assembleur optimisé, ça simplifierai pas mal le SE mais il faudrait que je teste l'impact sur les performances

Et bon anniv Stef, si j'en crois le forum

Haha merci oui, le 21 juin est un bon jour pour fêter son anniversaire :p

Il sait pas ce qu'il perd

(enfin moi, je sais... Je pense qu'il préférera des € )

C'est beau la dévotion 

Haha à moins que derrière ce pseudo se cache une jolie demoiselle il y a de forte chance que je préfère le don en €

[Invité]

je génèrerai la SAT entièrement à chaque SPR_update(..) avec du code assembleur optimisé, ça simplifierai pas mal le SE mais il faudrait que je teste l'impact sur les performances 

je pense que ça peut être un bond en avant niveau perfs, dommage (même si je comprends la charge de boulot que ça représente) que tu n'ais pas converti plus de routines sensibles (comme la queue DMA par exemple) au fil du temps .

Haha à moins que derrière ce pseudo se cache une jolie demoiselle .

Dans un film marc dorcel surement, mais on est sur gamopat là, donc je pense qu'il faut pas trop y compter 
C'est plutôt barbu ascendant yéti alcolo derrière les pseudos  

[Invité]

Stef, je t'ai envoyé un Mail suite à un gros soucis sur mes projets Sgdk.

Merci copain et encore Joyeux anniversaire !! 

[Invité]

Oui tout ça est normal, en mode debug tu as quelque informations qui sont loggués dans la console pour t'aider à débugger

Ok, mais je n'utilise pas la lib en mode debug mais celle en version finale, ça veut donc dire que c'est aussi envoyer lorsque tu créé la rom (même si, au vue de la fonction, cela n'a pas d'incidence).

[Stef]

Oui tout ça est normal, en mode debug tu as quelque informations qui sont loggués dans la console pour t'aider à débugger

Ok, mais je n'utilise pas la lib en mode debug mais celle en version finale, ça veut donc dire que c'est aussi envoyer lorsque tu créé la rom (même si, au vue de la fonction, cela n'a pas d'incidence).

Ah tiens oui dans ce cas, c'est une erreur :p Ca ne devrait apparaitre qu'en mode debug, je vais regarder ça (même si effectivement ça n'a aucun impact sur le fonctionnement du jeu même sur la machine d'origine).

[Stef]

je pense que ça peut être un bond en avant niveau perfs, dommage (même si je comprends la charge de boulot que ça représente) que tu n'ais pas converti plus de routines sensibles (comme la queue DMA par exemple) au fil du temps .

Par sur du tout, actuellement le SE ne reconstruit que les parties nécessaires de la SAT, par exemple si un sprite n'a pas bougé, aucune raison de modifier la partie de la SAT qui lui ai réservé... Mais bien sur tout ce mécanisme de "update on change" coute assez cher sur l'implémentation globable et sur la complexité en générale. Malgré tout je pense que dans un cas où tu as beaucoup de sprites qui ne bougent pas (cas où tu fais un HUD en sprite par exemple) le SE actuel s'en sort bien, par contre si tu as beaucoup de sprite et qu'ils bougent tous alors oui, ça va être plus difficile (même si je ne met que la position à jour dans la SAT). Je pense que ça mérite des tests car dans le cas de 50 sprites, reconstruire complètement la SAT à chaque frame c'est loin d'être gratuit quand même (gestion des méta sprite, priorité...)

Pour ce qui est de passer les routines sensibles en assembleur, certes oui mais je dirais que maintenant que j'utilise GCC 6.3 le besoin est un peu moindre, certaines routines tournent pas trop mal. Hpman avait tenté de passer le DMA_queue(..) en assembleur et le gain n'était pas très probant (entre temps il m'a trouvé un moyen d'optimiser le code en C qui doit commencer à être assez efficace) Mais bon ça n'empêche qu'il reste certains bottleneck à améliorer, assurement

Dans un film marc dorcel surement, mais on est sur gamopat là, donc je pense qu'il faut pas trop y compter 
C'est plutôt barbu ascendant yéti alcolo derrière les pseudos  

Haha oui non je me doute bien hélas :) Pas sur qu'il y ai ne serait-ce que 5% de "gamopateuse" sur ce forum

@Vetea> Merci   J'ai répondu à ton mail

[bfg]

Salut Stef,

 La doc ne semble plus présente dans la dernière release, normal ou j'ai du caca dans les yeux ?

[Stef]

Heu... tu as du caca dans les yeux ? :p Le répertoire 'doc' est toujours présent dans l'archive (je viens de re télécharger pour vérifier)


@Alekmaul>

Ok, mais je n'utilise pas la lib en mode debug mais celle en version finale, ça veut donc dire que c'est aussi envoyer lorsque tu créé la rom (même si, au vue de la fonction, cela n'a pas d'incidence).

Je viens de vérifier et normalement si, ces messages ne devraient apparaitre qu'en mode debug donc tu utilises très probablement la librairie debug.

[Invité]

Je viens de vérifier et normalement si, ces messages ne devraient apparaitre qu'en mode debug donc tu utilises très probablement la librairie debug.

Quel coullion, je développe sur 2 PC différents et effectivement, j'avais généré la room sur un PC avec la lib en mode debug, désolé ....

[bfg]

Heu... tu as du caca dans les yeux ? :p Le répertoire 'doc' est toujours présent dans l'archive (je viens de re télécharger pour vérifier)


@Alekmaul>

Ok, mais je n'utilise pas la lib en mode debug mais celle en version finale, ça veut donc dire que c'est aussi envoyer lorsque tu créé la rom (même si, au vue de la fonction, cela n'a pas d'incidence).

Je viens de vérifier et normalement si, ces messages ne devraient apparaitre qu'en mode debug donc tu utilises très probablement la librairie debug.

Bon, ben je dois pas savoir telecharger dans github alors ...

[Stef]

La doc n'est pas dans le repository github :p Je ne la mets que dans l'archive complète (7z) à chaque fois, il faut aller dans 'release'

[bfg]

C'est bien ce que je dis, je ne sais pas utiliser github  

[Invité]

J'ai une question par rapport à SPR_setNeverVisible.
Je pensais que cette fonctione servait à faire apparaitre et disparaittre un sprite de l'écran avec , respectivement :

Code:

      SPR_setNeverVisible(ptSpr, TRUE); -> sprite disparait
      SPR_setNeverVisible(ptSpr, FALSE); -> sprite apparait

Il semble que cela ne fonctionne pas pour le faire réapparaître, même en utilisation SPR_SetPosition après le FALSE.
Je fais donc un : SPR_setPosition(ptSpr,320,256); pour le faire disparaître sans utiliser maintenant cette fonction setNeverVIsible.

Est-ce que c'est normal ?


T'as prévu des vacances Stef ? mal barré, on va te bombarder de question tout l'été !

[Stef]

En fait la méthode setNeverVisible(..) est dépréciée (c'est écrit dans la doc, n'oubliez pas de la lire :p) donc son utilisation est déconseillée   Je l'ai déprécié notamment pour la confusion dans son utilisation (la preuve), utilise la fonction SPR_setVisibility(..) à la place, c'est plus clair =)

[Invité]

Pk ne pas faire des fonctions setSprShow(), et setSprHide() plutôt ??
Parce que setNeverVisible(), perso ça me dit que ça cache définitivement le sprite(à savoir vire le lien),et qu'il faut recréer le sprite pour le rendre à nouveau visible .

[Stef]

Ben déjà c'est pour ça que j'ai déprécié cette méthode, le nom prêtait à confusion :p
Ensuite pourquoi j'utilise une méthode SPR_setVisibility(..), tout simplement parce-que tu peux le faire en manuel : visible / hidden, mais tu peux également demander au SE de le gérer automatique : auto
Et pour le mode auto tu as une méthode rapide (meta sprite global) ou une méthode lente (qui va déterminer la visibilité pour chaque sprite hard).

[Invité]

Nickel, merci, ça marche effectivement bien avec cete fonction.
Autre question et j'ai pas trouvé de réponse pour l'instant. Est-ce qu'une rom est compatible 50/60Hz ou faut adapter des choses ?
Je pense par exemple à la musique au format VGM qui contient la fréquence dans l’entête du fichier. J'ai vu que rescomp avec des options :

Code:

    timing          define the XGM base timing
                      -1 (default) = AUTO (NTSC or PAL depending the information in source VGM/XGM file)
                        0          = NTSC (XGM is generated for NTSC system)
                        1          = PAL (XGM is generated for PAL system)


Est-ce que cela veut dire que je dois enregistrer sous 2 noms différents mes VGM si je veux gérer une seule rom et ensuite adapter la vitesse avec SND_setMusicTempo_XGM ?

Enfin, est-ce que je dois gérer autre chose dans le jeu pour les soucis de vitesse entre les 2 systèmes ou pas ?

[Stef]

Pour ce qui est de la musique, normalement le driver XGM gère ça de lui même. En entrée tu lui files un seul VGM et lui ensuite le jouera à la bonne vitesse quelque soit le système (il modifiera automatiquement le tempo du playback du XGM à 60 ou 50 selon le système).

Par contre pour le jeu bien sûr si tu veux que la vitesse du jeu soit la même entre le NTSC et le PAL c'est à toi de gérer ça, mais je pense que tu dois déjà connaitre ces choses là Sinon il n'y a pas de soucis particulier, tu as beaucoup pus de bande passante en PAL, mais bon en général on se limite aux capacités du NTSC :)

[Invité]

Encore une question du noob sur MD
avec rescomp, pour les SFX au format WAV, j'utilise pour l'instant l'instruction

Code:

WAV namewav_file 5

pour tansformer mes SFX et les faire jouer par ton drivers XGM.
Mais je dois dire que le rendu est pas géant
Il faut avoir un format wav particulier en entrée (8/12/16 Khz, 8 ou 16 bits ) pour que cela rende bien ?

[Stef]

Pour un rendu optimal il faut un fichier WAV à 14Khz en entrée (et donc le ré-échantillonner avec un bon filtre) bien normalisé pour avoir un volume optimal. Sur MD le rendu est très dépendant de la machine et de l'intensité des DMA (normalement le driver XGM les gère assez bien quand même). Sur émulateur aussi la qualité est très variable selon l'émulateur, je te conseille d'essayer avec plusieurs.

[Invité]

ok, je vais faire cela, merci :)