Utilisation CPU

[Dr.Vince]

Bon bah voilà, j'arrive pas à remettre la main sur le bout de code qui permet de connaitre l'utilisation du CPU.

Donc si quelqu'un remettait la main dessus ce serait vraiment cool ;)

Merci d'avance

[thoduv]

Je suis également intéréssé ! :)

[Dr.Vince]

Bon ça y est j'ai enfin trouvé dans l'ancien forum :
void InitTimers() {
//Stoppe le timer
R_TIM1CNT=0;
//Le remet à zéro
R_TIM1COUNT=0;
//65 kHz
M_TIM1CNT_SPEED_SELECT_SET(2);
//Démarre
M_TIM1CNT_TIMER_START;
}

#define UtilCPU() (R_TIM1COUNT)

void NouvelleTrame() {
R_TIM1CNT=0;
R_TIM1COUNT=0;
M_TIM1CNT_SPEED_SELECT_SET(2);
M_TIM1CNT_TIMER_START;
}

int i;
InitTimers();
while(1)
{
[code de gestion]
i=UtilCPU();
ham_DrawText(0,0,"CPU: %02i.%i%% ",i/10,i%10);
AttendVSync();
NouvelleTrame();
[code quand la VBL est passée]
}

Merci Brunni :wub:

Si quelqu'un utilise une autre méthode merci de le dire !!

Bon je l'ai mis en pratique mais j'obtiens n'importe quoi !! >(

Quelqu'un pourrais me dire d'ù viens mon erreur ???
voilà mon code :

while(TRUE){
if(NEW_FRAME){
u8 i=UtilCPU();
ham_VBAText("CPU: %02i.%i%% \n",i/10,i%10);
NouvelleTrame();
// mon code du jeu
NEW_FRAME = FALSE ;
}
}


Et voilà les valeurs que j'obtiens :

CPU: 00.6%
CPU: 16.5%
CPU: 09.8%
CPU: 00.6%
CPU: 00.6%
CPU: 00.6%
CPU: 16.5%
CPU: 09.8%
CPU: 00.2%
CPU: 00.9%
CPU: 00.6%
CPU: 16.5%
CPU: 09.4%
CPU: 00.6%
CPU: 00.6%
CPU: 00.6%
CPU: 16.8%
CPU: 09.5%
CPU: 00.6%
CPU: 00.6%
CPU: 00.6%
CPU: 16.6%
CPU: 09.7%
CPU: 00.5%
CPU: 00.7%
CPU: 00.6%
CPU: 19.8%
CPU: 06.4%
CPU: 00.3%
CPU: 00.9%
CPU: 00.6%
CPU: 19.9%
CPU: 06.4%
CPU: 00.2%
CPU: 00.6%
CPU: 00.8%
CPU: 19.8%

[Brunni]

Je pense que HAM utilise le timer 1 pour lui, mais il faudrait vérifier. Essaie de remplacer tout ce qui est R_TIM1* par R_TIM2 par exemple.

[Mollusk]

Moi j'utilisais pas du tout ca comme méthode, mais bon, c'est peut-etre celle-là la meilleur...

Concrètement, je regardais à quel HBL on est au moment au moment de l'attente Vsync...
Une variable dans le vbl qui compte le nombre de vbls, remis à 0 par la fonction d'attente vbl.

Si jamais on n'a pas passé plusieurs VBL, on est à moins de 100% d'utilisation. A partir de là, il est facile de calculer le % du temps pris en faisant le nmobre de HBL passés divisé par le nombre total pendant une trame (sur gba je ne sais plus combien c'est, par contre). Ca marchait plutot bien comme ca

[Dr.Vince]

et un ptit bout de code pour illuster tout ça Mollusk ???

[Mollusk]

euh, là tout de suite je l'ai pas sous la main, parce que j'ai changé de PC et que j'ai pas tout mon paquet de codes gba de l'époque :s

mais c'est vraiment pas méchant...



#define N_HBL 263 // sur DS en tout cas me semble, sur gba ca fait moins
#define VCOUNT_VBL 192 // moment où le vbl arrive sur DS, sur gba ca sera 160
#define REG_VCOUNT _REG16(0x04000006)


void VSynchtruc(void){
float cpu = VCOUNT ;
if (cpu > VCOUNT_VBL) cpu -= VCOUNT_VBL; // nombre de trucs depuis le vbl
else cpu += N_HBL - VCOUNT_VBL;
/* comme ca fait une valeur de 0 à 192, on rajoute les hbl de 192 à 263
pendant lesquels le prog a tourner...
donc un VCOUNT a 0 signifie déjà 263-192 hbl (à adapter sur gba)*/

cpu = (cpu*100)/N_HBL;

//afficher le taux de cpu en pourcentage

Attendrelasupersynchrosanslaquelleleprogmarchen'im portecomment();
}


Voilà, c'était un truc du genre me semble


}

[Brunni]

Moi j'utilisais pas du tout ca comme méthode, mais bon, c'est peut-etre celle-là la meilleur...
Ma méthode est plus précise, mais elle utilise un timer (enfin, je dirais même qu'elle le gaspille si vous ne le reservez que pour ça).
Ta méthode est moins précise (227 unités par frame sur GBA, soit précis aux 0.45% de CPU près) mais elle ne gaspille pas de timer. C'est particulièrement mieux si vous utilisez HAM, qui réserve déjà 2 timers sur 4 pour lui je crois.

J'avais changé ma méthode car il fallait quelque chose de précis pour stabiliser les valeurs (en gros j'affiche la valeur la plus haute que j'ai eue, tant que la variation est inférieure à 0.5, comme ça s'il oscille entre 39.2 et 39.4% de CPU, il mettra définitevement 39.4%, et ce "record" sera annulé s'il tombe en-dessous de 38.9).
Et c'était aussi pour l'"anti-rame" de mon Sonic (légère désynchronisation lorsqu'on est près de 100% pour éviter de chuter d'un coup à 30 FPS dans ces zones, et avec l'autre méthode si on est genre entre 98 et 103%, ça foirait complètement).