[MD] Gens et overscan

[Tryphon]

Je cherche le réglage, s'il existe, pour que Gens (ou un autre ému éventuellement) affiche l'overscan de la MD (pour utiliser l'astuce de changer la couleur de background suivant mes routines, afin de déterminer le temps qu'elle prenne).

[Hpman]

Jette un oeil sur Exodus, il me semble qu'il en affiche tout ou partie.

[Tryphon]

Le problème d'Exodus c'est qu'il tourne très lentement chez moi (PC peu rapide).

[Stef]

Peu d'émulateurs ont cette feature (et Gens ne l'a effectivement pas). Exodus le fait et je crois bien que c'est le seul, tu souhaites suivre la conso CPU pendant le VBlank c'est ça ?

[Tryphon]

Exactement.

Exodus tourne à 10 fps chez moi, c'est difficilement exploitable...

[troudki]

hello Tryphon,
ton code , c'est une sorte d'outil de "profiler" directement visible sur l'écran durant l'execution du jeux ?

[upsilandre]

En désactivant l'affichage sur la colonne de gauche (8 pixel) tu dois pouvoir faire apparaître la couleur d'overscan sur n'importe quelle emulateur et donc avoir ton CPU Meter dans cette colonne.

edit: en mode 5 ca n'a plus l'aire d'exister, tanpis

[Hpman]

Toujours possible de laisser des trous dans le décor pour voir la couleur de fond le temps de debugger.

Sinon y'a un compteur de ligne fourni par le VDP, mais c'est moins visuel.

[troudki]

il serait possible d'avoir un exemple en SGDK de vos profiler ?

[Stef]

En désactivant l'affichage sur la colonne de gauche (8 pixel) tu dois pouvoir faire apparaître la couleur d'overscan sur n'importe quelle emulateur et donc avoir ton CPU Meter dans cette colonne.

edit: en mode 5 ca n'a plus l'aire d'exister, tanpis

Pour visualiser la conso CPU pendant la période active c'est simple, il suffit de changer la couleur de fond et d'avoir un fond transparent (au moins sur une ligne). Ce qui est plus compliqué c'est de suivre la conso pendant le VBlank (par exemple pour voir combien de % du VBlank tu consommes avec le DMA).
SGDK a des fonctions de "timer" qui peuvent aider pour profiler :

https://github.com/Stephane-D/SGDK/blob/master/inc/timer.h

La fonction getTimer est la plus facile pour ça :

Code:

u32  getTimer(u16 numTimer, u16 restart);

Tu spécifies un numéro de timer (SGDK autorise 16 timers, c'est largement suffisant donc de 0 jusqu'à 15) et ça te retourne le temps écoulé en nombre de 'subtick' (soit 1/76800 de second) depuis le dernier appel à startTimer(..) ou getTimer(..) avec la paramètre restart = TRUE.

Le problème de cette méthode c'est qu'elle ne fonctionne pas pour mesurer un lap de temps court juste pendant le VBlank (car le V counter fait un rollback du coup impossible de savoir où on en est réellement) :-/

[upsilandre]

Sur Mesen on a l'event viewer. Ca affiche l'image avec tous l'overscan et ca place des marqueurs colorés sur l'image pour divers type d'event. Lecture/ecriture vers le PPU, vers le mapper, nmi, irq, sprite 0 hit et aussi les break point (donc on peut y mettre ce qu'on veut comme marqueur) c'est juste génial comme outil
Sinon y a les script Lua qui peuvent t'ajouter un layer visuel sur les ressources consommé en temps réel. Ca va tres vite a codé. C'est quelques minutes

[troudki]

Pour visualiser la conso CPU pendant la période active c'est simple, il suffit de changer la couleur de fond et d'avoir un fond transparent (au moins sur une ligne)

oula...pas sure de bien comprendre ta technique Stef   , il suffit  de rajouter un VDP_setPaletteColor ( 0, 0x0F0F ) dans sa fonction pour visualiser sa conso CPU ?

[Hpman]

Tu changes la couleur de fond entre les différents étapes de ton code (couleur x pour mettre à jour les IA, y pour trier les sprites, etc...), ça te permet de visualiser le temps passé dans chaque fonction.
Tu mets une couleur avant de waitVBlank, comme ca tu peux voir le temps CPU libre.

[Stef]

Voilà, hpman a bien décrit le truc

[troudki]

Le code est sous cette forme là?
J'ai un bel effet stroboscopique sous les yeux  en couleur de fond 

Code:

while(TRUE)


    {





        updateIA();


        updatePlayer();       


        SPR_update();





        VDP_setPaletteColor(0,0x000F);


        VDP_waitVSync();


    }


/////

void updateIA()


  {


  routine calcul ici;


 VDP_setPaletteColor(0,0x0F0F);


 }



void updatePlayer()


  {


  routine calcul ici;


 VDP_setPaletteColor(0,0x0F00);


 }



[Hpman]

Genre comme cela:

Code:

while(TRUE) {
 VDP_setPaletteColor(0,0x0F0F);
 updateIA();
 
 VDP_setPaletteColor(0,0x0F00);
 updatePlayer();      
 
 VDP_setPaletteColor(0,0x000F);
 SPR_update();
 
 VDP_setPaletteColor(0,0x0000);
 VDP_waitVSync();
}

Si c'est soirée disco tu as probablement du frameskipping...

[Tryphon]

Je vais juste commenter le chargement du tileset comme ça toutes les tiles seront couleur de fond

[Tryphon]

Bon, j'ai désactivé le chargement du tileset (mais pas l'affichage des maps) et ça donne ça :



Le bleu, c'est la màj des objets
Le vert, c'est la màj des sprites
le jaune (une frame sur 16), c'est la màj de la carte
le gris, c'est libre

Le gestionnaire d'objets est encore rudimentaire (s'il est non-visible, l'objet regarde si par hasard il ne serait pas devenu visible, et vice-versa) mais le gestionnaire de sprites est à peu près ce que je voulais. Au niveau perfs, c'est ce à quoi je m'attendais (vous noterez sur la vidéo jusqu'à 8 sprites dynamiques simultanés sans perte de frame).

Ce qui m'embête, c'est la màj de la carte. On voit pas bien, voici une pause sur une frame (pas tiré de cette vidéo, le scrolling était vertical, mais c'est similaire) :



On voit que la zone jaune fait à peu près autant que 4 vertes.

Or la jaune correspond à une copie d'une ligne dans la tilemap (2 en fait parce que les metatiles font 16 pixels), soit 84 mots, alors qu'une seule verte correspond à la màj des patterns d'un sprite (soit une trentaine de patterns de 32 octets chacun) + l'entrée SAT correspondante.

Donc y'a un truc pourri dans ma màj de tilemap. Un indice : je ne la fais pas pendant la VBlank (alors que pour la màj des sprites par exemple, j'utilise VDP_loadTileData(..., DMA_QUEUE) et VDP_updateSprites(..., TRUE)). Est-ce que ça suffirait à expliquer une aussi nette différence de performances ?

[Hpman]

La fiche technique donne 4Ko de transfert VRAM par frame pendant l'affichage, donc 84 mots c'est théoriquement ~10 rasters.

Y'a de la décompression qui tourne derrière? même pour les sprites ça me parait beaucoup de temps cpu.

[Tryphon]

Pas de décompression, juste des métatiles.

Mais comme elles sont stockées dans l'ordre

Code:

0 1
2 3


y'a quand même un petit travail de réorganisation.

D'ailleurs je pourrais faire un cache en RAM avec les tiles dans le bon ordre, et envoyer ça pendant la VBlank, ça accélèrerait peut-être les choses ?

Pour les sprites, un truc que je trouve chelou, c'est que les lignes vert atari (0x0F0) contiennent seulement les lignes suivantes :

Code:

KDebug_AlertNumber((u32) object);
 KDebug_Alert("is_activated");
 object->sprite->x = fix32ToInt(object->x) - camera.left;
 object->sprite->y = fix32ToInt(object->y) - camera.top;

Et pourtant j'ai 4 raster à chaque fois, c'est curieux...

Edit : ooookay, c'est les KDebug qui sont hyper-lents...

Edit2 : cela dit, il n'y en a pas dans la màj de la map Ce qui rend le différentiel complètement dingue (la màj map met autant de temps que les 8 sprites...)

[upsilandre]

l'acces a la VRAM pendant l'affichage est tres lent, y a juste quelques slot disponible, normalement c'est a eviter.

[Tryphon]

Je savais, mais je pensais pas à ce point...

Bon, je vais faire un cache en RAM et utiliser DMA_queueDma pour que la copie se fasse pendant la VBlank.

[upsilandre]

J'ai pas bien compris ton CPU meter. il ne nous montre pas de toute facon ce qu'il se passe pendant le Vblank? Donc c'est quoi le vert?

[Tryphon]

C'est la partie du code qui met à jour les metasprites :

* vérifie si le sprite est visible
* màj des coordonnées du sprite
* vérifie si la frame doit être changée (et màj certains flags pour l'utilisateur)
* si oui, ajoute dans la DMA queue les infos pour charger les patterns suivants, et met à jour la SAT

[upsilandre]

Ok donc y a pas dedans le chargement en VRAM alors que sur la bande jaune doit y avoir une partie traitement (decompression tilemap?) + le chargement (lent) en VRAM.

[Tryphon]

Oui. Mais ça concerne seulement 84 octets mots (168 octets), je pensais que ça restait soft.

[Hpman]

Laisse la fonction faire le taf et retire juste le transfert (ou mets le en une autre couleur), histoire de voir.

[Tryphon]

'tain chuis con, t'as raison !

Bon, ben c'est bien le transfert qui ralentit tout, le reste de la fonction est quasi-invisible.

Merci :)

[upsilandre]

Oui. Mais ça concerne seulement 84 octets mots (168 octets), je pensais que ça restait soft.

oui c'est vrai que c'est beaucoup. Si je ressort les vieux schema


je vois 18 slots disponible par scanline pendant l'affichage. En lecture les slot sont 32bit mais je crois qu'en ecriture c'est 8bit donc ca ferait 18 octets par scanline? soit une dizaine de scanline

[upsilandre]

Apres le probleme c'est que pour un scroling horizontal il faut un mode d'auto-incrementation spécial de l'adressage VRAM sinon faut recharger l'adresse a chaque acces et c'est encore plus lent. La megadrive a sans doute ce type de mode d''auto-incrementation (la Master System ne l'a pas par exemple) mais faut peut etre quand meme que tu le declare.

edit: apparement c'est le registre 15 du VDP qui s'occupe de ca