Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Merci @Tryphon pour la précision.

En fait c'était une définition qui bloquait chez moi, elle était à 8, je l'ai passé à 32, plus de soucis.

Le seul problème que j'ai, c'est qu'il semble y avoir un problème de priorité. Lorsqu'un sprite quitte l'écran, je le désactive avec SPR_releaseSprite(sprite) afin de libérer la mémoire. Par exemple lorsque je tire en continu, pas de soucis, mais si je tire lorsque la vague d'ennemis se pointe, les bullets ne sont pas affichées. Puis quand les bullets s'affichent, des ennemis disparaissent...

J'ai regardé dans le VDP_SPRITE de DGENS et le sprite bullet veut toujours se positionner à la place des sprites ennemies au-lieu d'allouer une place à la suite.

Je ne sais pas si c'est bien de décharger un sprite puis de le charger à la voler ou de le garder de côté.

Y a t-il un moyen de modifier la priorité ?

Code:

player.sprite = SPR_addSprite(&player_ship, player.posx, player.posy, TILE_ATTR_FULL(PAL1, TRUE, FALSE, FALSE, 1));

Serait-ce un comportement normal étant donné que j'ai lu que la Mega Drive ne pouvait pas afficher plus de 20 sprites par ligne ?

[Invité]

Je pense que tu as donné la réponse à ta question, la limite des sprites par ligne et dans ce genre de jeu, c'est souvent un petit problème !
Tu peux décaler d'un pixel {+1, -1} à chaque tir pour éviter qu'ils soient tous sur la même ligne, et à l'oeil, ça se verra pas vraiment, mais ça serait ma méthode de Manouche codeur.  

Bon, je pense que les Pros répondront mieux que moi et seront beaucoup plus précis et techniques.

[Stef]

Oui clairement la limite par ligne est la plus génante :
- 320 pixels de sprites (transparent ou pas)en H40 et 256 pixels en H32
- 20 sprites en H40 ou 16 sprites en H32

Sinon Shingo, utiliser addSprite(..) et releaseSprite(..) à chaque nouveau / ancien bullet c'est un peu "lourd", tu devrais plutot allouer un nombre fixe de bullets (genre 10 sprites) que tu recycles à chaque fois. Quand un bullet entre/sort de l'écran tu le passes en visible/non visible avec SPR_setVisibility(..)
Ca sera bien plus rapide qu'un addSprite(..) et releaseSprite(..) 

[Invité]

Oh putain merci @Stef !

A force, on va pouvoir écrire un petit livre sur SGDK :)

Excellent !

Au moins je connais la limitation technique de la machine et du coup, on peut dire que le placement de chaque sprite a dû demander pas mal de boulot à ceux qui réalisaient les shmup à l'époque !

J'imagine le casse tête que cela doit être de faire un shmup sur SNES.

[TotOOntHeMooN]

En même temps, se sont les specs de base de la Megadrive, façon wikipedia. 
A croire que vous ne vous renseignez pas sur la machine avant de coder. 

[Invité]

En même temps, se sont les specs de base de la Megadrive, façon wikipedia. 
A croire que vous ne vous renseignez pas sur la machine avant de coder. 

Non surtout ce que je voulais savoir c'est les limites du SGDK.

[Invité]

J'ai cherché dans la documentation, mais rien n'est indiqué si la fonction SPR_setVisibility() permet de ne pas prendre en compte un sprite.

J'ai essayé d'augmenter le nombre d'ennemis à 16 dans mon tableau (j'en affiche un seul pour le moment) et du coup, soit le vaisseau du joueur ou les bullets ne s'affichent plus.

Dans le VDP de DGENS, on ne voit que les sprites visibles.

J'ai pu fixer le problème en initialisant les ennemis en dernier. Youpi !!!!

[uran]

Utilises un flag du genre "Alive" pour savoir si tu dois traiter ton Sprite courant.

[Invité]

Utilises un flag du genre "Alive" pour savoir si tu dois traiter ton Sprite courant.

J'utilise une variable "active" de type bool. Je n'ai pas encore pu déterminer pourquoi si j’initialise mes ennemis avant les bullets, ça foire, mais j'ai peut-être une piste.

[Tryphon]

En même temps, se sont les specs de base de la Megadrive, façon wikipedia. 
A croire que vous ne vous renseignez pas sur la machine avant de coder. 

Non surtout ce que je voulais savoir c'est les limites du SGDK.

SGDK ne peut pas gérer plus de sprites que la MD ne le peut

Donc sa limite théorique, c'est 80.

Mais ne perds pas de vue qu'un Sprite au sens SGDK (un metasprite) peut être constitué de plusieurs sprites au sens du VDP (sprites hardware). Donc la limite de SGDK est inférieure et dépend de la taille de tes (meta)sprites.

De plus, si les sprites sont dynamiques, alors il faut aussi charger en VRAM les tiles de chaque sprite lors de chaque frame, ce qui ralentit le bouzin et fait que tu ne peux peut-être pas atteindre le maximum théorique.

[Invité]

Annnnw !

Du coup quel est donc la taille d'un sprite hardware ?

[Tryphon]

De 8x8 pixels à 32x32, en passant par tous les multiples de 8 possibles, même rectangulaires.

[Invité]

Donc si je comprends bien, si je souhaite utiliser un sprite faisant 64x64, SGDK va me le découper en deux sprites automatiquement ?

[Tryphon]

Plutôt 4

Voire plus, s'il peut faire des sprites plus petits (je ne sais pas s'il vise le minimum de sprites hw, ou le minimum de tiles pour les construire).

[Invité]

Merci @Tryphon pour ces informations. C'est important, car mine de rien on peut vite dépasser les limites !

Actuellement j'utilise des sprites faisant 16x16, 32x16 et 32x32.

J'ai déclaré 1 sprite pour le joueur, 5 sprites pour les bullets, 4 sprites pour l'explosion (5 frames) et 32 ennemis.

[Stef]

SGDK va toujours découper pour minimiser le nombre de sprites hard, du coup tant que tu ne dépasses pas 32x32 tu restes sur 1 sprite hard en interne
En réalité SGDK te permet d'avoir jusqu'à 128 sprites (j'aime les puissance de 2 et aussi parce-que le champ link interne permet 128 sprites théoriques mais je crois que le cache interne du VDP lui ne le permet pas :p) mais effectivement tu ne pourras jamais en afficher plus de 80 quoiqu'il arrive donc il vaut mieux se limiter à ça. Aussi le SPR_setVisibility(..) permet justement de ne plus afficher le sprite par contre ses ressources restent allouées : il consomme donc encore des sprites hard (qui compte dans la limite des 80 sprites) mais il l'affiche hors écran du coup ça ne consomme plus dans la limite du "scanline", la limite la plus pénalisante à mon sens.

[Tryphon]

Tiens, question non spécifiquement liée à SGDK : qu'est ce qu'il se passe si tu modifies la SAT au milieu de l'écran (via une HInt) ? Tu peux dépasser 80 sprites affichés ?

[Invité]

Oki, donc le fait que je place tous mes sprites à x = -100 y = -100 et en faisant un hidden sur ces sprites, je devrais être tranquille.

Sauf que je ne comprend pas pourquoi dès que je déclare trop de sprites, certains sont masqués :

Code:

#define MAX_PLAYER_BULLETS 4
#define MAX_ENEMIES 8
#define MAX_EXPLOSIONS 4

Code:

for(i = 0; i != MAX_EXPLOSION; i++)
    {

        explosions[i].active = false;
        explosions[i].initialized = true;
        explosions[i].lastFrame = 0;
        explosions[i].countFrame = 0;
        explosions[i].sprite = SPR_addSprite(&spr_explosion, -100, -100, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
        SPR_setVRAMTileIndex(explosions[i].sprite, 250);
        SPR_setVisibility(explosions[i].sprite, HIDDEN);
    }

Code:

for(i=0; i != MAX_PLAYER_BULLETS; i++)
    {
        playerBullets[i].active = false;
        playerBullets[i].posx = -100;
        playerBullets[i].posy = -100;
        playerBullets[i].speed = 1;
        playerBullets[i].box.w = 8;
        playerBullets[i].box.h = 6;
        playerBullets[i].box.x = 0;
        playerBullets[i].box.y = 0;

        playerBullets[i].sprite = SPR_addSprite(&player_bullet, playerBullets[i].posx, playerBullets[i].posy, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
        SPR_setVRAMTileIndex(playerBullets[i].sprite, 300);
        SPR_setVisibility(playerBullets[i].sprite, HIDDEN);
    }

Code:

for(i=0; i != MAX_ENEMIES; i++) {
        enemies[i].active = false;
       enemies[i].box.w = 16;
        enemies[i].box.h = 16;
        enemies[i].box.x = 0;
        enemies[i].box.y = 0;
        enemies[i].posx = -400;
        enemies[i].posx = -400;
        enemies[i].sprite = SPR_addSprite(&enemy_ship, enemies[i].posx, enemies[i].posy, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
        SPR_setVRAMTileIndex(enemies[i].sprite, 140);
        SPR_setVisibility(enemies[i].sprite, HIDDEN);
    }

Code:

player.is_moving = false;
    player.dead = true;
    player.dead_position.x = -50;
    player.dead_position.y = 100;
    player.posx = -50;
    player.posy = 100;
    player.direction = 0;
    player.life = 100;
    player.lives = 5;
    player.credits = 3;
    player.lastFire = 0;
    player.box.w = 16;
    player.box.h = 16;
    player.count_kill = 0;
    player.bulletCount = 0;
    player.active = false;
    lastDirection = 0;
    player.timeShot = 40;

    player.sprite = SPR_addSprite(&player_ship, player.posx, player.posy, TILE_ATTR(PAL1, TRUE, FALSE, FALSE));
    SPR_setVRAMTileIndex(player.sprite, 100);



    player.initialized = true;

J'ai tenté d'allouer 20 ennemis, 20 explosions et 20 bullets. Du coup, je ne vois que les bullets

[upsilandre]

Tiens, question non spécifiquement liée à SGDK : qu'est ce qu'il se passe si tu modifies la SAT au milieu de l'écran (via une HInt) ? Tu peux dépasser 80 sprites affichés ?

Les attributs sont chargé dans un cache interne en debut de frame sinon ca demanderait trop de bande passante donc a priori ca changera rien de modifier la SAT en VRAM et on a pas acces au cache interne. Je crois que c'est pareille pour la PCE. Par contre sur SNES on accede directement au cache interne comme sur NES mais je doute qu'on puisse y toucher pendant l'affichage ou alors peut etre en mettant sur Off le PPU comme sur NES (y a des jeux qui l'on utilisé) et encore je suis pas sure que ca suffisent.
Sur Master System je pense qu'il charge au moins les Y dans un buffer interne en debut de frame donc on doit pas pouvoir faire grand chose non plus.

Y a un truc qu'on doit pouvoir modifier a la volé dans la SAT sur MD je pense c'est l'ID de la pattern pointé par le sprite. ca doit pas etre chargé dans le buffer interne. mais je vois pas quelle utilité ca aurait de changer ca pendant l'affichage. Tant qu'on peut pas agir sur Y y a rien d'intéressant a faire.

[Stef]

Alors en fait c'est un peu plus compliqué que ça ^^
Effectivement une partie de la SAT est cachée dans le VDP mais celle ci est mise à jour en même temps que tu écris la SAT en VRAM, donc si tu réécris une partie de la VRAM sur une hint  ça fonctionne, mais c'est long d'écrire en VRAM pendant l'affichage, du coup il vaut mieux faire comme Sonic 2 en mode splitté et désactiver l'affichage sur quelques lignes. Et effectivement en faisant de cette façon tu peux dépasser les 80 sprites (mais pas la limite par ligne).
Ensuite moi j'avais simplement tenté d'avoir plusieurs SAT en VRAM et juste de switcher de SAT sur une hint en changeant l'adresse de la SAT, mais ce ne marche pas car dans ce cas le cache interne n'est pas à jour, du coup seuls les attributs stockés en dehors du cache seront mis à jour. Castlevania utilise cette feature (je pense qu'ils l'ont découvert un peu par hasard) pour faire l'effet de réflection des sprites dans l'eau dans le niveau 2.

[upsilandre]

Tu veux dire que le buffer interne fonctionne comme un cache? si t'adresse la VRAM le VDP verifie si c'est une adresse qui tombe dans la SAT et dans ce cas il intercepte les datas pour les dupliquer aussi dans le buffer interne. C'est pas mal.
T'as l'aire de dire que ca le fait meme quand tu désactives l'affichage (donc ca le fait tout le temps), du coup si ca le fait tout le temps a quoi ca sert de bufferiser dans la VRAM les data autre que ceux qui ne sont pas stocker dans le buffer interne? Peut etre parce qu'il y a une altération de ces data interne pendant l'affichage ou alors juste pour permettre d'avoir plusieurs SAT differente en VRAM pour pouvoir préparer la seconde pendant l'affichage (mais ca on le fait plutot en RAM).

Du coup y a des documents qu'il faudrait mettre a jour genre ca:  

Note: The VDP has an internal 'cache' memory for the sprite attribute table that is loaded every vertical blanking interval, which effectively prevents the re-use of sprites by changing their position during active display that was common with other computers of the era. Tile data for sprites is also fetched during the blanking interval of the line before. This can be circumvented by changing the sprite table address register, but may result in dropped sprites.

[Tryphon]

Je pensais effectivement à changer l'adresse de la SAT plutôt que de réécrire dedans.

[Stef]

Tu veux dire que le buffer interne fonctionne comme un cache? si t'adresse la VRAM le VDP verifie si c'est une adresse qui tombe dans la SAT et dans ce cas il intercepte les datas pour les dupliquer aussi dans le buffer interne. C'est pas mal.

C'est ça : en fait c'est un cache de type "write through", j'avoue que je n'y croyais pas trop au début car c'est plus difficile à mettre en oeuvre q'un cache type "write back" qui serait mis à jour pendant le vblank (mais qui du coup consommerait des slots). En gros il y a un test sur chaque écriture en VRAM pour mettre à jour dans le cache si on écrit dans la plage de la SAT (dont l'adresse est interchangeable) et pour avoir fait des tests sur le vraie machine (en essayant de changer la fameuse adresse de la SAT, en attendant le vblank...) j'ai pu vérifier que c'est bien comme ça que ça fonctionnait.
Par contre si en VRAM la taille de la SAT fait 128 entrées (le link permet de pointer sur 128 entrées), le cache VDP est lui bien limité à 80 entrées, ce qui est compréhensible car ça doit bouffer une place non négligeable sur le die :-/ Du coup quand tu addresses les sprites > 80 (ce qui est possible via le link) alors tout les attributs fetchés depuis le cache retourne du garbage alors que ceux lus depuis la VRAM sont corrects.

T'as l'aire de dire que ca le fait meme quand tu désactives l'affichage (donc ca le fait tout le temps), du coup si ca le fait tout le temps a quoi ca sert de bufferiser dans la VRAM les data autre que ceux qui ne sont pas stocker dans le buffer interne? Peut etre parce qu'il y a une altération de ces data interne pendant l'affichage ou alors juste pour permettre d'avoir plusieurs SAT differente en VRAM pour pouvoir préparer la seconde pendant l'affichage (mais ca on le fait plutot en RAM).

En fait en réalité il n'y a aucun intérêt à ce que la partie cachée soit également stockée en VRAM car le cache le conserve indéfiniment, mais c'est juste l'implémentation qui est comme ça, c'est juste un cache type write through donc c'est un peu logique, ça cache une petite partie de la VRAM qui doit être accédé plus rapidement... Le pire c'est que si tu as 2 SAT en VRAM et que tu changes juste l'addresse de la SAT via le registre qui le permet ça ne marche pas justement, tu ne peux pas faire de "double buffering" de ta SAT de cette manière à cause de ce fichu cache qui se met à jour que sur l'écriture explicite en VRAM à l'addresse où la SAT est actuellement configurée... le seul "intérêt" c'est d'utiliser le DMA VRAM copy éventuellement mais bon en général tu as plus vite fait de faire un seul DMA pendant la VBlank depuis la RAM pour remplir la SAT :-/

Du coup y a des documents qu'il faudrait mettre a jour genre ca:  

Note: The VDP has an internal 'cache' memory for the sprite attribute table that is loaded every vertical blanking interval, which effectively prevents the re-use of sprites by changing their position during active display that was common with other computers of the era. Tile data for sprites is also fetched during the blanking interval of the line before. This can be circumvented by changing the sprite table address register, but may result in dropped sprites.

Ah oui pas vraiment, là on est sur NES ou PCE (où il y a un DMA automatique de la SAT en cache pendant le vblank ?) mais sur MD ça ne fonctionne pas du tout comme ça (sauf le fetch des tiles de sprite qui se fait effectivement durant le hblank plus ou moins)
On peut donc ré-utiliser des sprites pour dépasser la limite des 80 en mettant à jour la SAT pendant le display, je voulais d'ailleurs faire une démo qui affiche environ 200 sprites de 8x8 mais j'ai jamais eu le temps de la fini...
Mais Sonic 2 le fait déjà, je pense que lorsque les 2 joueurs perdent leurs anneaux en même temps en mode splitté (ce qui fait bien ralentir le jeu ^^) alors on doit dépasser la limite théorique des 80 sprites

[Stef]

@shingo>

Oki, donc le fait que je place tous mes sprites à x = -100 y = -100 et en faisant un hidden sur ces sprites, je devrais être tranquille.

Pas la peine de changer leur position, tu fais du travail pour rien... tu les passes juste en hidden et c'est bon

Sinon pour ton problème d'allocation, déjà il faudrait voir combien tu alloues en ressource au sprite engine lors de l'init SPR_init(..)
Ensuite je vois que tu gères manuellement l'allocation VRAM, j'espère que tu sais ce que tu fais mais à priori c'est le cas ici
il faudrait voir si tes ennemis ne dépassent pas le taille de 32x32...

Sinon quelques conseils :
Je vois que tu fais tes boucles for de la manière suivante :

Code:

for(i = 0; i != max; i++)

Je te conseille vraiment de comparer avec <, c'est pas plus lent et ça évite des bugs que tu risques de chercher longtemps si par hasard tu modifies i dans ta boucle :

Code:

for(i = 0; i < max; i++)

Aussi, pourquoi allouer 20 ennemies et 20 explosions ? souvent ce qu'on fait c'est remplacer le sprite de l'ennemi par le sprite de l'explosion quand celui ci est détruit, c'est une simplification bien pratique qui te permet d'économiser de précieux sprites et quelques traitements. Tu peux changer la source/définition d'un sprite à la volée avec SPR_setDefinition(..), bien sur ça peut changer les ressources allouées automatiquement si c'est nécessaire.

[Invité]

@shingo>

Oki, donc le fait que je place tous mes sprites à x = -100 y = -100 et en faisant un hidden sur ces sprites, je devrais être tranquille.

Pas la peine de changer leur position, tu fais du travail pour rien... tu les passes juste en hidden et c'est bon

Sinon pour ton problème d'allocation, déjà il faudrait voir combien tu alloues en ressource au sprite engine lors de l'init SPR_init(..)
Ensuite je vois que tu gères manuellement l'allocation VRAM, j'espère que tu sais ce que tu fais mais à priori c'est le cas ici
il faudrait voir si tes ennemis ne dépassent pas le taille de 32x32.

Merci Stef, t'as réponse à résolu mon problème.

Quel plaisir de voir autant de sprites !

[Invité]

Sinon quelques conseils :
Je vois que tu fais tes boucles for de la manière suivante :

Code:

Code:

for(i = 0; i != max; i++)

Je te conseille vraiment de comparer avec <, c'est pas plus lent et ça évite des bugs que tu risques de chercher longtemps si par hasard tu modifies i dans ta boucle :

Code:

Code:

for(i = 0; i < max; i++)

Aussi, pourquoi allouer 20 ennemies et 20 explosions ? souvent ce qu'on fait c'est remplacer le sprite de l'ennemi par le sprite de l'explosion quand celui ci est détruit, c'est une simplification bien pratique qui te permet d'économiser de précieux sprites et quelques traitements. Tu peux changer la source/définition d'un sprite à la volée avec SPR_setDefinition(..), bien sur ça peut changer les ressources allouées automatiquement si c'est nécessaire.

Au début j'utilisais for(i=0; i < MAX; i++); mais j'avais un doute alors je suis passé à !=

Je vais modifier le code, en tout cas merci pour ta remarque.

Ah excellents, je ne sais pas qu'on pouvait remplacer un sprite initialisé ! Voilà de quoi me faire gagner quelques sprites supplémentaires :)

[Invité]

@Stef J'ai donc fais que tu as dis, je recycle le sprite en changeant sa définition. Sauf que du coup, je ne peux plus choisir l'index dans la VRAM pour chaque sprite sinon forcément, quand je change la définition, c'est pour tous les sprites utilisant le même index dans la VRAM !

Donc ma question, est-ce un problème côté performance / pratique de laisser SGDK gérer l'index des sprites dans la VRAM ?

[Invité]

Je suis en train de bosser sur les menus et j'aimerais utiliser une palette pour un texte seulement.

La fonction VDP_setTextPalette() définie une palette pour tous les textes et je n'ai pas trouvé d'autres fonctions...

Un petit indice à me donner ?

Merci d'avance !

edit : trouvé ! Il faut utiliser la fonction VDP_setTextPalette() avant chaque VDP_drawText();

[Stef]

@Stef J'ai donc fais que tu as dis, je recycle le sprite en changeant sa définition. Sauf que du coup, je ne peux plus choisir l'index dans la VRAM pour chaque sprite sinon forcément, quand je change la définition, c'est pour tous les sprites utilisant le même index dans la VRAM !

Donc ma question, est-ce un problème côté performance / pratique de laisser SGDK gérer l'index des sprites dans la VRAM ?

En fait quand tu vas changer la définition d'un sprite, SGDK va allouer les ressources sur les parties qui sont en allocation automatique, mais comme toi tu positionnes manuellement le VRAM index alors il ne va pas toucher l'allocation VRAM (juste l'allocation sprite hard). Par contre le sprite engine va remplacer les data à la position VRAM utilisée par ton sprite pour qu'il soit correctement affiché donc en théorie juste après avoir changer la définition c'est à toi de changer manuellement la position VRAM pour qu'elle pointe à l'endroit où tu souhaites stocker les pattern de l'explosion (et donc ne pas écraser les pattern du vaisseau). Et comme tes explosions sont animées c'est encore plus sioux... en gros quand tu passes à l'explosion tu devrais repasser en allocation VRAM automatique ça serait plus simple.
En réalité tu peux tout tuner et gérer manuellement, le sprite engine te laisse cette possibilité... par exemple tu as la SPR_setAutoTileUpload(..) qui te permet de désactiver l'upload automatique des tiles en VRAM lorsque ton sprite est animé, mais ça signifie que c'est à toi de gérer cet aspect (en uploadant toutes les frames à l'avance et en changeant le tile VRAM index comme il faut ou en uploadant manuellement les tiles à chaque fois mais dans ce cas autant laisser faire le sprite engine).

[Invité]

@Stef merci j'ai fais comme tu m'as dis, ça marche très bien comme cela.

[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