Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Je suis en train de créer un tileset font. Je voulais savoir s'il existe un outil pour générer directement un tilset depuis une font ou il faut tout faire à la main ?

Merci

[Tryphon]

Ce n'est pas très difficile à coder, mais un TTF rendu en 8 pixels, c'est souvent dégueulasse. Mieux vaut utiliser une police en bitmap.

Tu en trouveras un certain nombre sur romhacking.net

[Invité]

Merci Tryphon, je suis parti voir le site, mais je n'ai pas trouvé chaussure à mon pied, alors j'ai réalisé un tileset avec une font que j'avais sous la main. Bon au moins ça marche et c'est une font plutôt agréable au visuel.

Quand tu dis utiliser une police en bitmap, tu sous entends qu'il est possible d'utiliser des caractères plus gros que du 8 pixels par tile avec le SGDK ?

Je voudrais également savoir s'il est possible de mettre en pause le temps écoulé depuis que la console est sous tension. Dans l'exemple XGMPlayer de @Stef, j'ai vu qu'il n'utilisait pas la fonction getTime() pour se repérer dans le temps.

Généralement j'ai toujours utilise cette méthode pour mes timings :

Code:

if(getTick() - lastPressTime > PRESSTIME) {
   lastPressTime = getTick();
   .... do stuff
}

J'utilise également cette logique pour déterminer quand les ennemis doivent venir dans la zone de combat, sauf que quand le jeu est en pause, forcément le compteur de temps évolue.

Bien sûr, je peux contourner le problème avec une variable lastPauseTime, mais je voulais savoir si ma logique était bonne, car @Stef semble procéder autrement.

[Stef]

Les fonctions startTimer(..) / getTimer(..) permettent de gérer des tempos comme tu souhaites le faire. Mais c'est bien à toi de gérer le temps de jeu, on ne peut pas mettre en pause le temps écoulé depuis le hard reset de la console. Le player XGM utilise le driver XGM pour afficher le temps écoulé de la musique, c'est différent

[ichigobankai]

Perso j'aurais plutôt tendance à mettre un marqueur jumelé au scrolling pour faire déclencher les vagues d'ennemis.

pour les fonts ; tu peux utiliser des banques de fonts en ligne comme Dafont
Il y a une section bitmap avec des fonts 8x8, 8x16, etc.

J'avais un petit soft sous windows qui permettait de générer un planche en bmp ou png via une font TTF mais je ne sais plus si j'ai encore ca vu qu'en général je fais ca plutot sous photoshop et je choisis moi même quels cars mettre dedans, histoire d'optimiser au max

[Invité]

L'idée de gérer les vagues avec le scrolling me paraît une bonne idée, je test cela se soir.

Je suis en train de me plonger dans le fichier memory.h, car j'aimerais vérifier s'il est possible de sauvegarder des données comme la table des scores et des stats.

Je sais que les sauvegardes se font à l'aide d'une pile située dans la cartouche, mais concrètement comment ça marche ?

Ah en cherchant dans les specs de la Mega Drive, j'ai trouvé la SRAM et du coup je suis parti conçulter le fichier sram.h dans le SGDK 

[Invité]

La position des ennemis avec scrolling est meilleure, c'est plus précis.

Je me suis amusé à sauvegarder des données, c'est vraiment très simple à utiliser, merci @Stef.

Par contre, j'ai remarqué pas mal de différences d'un émulateur à un autre. Par exemple dans KEGA Fusion, j'obtiens "-1" lorsque je tente de récupérer une donnée qui n'a jamais été enregistrée alors que sur DGENS j'obtiens un 0.

[Tryphon]

Quand tu dis utiliser une police en bitmap, tu sous entends qu'il est possible d'utiliser des caractères plus gros que du 8 pixels par tile avec le SGDK ?

Non, quand je parle de police en bitmap, c'est par opposition à police vectorielle. Le TTF (TrueType) ou le ps (Postscript) (par exemple), sont des fontes vectorielles. Quand tu les affiches sur l'écran à une taille donnée, elles sont converties en bitmap, en utilisant plein de raffinements (antialiasing, hinting) pour que ça soit joli. Mais à une taille aussi petite que 8 pixels, et en 2 couleurs (fond/forme), ça rend rarement bien.

Sinon oui, il est possible d'utiliser des caractères de 16x16 ou 8x16, certains jeux le font. Mais c'est à toi de coder la routine d'affichage (ce n'est pas violent).

Mieux, certains jeux utilisent des caractères de largeur variable, le rendu est incomparablement meilleur, mais la routine d'affichage incomparablement plus difficile. Les deux Shining Forces le font, ainsi que ma fantrad de Psy-O-Blade (ainsi que celle de Lord Monarch, qu'il faudra que je termine un jour). C'est totalement overkill pour un shoot bien sûr (mais ç'aurait été joli dans le LDVELH de Vetea).

La position des ennemis avec scrolling est meilleure, c'est plus précis.

C'est aussi comme ça que je fais dans Shinobi, mais dans ce jeu le scrolling vertical et la position du perso sont désynchronisés, ce qui dans certains cas peut empêcher un perso d'apparaître (ça arrive une fois dans le jeu jusqu'à présent).

Par contre, j'ai remarqué pas mal de différences d'un émulateur à un autre. Par exemple dans KEGA Fusion, j'obtiens "-1" lorsque je tente de récupérer une donnée qui n'a jamais été enregistrée alors que sur DGENS j'obtiens un 0.

Ca veut tout simplement dire que l'un remplit les positions non-enregistrées par des 0x00, l'autre par des 0xFF. En pratique, tu ne peux pas savoir.

[ichigobankai]

en plus dans le Shinobi de Tryphon tu peux reculer...dans un shoot c'est plutôt rare ^^

pour ta sram, 0x00 ou 0xFF peut importe.
Le plus simple c'est de verifier si un header est présent (via un checksum ce cette même ligne par exemple)
si non, tu initialises pour la 1ere fois
si oui, juste à lire (ou écrire) les infos pour le tableaux des hi-score & cie.

[Invité]

@Tryphon merci tes explications, c'était vraiment intéressant à lire.

@ichigobankai il est seulement possible de sauvegarder un bit, long ou word ? Impossible de sauvegarder les initiales d'un joueur par exemple ou alors je dois faire correspondre des chiffres avec des lettres ?

[Tryphon]

Les lettres ça n'existe pas en Informatique. Tout est nombre.

Donc oui, tu dois faire correspondre, mais le C le fait pour toi, à l'aide du code ASCII.

Par exemple, si tu fais :

Code:

char c = 'A';
printf(c);


tu obtiendras 65, qui est le code ASCII du 'A'.

[ichigobankai]

perso j'écris en char (enfin c'est sur SMS ^^), de toute facon tu peux verifier dans le fichier SRM généré par les emus.
Après pour le nom des joueurs etc, ca dépend directement de tes "lettres" dans la vram...

[Invité]

@Tryphon ah oui c'est vrai ! J'étais confronté à ce problème la première fois que j'ai voulu afficher du texte avec des nombres. Je vais faire quelques essais :)

[Invité]

Petite question concernant SRAM_readLong() et SRAM_writeLong(), j'aimerais savoir si je suis libre de choisir l'offset et de m'organiser en conséquence ?

Y a t-il une méthode afin d'effacer tous les sprites plutôt que de devoir utiliser à chaque fois SPR_releaseSprite() ? Quelle différence il y a entre VDP_releaseAllSprites() et SPR_releaseSprite ?

J'ai remarqué qu'en faisant un VDP_resetScreen(), il y a quelques fractions de secondes où on voit les sprites changer de palettes. Je n'ai pas réussie à empêcher cela, si ce n'est en faisant un fadeOut() histoire de cacher la transition.

Merci les gars !

[Stef]

Pour la SRAM, normalement elle commence toujours à l'adresse :
SRAM_BASE      0x200001


C'est une convention sur MD (on pourrait la mettre ailleurs mais c'est un espèce de standard).
Ensuite pour l'offset, tout dépend de la taille de la SRAM dont tu disposes, aujourd'hui le cout est à peu prêt le même quelque soit la taille de la SRAM mais avant on avait tendance à limiter la taille au maximum (et bon en général tu sauvegardes pas grand chose dedans). Ne dépasse pas 64Ko si tu veux être compatible avec les flashcart standard qui ont de la SRAM.


Sinon SPR_clear() te permet d'effacer tout les sprites rapidement et temporairement, les sprites restent alloués et le prochain SPR_update() va les rendre visible à nouveau, mais ça te permet justement de  bidouiller l'allocation, les définitions etc... pendant ce temps si tu as beaucoup de changements à effectuer.

La méthode VDP_releaseAllSprites() est une méthode plus bas niveau dans la gestion des sprites, tu ne dois surtout pas mélanger les méthodes SPR_xx et VDP_xxSpritexx sinon tu risques d'avoir des soucis :p
Le sprite engine utilise les méthodes bas niveaux VDP_xxx pour allouer ses ressources, si tu y touches aussi le Sprite Egine risque de ne pas être content ^^

Soit tu passes par le sprite engine ou soit tu fais tout en bas niveau (avec les méthodes VDP_xxx) mais tu ne peux pas vraiment mixer les 2 (à moins de vraiment savoir ce que tu fais ^^).

Sinon utiliser un fadeout pour cacher une transition c'est classique, pas de honte à avoir à faire ça pour cacher des flickerings de data en train de se mettre à jour

[Invité]

@Stef merci pour ces explications ! Pour la SRAM, cela semble fonctionner, en tout cas j'arrive à retrouver mes données ^^

Je trouve le SGDK vraiment excellent, c'est toujours aussi plaisant de bosser dessus. Je voulais aussi savoir si tu prévoyais d'écrire une fonction permettant d'augmenter / diminuer le son avec le driver XGM. J'ai remarqué que lorsque je baissais ou augmentait le son avec le driver 4PCM, les sons émis en XGM pètent un câble et c'est une torture pour les oreilles.

Autre question, je n'ai pas vu de fonction dans maths.h afin de connaître l'angle d'un vector2D et du coup je ne vois pas comment envoyer des projectiles dans la direction du joueur. A moins que j'ai mal vu, dois-je écrire mes propres fonctions ?

[Stef]

@Stef merci pour ces explications ! Pour la SRAM, cela semble fonctionner, en tout cas j'arrive à retrouver mes données ^^

Je trouve le SGDK vraiment excellent, c'est toujours aussi plaisant de bosser dessus. Je voulais aussi savoir si tu prévoyais d'écrire une fonction permettant d'augmenter / diminuer le son avec le driver XGM. J'ai remarqué que lorsque je baissais ou augmentait le son avec le driver 4PCM, les sons émis en XGM pètent un câble et c'est une torture pour les oreilles.

Autre question, je n'ai pas vu de fonction dans maths.h afin de connaître l'angle d'un vector2D et du coup je ne vois pas comment envoyer des projectiles dans la direction du joueur. A moins que j'ai mal vu, dois-je écrire mes propres fonctions ?

Hélas non tu n'as pas de gestion de volume avec le driver XGM, et ça ne sera jamais le cas sur les sons PCM quoiqu'il arrive (ça demande une gestion soft et le Z80 est déjà assez surchargé avec le reste).
Si tu essais de mélanger l'utilisation du driver 4PCM et le driver XGM c'est normal que ça explose ^^ C'est l'un ou l'autre mais pas les 2 en même temps :p

L'unité maths est très incomplète et de mémoire il n'y a pas de fonction de calcul d'angle (ça serait interessant à rajouter en effet car on utilise ça fréquemment dans un jeu), mais c'est juste un atan non ?

[Invité]

Stef,
y a -t-il une commande magique pour forcer un timing de music, peu importe que le jeu soit lancé en mode 50 ou 60 Hz ?
L'idée c'est d'entendre la zique comme elle a été faite, et pas ralentie ou accélérée suivant la vitesse de la machine

[Stef]

@kaot> si tu es sur la dernière version de SGDK alors normalement c'est le cas par défaut. Il y avait un bug dans les vieilles versions qui passait le timing à 50 sur une machine PAL mais de base le timing XGM c'est 60 Hz (et il y a une compensation automatique) donc on doit le laisser à 60 pour avoir la bonne vitesse (qu'on soit en Pal ou Ntsc).

[Invité]

stef.... les vgm sont exportés en 50 Hz (valeur PAL dans dm). la problématique est là.

>> Il y avait un bug dans les vieilles versions qui passait le timing à 50 sur une machine PAL


c'est exactement l'effet escompté . le vgm en mode 50hz quoi qu'il arrive, PAL et NTSC.

-peut-on reproduire cette "feature" sur des MD 60hz moyennant un parametre ou deux du driver (genre baisser la vitesse de playback, comme on peut le faire dans xgmplayer)?
-ou est-ce que je dois refaire tous les exports avec les timings adaptés pour du 60hz (si j'ai bien compris, ca jouerait la musique à vitesse 1/1, quel que soit le zonage, encore faut-il que la rom soit reexportée avec une version récente de sgdk)?
-vois tu une solution alternative?
je suis confusion.

[Invité]

Kaot, si tu veux parler de ce que je pense, alors laisse tomber, le projet n'a pas été réalisé avec SgdK et en plus, avec une ancienne version du Driver réalisé par Stef.
Ne t'embête pas avec ça.

[Stef]

@kaot> Mais au final je n'ai pas compris, qu-utilises tu pour jouer la musique sur MD ? un driver VGM ? ou le driver XGM ? si tu utilises le driver XGM, alors tu peux passer le timing à 50 de force et ça devrait jouer à la bonne vitesse sur une machine PAL et NTSC, mais là encore il faut que tu sois à jour dans les versions de SGDK et driver XGM...

[Invité]

stef c'est top secret je te mp

[Invité]

L'unité maths est très incomplète et de mémoire il n'y a pas de fonction de calcul d'angle (ça serait interessant à rajouter en effet car on utilise ça fréquemment dans un jeu), mais c'est juste un atan non ?

Ce calcul avec la fonction atan2 permet de connaître l'angle de V2 par rapport à V1.

Code:

atan2 (v2.y, v2.x) - atan2 (v1.y, v1.x)

Sauf qu'il n'y a pas d'atan2 dans le fichier math.h...

[Stef]

oui voilà, c'est un atan2, mais en effet il n'y en a pas dans l'unité maths car il faut une implémentation software qui risque de couter cher en CPU :p
Enfin tot ou tard il faudrait que j'ajoute tout ça quand même

[Invité]

Ah mince, pas d'autres techniques pour lancer une bullet dans la direction du joueur, parce que si ça coûte cher en CPU...

[Tryphon]

Si, y'en a plein. Est-ce que tu veux que toutes les boulettes aillent à la même vitesse ?

[Invité]

Oui, les bullets lancées vers le joueur doivent aller à la même vitesse. Ah bah si y a pleins de techniques, je suis preneur :)

[fanoplusplus64K]

Pourquoi utiliser atan, tu peux très bien diviser (enfin garder le modulo plutôt), la partie de vecteur la plus petite par la plus grande, comme ça tu te retrouves avec un vecteur genre 1/x que tu multiples rapidement par 2,4 ou 8 selon la vitesse de ton projectile

[Tryphon]

Si A est l'ennemi et B le joueur, et v la vitesse de la boulette, tu veux calculer un vecteur (dx, dy) colinéaire à AB de norme v.

La formule est u = v* 1/norme(AB) * vecteur(AB)

le calcul emmerdant est norme(AB) = racine carrée(x(AB)^2 + y(AB)^2)

Tu dois faire une table des 1/racines, sinon ça sera trop lent. Problème, x(AB) peut varier entre -320 et 320, et y(AB) entre -224 et 224, ce qui ferait une très grosse table !

Déjà, le signe de x et y n'intervient pas, donc tu peux juste faire x entre 0 et 320 et y entre 0 et 224.

Ensuite, tu peux considérer uniquement le cas où y < x : en effet, la table en [x][y] et en [y][x] contiennent la même valeur.

Ça fait une table à 320 * 224 / 2 soit environ 36000 entrées, une entrée étant au moins sur 16 bits, ça fait 72 ko de table. C'est beaucoup. Après, tu peux travailler à mi-résolution, ça devrait pas trop se sentir, ce qui te fait 4 fois moins de données, soit 18 Ko. Tu peux peut-être faire encore moins précis (et gagner encore un facteur 4).

Il te faudra multiplier le x et le y de ton vecteur AB par ce nombre, ce qui sera lent.

Par cotre, si ta vitesse vaut 2, 4 ou 8 pixels par frame, la multiplication par v sera rapide.

On peut faire plus rapide en perdant en précision (par exemple en "hardcodant" la multiplication par 1/racine suivant les valeurs de x et y).

Y'a d'autres méthodes, mais je pense qu'elles sont toutes équivalentes du point de vue calcul.

[fanoplusplus64K]

Dans tous les cas le coup minimum sera une multiplication au moment de calculer le vecteur, ça reste raisonnable pour un 68k tout de même.