Re: Sgdk - Sega Megadrive / Genesis Development Kit

[uran]

Arrête de flooder uran ... Merci !
Merci pour ce message mon ami, conclusion brillante de notre conversation de tout a l'heure au travail.

Oui tu as raison allons plutôt ici continuer cette conversation sans fin :)

[uran]

Bonjour,

Dans SGDK,  l'exemple SPRITE utlise des variables déclarées en FIX32 pour la position des sprites

Code:

fix32 posx;
fix32 posy;

et ensuite on utilise une fonction de "cast" pour ajouter un sprite à l'écran

Code:

sprites[0] = SPR_addSprite(&sonic_sprite, fix32ToInt(posx -
camposx), fix32ToInt(posy - camposy), TILE_ATTR(PAL2, TRUE, FALSE,
FALSE));

Pourquoi ne pas directement déclarer ces variables dans le format qui sera utilisée par la fonction, cela éviterait une consommation de mémoire et de ressource µp. Ou est ce qu 'il y a quelque chose que je rate? (je découvre gentiment SGDK par petit petit morceau, et je n'ai pas encore découvert grand chose).

Yann

[Tryphon]

L'exemple sprite est basé sur Sonic, dans lequel tu dois gérer la vitesse et l'accélération, donc travailler avec des flottants. C'est le cas de beaucoup de jeux de plate-formes (depuis au moins Super Mario).

Pour des jeux à la physique plus simple, tu peux te contenter d'entiers.

[uran]

Ok! c'est un peu ce qui me venait à l'idée, même cela me paraissait un peu capilotracté.

Merci

[Tryphon]

Quand j'ai commencé Shinobi sur MD, j'ai beaucoup étudié la physique des persos sur la version arcade et je suis à peu près sûr que le moteur travaille en 1/8ème de pixels.

Shadow Dancer sur MD travaille aussi avec des flottant, mais il a une "astuce" : la partie entière est sur 2 octets et la partie fractionnaire sur 2 octets. Du coup les calculs se font sur 4 octets (avec des add.l en asm), mais la passage réel -> flottant nécessite juste de lire les deux premiers (avec un move.w). C'est peut-être plus rapide que les conversions de SGDK (à base de shifts). On doit pouvoir obtenir un résultat similaire en SGDK avec des union...

[uran]

Quand j'ai commencé Shinobi sur MD, j'ai beaucoup étudié la physique des persos sur la version arcade et je suis à peu près sûr que le moteur travaille en 1/8ème de pixels.

Là je veux bien une explication un peu détaillée si possible.

Pour le flottant en non ANSI (signe, mantiss, exposant) j'ai déjà un truc que j'utilise au boulot sur des µc 8bits qui pourrait peut être s'adapter, on verra quand j'aurais un peu plus vu comment marche le bas niveau de la MD et si j'en ai besoin (ce dont je doute dans l'immédiat, si j'arrive à consacrer 1h ou 2 par semaine ça sera déjà beau).

[Tryphon]

J'ai utilisé le mot flottant mal à propos.

Ce ne sont pas des nombres à virgule flottantes mais à virgule fixe (d'où le fix).

Les fix16 sont de la forme : eeeeeeee eeffffff (10 bits de partie entière)
Les fix32 sont de la forme : eeeeeeee eeeeeeee eeeeeeff ffffffff (22 bits de partie entière)
Les fix de Shadow Dancer sont de la forme : eeeeeeee eeeeeeee ffffffff ffffffff (16 bits de partie entière)

Je n'ai pas regardé dans le code de Shinobi (je sais pas trop comment sont organisés les fichiers d'une ROM System16), mais je suis à peu près sûr que les déplacements verticaux sont gérés par un truc de la forme :

vitesse += acceleration
position += vitesse

acceleration est en général une constante multiple de 1/4.

Les déplacements horizontaux sont en général plus simples (pas d'accélération), sauf lors des sauts où l'accélération horizontale est de 1/8 (ce qui explique le délai lorsque tu changes de direction en plein saut).

[Invité]

C'est marrant votre histoire d'accélération ... J'utilise de la physique pour mon jeu de tennis et aussi pour Bomb on Basic City, mais j'ai utilisé que des entiers. Pourquoi se prendre la tête avec du flottant alors que l'on peut faire la même chose avec des entiers ?
Merci.

[Tryphon]

Ben parce que quand tu rajoutes 1/8, c'est pas un entier.

Mais encore une fois, c'est pas un flottant non plus, c'est un fixed, donc les opérations que tu effectues dessus sont des opérations sur des entiers, pas sur des flottants :

pour additionner a,b et c,d qui s'écrivent en binaire sur 2 octets (fix16) :

aaaaaaaa aabbbbbb
ccccccccc ccdddddd

tu utilises un add.w, tout bêtement (donc ça se comporte comme un entier).

C'est juste que quand tu "lis" le résultat (pour le mettre en coordonnée de sprites par exemple), il faut le convertir en vrai entier (avec un shift).

aaaaaaaa aabbbbbb >> 6 = aaaaaaaaaa

Grosso modo, avec un fixed, tu as tous les avantages des flottants sans leur désavantage (la lenteur). Bon, c'est pas tout à fait vrai, tu perds la souplesse du décalage de virgule, mais pour des jeux c'est suffisant.

Tu fais comment toi ?

[Invité]

Simple :
Pendant la Vblank :

1/ Tempo ++
2/ Si tempo >= Valeur alors accélération ++ : tempo=0
3/ Vitesse=Vitesse+accélération

Avec valeur je varie l'accélération ...
Une solution de N00b qui me convient.
Il suffit de tester la démo de mon jeu de tennis pour s'en rendre compte.
Apres il y a toujours d'autres solutions ...

[Invité]

aaaaaaaa aabbbbbb
ccccccccc ccdddddd

Pk ce format ??

Quand tu es en fix 16 bits, c'est en général 8 bits pour la partie entière, et 8 bits pour la décimale non ??

Là tu es en 10/6 .
Enfin si tu es obligé de shifter, finalement un CPU 8 bits semble plus adapté pour ce genre de calculs,en 10/6 tu auras juste besoins de 3 ROL au lieu des 6 shifts .

Grosso modo, avec un fixed, tu as tous les avantages des flottants sans leur désavantage (la lenteur). Bon, c'est pas tout à fait vrai, tu perds la souplesse du décalage de virgule, mais pour des jeux c'est suffisant.

Oui dans un jeu 16 bits tu n'as pas besoins de la précision d'un flottant.

[Tryphon]

aaaaaaaa aabbbbbb
ccccccccc ccdddddd

Pk ce format ??

Aucune idée ! Demande à Stef

Quand tu es en fix 16 bits, c'est en général 8 bits pour la partie entière, et 8 bits pour la décimale non ??

Là tu es en 10/6 .

Je pense que Stef a dû penser qu'on serait trop limité avec 8 bits de partie entière. Si tu veux stocker une position, sur MD, tu dois pouvoir aller jusqu'à 320 déjà... Personnellement je n'utilise pas le fix16.

Par contre j'aurais fait 16/16 en fix32, pour les raisons évoquées plus haut, mais bon, c'est facile à implémenter si nécessaire.

@vetea : ce que tu fais n'est pas plus simple, et légèrement plus lent que manipuler un fix. La différence est vraisemblablement négligeable, donc si tu préfères, garde ça, mais ça peut valoir le coup de jeter un coup d'œil au fix (ça rendra surtout le code plus lisible, tu auras une variable en moins - le tempo).

[Stef]

Exactement un fix16 en 8.8 ça pose beaucoup de problème sur MD, surtout que tu peux vouloir utiliser le fix16 comme un signé, donc faut réduire de 1 bit encore.
J'ai donc décidé d'avoir du -512 --> 511 avec le fix16, pour passer au moins au dessus du 320px. Aussi il me semble que les positions sprite/plan sont toujours encodé sur 10 bits sur MD donc c'est pratique d'avoir 10 bits pour la partie entière. Idem pour les calculs "3D", j'utilise beaucoup le fix16 pour des raisons de performances et en 8.8 j'aurais été bien trop limité.
Pour le fix32 j'aurais effectivement pu faire du 16.16 mais j'ai voulu garder la proportion avec le fix16, puis encore une fois ça me parait plus "équilibré". Et si tu veux faire du 16.16 c'est pas très compliqué

[Invité]

Mais un fix 16.16 aurait été plus simple/pratique à gérer sur le 68k(car plus natif) ,non ??

[Stef]

Oui en effet un fix32 type 16.16 aurait été bien plus rapide pour pas mal de choses mais je souhaitais conserver le ratio mantisse.exposant du fix16. Et puis simplement une valeur entière limitée à -32768 --> 32767 ça me paraissait un peu faible pour le fix32 alors que 16 bits en partie décimale c'est bien trop (gachi)...
Et si quelqu'un veut faire du 16.16, c'est vraiment pas bien compliqué de le faire soit même Peut être que plus tard j'ajouterai un fastf16 / fastf32

[uran]

Fichtre je n'aurais pas pensé qu'une petite question comme çà aurait entrainé un tel débat :)

Sinon j'ai un petit soucis avec la fonction "VDP_drawTextBG(PLAN_WINDOW, "SHOOT",1,1);" que je n'arrive visiblement pas à utiliser .. du moins sur le plan WINDOW, sur le A & le B ça semble bon ou alors j'ai du bol....
Est ce qu'il faut initialiser quelque chose avant pour utiliser ce plan WINDOW (pour le moment j'aimerais y afficher divers trucs pour faire une sorte de debug, par la suite j'aimerais bien l'utiliser pour afficher des scores/sprites fixes ou autres)

Merci

[Stef]

Oui il te faut utiliser les fonctions suivantes pour activer la window :

Code:

VDP_setWindowHPos(..)
VDP_setWindowVPos(..)

Je te conseille de lire la documentation de ces méthodes pour comprendre comment ça configure l'affichage de la window. Ensuite il faut t'assurer que tu as alloué assez d'espace pour le tilemap de la window, par défaut SGDK n'alloue qu'un demi écran il me semble (donc la window ne peut être que sur la moitié supérieure de l'image) pour ne pas gacher trop de VRAM (la window étant rarement utilisée).


Un détail important: la window n'est pas à proprement parler un pan supplémentaire, en réalité elle remplace le plan A : là où la window s'affiche, le plan A ne s'affiche pas (en gros c'est comme si tu fixais une partie du plan A et que cette partie avait son propre tilemap).

[Tryphon]

Si tu veux faire du debug, les fonctions KDebug_Alert qui te permettent de faire afficher des messages dans une fenêtre à part de ton émulateur (il te faut alors Gens_kmod) sont pas mal : elles évitent de t'obliger à utiliser des ressources VRAM ou du temps pour l'affichage (il reste juste le temps des opérations sur les chaînes que tu affiches).

Et si tu oublies de les virer lors du test sur vrai hardware, ben à ma grande surprise, ça embête pas la MD...

[uran]

Merci stef pour l'explication.
La doc c'est la doxygen dont tu parles ?

Tryphon, c'est une bonne nouvelle cette fonction :)

[Tryphon]

Oui je m'en sers pas mal. Tu peux aussi pauser le jeu vie KDebug_Halt() si je me souviens bien. Le seul truc relou, c'est que Gens_kmod est pas super ergonomique et tu dois naviguer dans les menus pour activer / désactiver la fenêtre.

[uran]

Oui j'ai vu (je l'utilise), et à chaque rechargement de la rom, les fenêtres ouvertes se ferment chez moi.

[Tryphon]

Pareil ! Un jour, j'apprendrais à compiler Gens et on verra ce qu'on peut faire...

[Stef]

Gens KMod est très pratique pour ses fonctionnalités de debugging, mais il ajoute quelque bug facheux qui n'étaient pas présents dans la version d'origine, aussi les debuggers CPU (68000 / Z80) sont moins pratiques que ceux d'origine je trouve. Mais rien pour la fenêtre de sortie log c'est hyper pratique, je l'utilise beaucoup aussi J'ai ajouté des méthodes dans SGDK pour l'utiliser plus facilement : KLog_xxx(..)

[Invité]

Un jour je saurai compiler un projet "Test" du tuto avec Code::Blocks  V.16.01 ... 

[Tryphon]

J'avais essayé une fois en suivant le tuto, et ça marchait. Sauf que j'ai cru que ça marchait pas parce que ma première compilation s'était mal passée.

Mais en fait non, y'a un bug de GCC ou de Windows qui fait que parfois la compilation échoue. Il suffit de la relancer (parfois plusieurs fois). C'est très très chiant.

Toujours est-il que finalement, je suis passé au couple Notepad++/ligne de commande. C'est pas terrible mais ça marche. Au moins t'as rien à configurer (je suis une quiche infâme en config d'éditeur, j'arrive jamis à recompiler un truc en C dès qu'il y a des libs)

(Tiens au fait j'ai un peu avancé dans Street Fighter, mais ça va prendre du temps, faudra que j'en parle)

[Invité]

Merci pour tes éclaircissements !

Finalement, par un hasard des plus providentiels, maintenant ça fonctionne et je peux même compiler les exemples du DevKit !

Allez, le C sur MD me tend les bras maintenant ... 

if Vetea=C
{ end
}

... ou un truc comme ça ... Oh purée ... 

[Tryphon]

T'as fait le plus dur

Si tu utilises les outils haut niveau (notamment le Sprite Engine) de Stef, je pense pas que ça soit beaucoup plus difficile que BEX

Après si tu veux trifouiller, là...

[Invité]

Etant donner que j'ai commencé à trifouiller le Hardware de la MD avec le l'assembleur 68000, ça devrait aller.
Par contre j'ai toujours un blocage mental avec le C, la feuille blanche à ne pas savoir que mettre, bref des verrous à débloquer et c'est ça pour moi le plus dur.

[Templeton]

if Vetea=C
{ end
}

... ou un truc comme ça ... Oh purée ...     

C'est presque ça:

if(Vetea==C)
{ /* end */
}


Courage, au vu de ce que tu as déjà réalisé, le C ne sera plus qu'une formalité pour toi très bientôt.

[Invité]

Merciii Templeton !!
A vrai dire, j'en ai rêvé cette nuit ... A dire si c'était un cauchemard, euh ...

[F.L]

Oui t'inquiete, c'est juste un probleme de synthaxe, la logique est la meme!
Et puis quand on a dompté  bex, on peut tout faire