Re: Sgdk - Sega Megadrive / Genesis Development Kit

[ichigobankai]

Stef te donnera une réponse précise, mais de mémoire environ 1500.

[upsilandre]

oui ca doit etre de cette ordre la puisque la VRAM de la MD = 2000 tiles mais qu'il faut reserver un bon quart de cette espace pour d'autre truc.

[Stef]

Coucou,

Conseil, si tu utilise ton Bga.Map dans ta fonction VDP_SetMapEx, ça va ramer GRAVE !! C'est normal, tu vas unpacker à chaque frame ta map !!!

Donc avant de faire ça, et en dehors de ta boucle, déclare en globale un pointeur Map :

Map* MaMap ;
( Eventuellement dans ton .h -> extern Map* MaMap ; )

Ensuite avant ta boucle principale :
MaMap = unpackMap(Bga.map, NULL);

Et après dans ta boucle principale :
VDP_setMapEx(PLAN_A, MaMap, etc ... );

Ca sera beaucoup plus fluide ainsi.

Bonnes fêtes !! 

Tu assures Vetea, tu as parfaitement expliqué le problème
Je suis arrivé trop tard mais je vois que la relève est là

Un petit détail, lorsque MaMap n'est plus utilisée (changement de niveau), il est préférable de libérer la mémoire utilisée avec avec MEM_free(MaMap) sinon au bout d'un moment tu risques de la remplir.

Sinon j'espère que vous avez tous bien festoyé hier soir

Pour le nombre de tiles utilisables, ça dépend de plusieurs choses, enfin surtout de l'arrangement de la VRAM.
Dans SGDK par défaut c'est effectivement proche de 1500, tu peux utiliser la constante TILE_USERLENGTH pour savoir le nombre de tile utilisable par l'utilisateur (le reste de la VRAM étant réservée par SGDK).
TILE_USERINDEX te donne le premier index utilisable par l'utilisateur (en théorie 0x10 car les 16 premiers tiles sont réservés par SGDK, ce sont des tiles plein pour chaque couleur).
TILE_USERMAXINDEX te donne l'index maximum.

[Invité]

Merci Stef, j'ai eu un bon formateur. :)

[Monos]

Yop les coupinous voici ce que j'ai sortis !
TILE_USERLENGTH => 1296
TILE_USERINDEX => 16
TILE_USERMAXINDEX =>1311

A quoi sert au SDGK les 16 premiers tiles de couleurs ?

[Stef]

@Monos Ca me parait faible tes chiffres, tu es bien sur la dernière version de SGDK ? Auparavant j'utilisais des plans de 64x64 ce qui consommait beaucoup de VRAM mais depuis SGDK 1.31 (je crois) je suis passé à 64x32 (ce qui est suffisant pour la plupart des cas de figure) et ça libère pas mal de tiles.
Les 16 premiers tiles sont les tiles "plains" (tile remplis des couleur de 0 à 15), ça peut servir on va dire (pour faire du remplissage rapide, debug palette, etc...). Quand j'ai tenté de les viré beaucoup d'utilisateurs s'en étaient plains Il y a aussi la font qui bouffe 96 tiles, on peut la redéfinir mais c'est vrai que par défaut elle n'est pas compté comme espace utilisateur... cela dit rien n'empêche de l'écraser si elle n'est pas utilisée.

[Invité]

En parlant de font, il y aurait un moyen de changer la taille voir de la remplacer?

[Monos]

Je pense être au dernier sdk.
Je vais regarder tout ça de plus près.
Existe t'il une variable pour connaitre le SDK utilisé ?

[Tryphon]

En parlant de font, il y aurait un moyen de changer la taille voir de la remplacer?

Non, et oui. Tu peux la remplacer en chargeant des tiles au même endroit.

Si tu veux une fonte plus grande, c'est à toi de gérer l'affichage dans un tilemap. Ce n'est pas très difficile.

[Monos]

Heu oué, je placé les mises à jour du SDK au mauvais endroit.
Je passe de 1296 à 1424.
Je gagne 34 tuiles de 16px c'est déjà ça xd

[Stef]

Dans le fichier readme.txt sinon y'a le SGDK_VERSION mais je l'ai ajouté dans la version 1.32 il me semble (et j'ai oublié de le mettre à jour dans la 1.33 ^^)
1424, c'est un peu moins que ce que je pensais mais possible car il y a la font qui en bouffe pas mal quand même (96).

[Monos]

Merci beaucoup des informations.

[Invité]

Petite question concernant les sprites :
J'ai une planche de sprites de 32*2048 pix, que je charge en tileset car je ne peux pas utiliser le moteur de sprite (conversion d'un jeu qui vous fera plaisir je pense .
Quand j'utilise ensuite les instructions :

Code:

   
VDP_loadTileData(  ..., 4*3, TRUE);
VDP_setSpriteFull(nb_sprites_oam,x,y,SPRITE_SIZE(4,3),TILE_ATTR_FULL(PAL0,FALSE,FALSE,FALSE,...),0);


Mes tiles du sprites sont chargés de haut en bas puis de gauche à droite, c'est normal o_O?
Je pensais plus de gauche à droite puis haut en bas.
Car là, mon sprite, il est tout mélangé ....

[Tryphon]

Oui, c'est normal. C'est l'ordre dans lequel les sprites sont affichés sur Megadrive.

[Invité]

oui, étrangement, j'ai réussi à trouver ma solution en utilisant les sprites à la place du tileset vu que ce n'est pas la même organisation.
Bref, pour les personnes voulant savoir comment utiliser les sprites sans le moteur de sprites, voici comment pointer sur le bon sprite dans votre bitmap (yspr étant l'indice du sprite à afficher) :

Code:

VDP_loadTileData( (const u32 *) pgfx->animations[yspr]->frames[0]->tileset->tiles, idTile+GFXADRSPR, 4*3, TRUE);

 VDP_setSpriteFull(nb_sprites_oam,x,y,SPRITE_SIZE(4,4),TILE_ATTR_FULL(PAL0,FALSE,FALSE,FALSE,idTile+GFXADRSPR),0);


Allez, le jeu, puisque c'est Noël, que je suis en train de préparer pour la megadrive , Rick Dangerous II ! Pas encore gagné mais en bonne voie ....

*EDIT* Bon, j'ai réussi à m'en sortir avec rescomp et les sprites, il y a effectivement un encodage différent des tilessets. Même si cela prend pas mal de place car les animations ne sont pas gérées, mes sprties sont maintenant correctement affiché. En effet, SprDefinition->animations[]->frames[0]->tileset->tiles pointe sur le bon tileset de sprite.

@Stef : il ne serait pas possible d'avoir une option dans rescomp qui permet d'encoder les sprites sans les animations ?

[F.L]

Rick dangerous II sur megadrive ! Cool !
Joli projet 
Et papa noel n'oublie pas la petite mise à jour de pvsneslib dans mon soulier aussi 

[Invité]

Rick dangerous II sur megadrive ! Cool !
Joli projet 
Et papa noel n'oublie pas la petite mise à jour de pvsneslib dans mon soulier aussi 

Oui, je fais au mieux ... :)

[ichigobankai]

Très bon choix le Rick Dangerous II !
Après t'auras plus qu'a nous faire une ptite compile Rick Dangerous I + II

[TotOOntHeMooN]

Rick et Rick II, c'est surtout une histoire de transition 8/16 bit.
Il faut te souhaiter qu'il sera mieux que la versions SMS en cours de dev, hein ! 

[Stef]

@alekmaul> Je pourrais effectivement faire des sprites plus léger (sans les informations d'animations) mais je pense que ça ne va concerner que très peu de personnes. Pourquoi ne passes tu pas par le sprite engine (simple curiosité) ? ^^

[Invité]

Le Sprite Engine est tout simplement génial. 
Surtout que Stef a fait beaucoup d'amélioration et d'ajouts.
L'essayer c'est l'adopter !

Après oui, c'est pas "bas niveau", mais on s'en tape si ça fait le boulot !! Pour un jeu de plateforme comme Rick, ca serait parfait, c'est pas un Doom Like non plus. ^^

[Invité]

@alekmaul> Pourquoi ne passes tu pas par le sprite engine (simple curiosité) ? ^^

Car je fais du reverse du code ST du jeu et que je veux juste afficher les sprites :)
Mais t'inquiètes, c'est bon maintenant, si personne ne veut d'un sprite engine light, y'a pas de pb pour moi ^^
Je suis en train de me battre maintenant dans le code porté du 68000 vers le C

[Invité]

Dites les gars, y a t-il une limitation de la taille d'une carte si oui, quelle est la résolution ou le nombre de tiles max? J'ai réalisé une map de 192 tiles par 40 et lorsque je scroll, la mise à jour de la carte se fait par morceaux manquant. Bizarrement quand ma map faisait maximum 128 tiles je n'avait pas de soucis. Quand je dis manquant, c'est que la mise à jour n'est pas complète.

[Tryphon]

La largeur d'un plan en mémoire est de 64 tiles, soit 512 pixels (par défaut). Si ta carte fait plus, c'est à toi de la mettre à jour. Si ça bugge, c'est que t'as merdé quelque part

Fais voir ton code ?

[Invité]

Code:

        y = scroll;
        scroll -= 2;
        next_y = scroll;

        z = (s8)(next_y / 8) - (s8)(y / 8);
        if(z)
        {
            az = (scroll / 8 ) + z;
            VDP_setMapEx(PLAN_B, map, TILE_ATTR_FULL(PAL0, FALSE, FALSE, FALSE, ind), 0, az & 31, 0, az & 191, 40, 1);
        }

[Stef]

Sur MD tu peux avoir une map qui fait jusqu'à 128x32 ou 32x128 tiles...
Mais bon normalement c'est juste "un cache", tu n'es pas sensé stocker toute ta map dedans, moi je travaille souvent avec un tilemap de 64x32, c'est suffisant... ensuite tu met à jour ta map au fur que tu te déplaces dans le tilemap. En gros le tilemap hardware est un cache, tu peux le voir comme un "rouleau" sur lequel tu boucles

[Invité]

Merci @Stef, en fait le problème c'était la carte et le code.

Code:

 az & 191

Du coup j'ai passé la map en 256 tiles ou alors fallait trouver une autre méthode :)

Code:

e = (scroll / 8) + (z < 0 ? 191 : -1);

[Stef]

191 ce n'est pas un masque d'une puissance de 2, tu as un bit à 0. Je ne sais pas ce que tu veux faire avec mais ça risque de ne pas marcher :p
Sinon voici un code bien commenté qui montre comment faire un scrolling multi directionnel sur une grande map :
https://github.com/kcowolf/GenScrollingMapDemo

Le fichier intéressant étant celui-ci :
https://github.com/kcowolf/GenScrollingMapDemo/blob/master/src/ScrollingMap.c

[Invité]

Merci pour le partage Stef !

En fait, c'est juste une coïncidence. J'avais commencé à réaliser une map et je suis me suis arrêté à 192 tiles, 32 tiles x 6.

Sauf que j'ai compris que ça ne marchait pas comme ça.

[Tryphon]

Oui, il faut absolument que ta "sous-carte" (la portion effectivement rendue dans la tilemap à un instant t) ait pour dimension une puissance de 2.

Vu que ton écran fait 40 tiles de large, qu'il faut en prévoir une de plus au cas où ton scrolling est à cheval sur 2 colonnes, ça marche impec avec 64 tiles.

[troudki]

Hello
Avec la nouvelle version SGDK 1.34 sortie récemment  (merci stef), est ce que vous voyez bien les sprites affichés dans le sample sprite ?
++