prblm de fps ... - Page 1

j'utilisais Gprectfill pour effacer mon ecran, avec j'etais a 42fps stables tout le temps,
g viré gprectfill pour mettre cette fct :

void afficher_bg(unsigned short * bg)
{
char cpt_y ;
short cpt_x ;
unsigned short *p_buf = (unsigned short *) (gpDraw[nflip].ptbuffer);

for(cpt_x=0;cpt_x<320;cpt_x++)
for(cpt_y=0;cpt_y<240;cpt_y++)
*(p_buf + cpt_x*240 + (239-cpt_y)) = 0xffff ;
//*(p_buf + cpt_x*240 + (239-cpt_y)) = *(bg + cpt_x*240 + (240-cpt_y)) ;
}

qt je touche a rien, le fps est stable a 35fps, qt je commence a jouer (et que le nombre de sprites affichés augmente) ca passe a 40 puis a 52fps
ca reste a 52 tant que g beaucoup de sprites (qui se deplacent) affichés puis sa commence a descendre avec le nombre de sprites (quant il n'y a qu'un sprite, ca varie entre 30 et 50 tout le temps)

je pete un cable, si qq peut m'aider ...

si j'affiche un bg au lieu du blanc en faisant ca :

//*(p_buf + cpt_x*240 + (239-cpt_y)) = 0xffff ;
*(p_buf + cpt_x*240 + (239-cpt_y)) = *(bg + cpt_x*240 + (240-cpt_y)) ;

le nombre de fps ne varie pas et reste a 27 ^^'

C'est quoi la question ?

erf ^^'
la question c : pourquoi le fps n'est pas stable ??

T'as fait tes tests sous Geepee32 ? Si c le cas, ça vient peut-être simplement de lui

non j'utilise pas geepee je fais tout tourner ss vrai gp

bon rov, fit nous un moteur 3d ultra complexe, il va tourner vraiment super vite :P

Ouais, hallucinant, tu remplis avec une valeur 16bit tout ce qui a de plus banale (0xffff) et le fps n'est pas stable dans le temps. As tu essayé de passer en 8bit pour voir si le resultat etait le meme ?
je me demandais si tu n'avais pas d'autres traitements ailleurs dans ta boucle...
et quand tu remplis avec les valeurs de ton objet 'bg', le fps est 'vraiment' stable à 27 ou il oscille entre 25-28 ? (ce qui expliquerai qu'il y a des traitements parasites dans la console, genre des threads, ou le idle qui merde...)
je ne suis pas tres precis, je me mets a peine a la prog sur gp32, mais ton cas m'interesse, car justement je reflechi a des optims de refresh de screen et de gestion des sprites...

> bon rov, fit nous un moteur 3d ultra complexe, il va tourner vraiment super vite :P

lol déjà comme je galere la, je suis ds la merde si je me met a la 3D
remarque, une fois que la gp a bien chauffée sa va vraiment vite g mes chances

> As tu essayé de passer en 8bit pour voir si le resultat etait le meme ?

non, tout mon jeux est en 16bit c la merde si je doit passer en 8 bits ^^

> quand tu remplis avec les valeurs de ton objet 'bg', le fps est 'vraiment' stable à 27 ou il oscille entre 25-28 ?

il oscile entre 26 et 27 (ca bouge vraiment rarement qt mm) mais ca viens du fait que le nombre de sprites n'est presque jamais le mm, et de la gestion des colisions
si j'utilise le gprectfill, ca varie de 1 aussi

je viens de retester avec le gprectfill, c pas 42 mais 45 / 46

arf !!! je viens juste de tester avec un gpbitblt normal (comme je l'avais déjà fait avant) je ne pert plus 20fps juste pour lui (comparé au gprectfill)
au 'repos' ca tourne entre 36 et 42 fps et 45 a 46 quant le prog est 'chaud' (lol) avec pleins de sprites (et des fois ca descend jusqu'a 33 qt il n'y a qu'un sprite, et qu'il se deplace lentement ...)
alors que cette nuit, ma fct afficher_bg niké de 5fps celle de gp, now c elle qui me nike
g changé mon bg, ca peut venir de ca ??

je viens de tester sans aucun effacage d'ecran ni bg, je tourne en fixe a 52fps

bhouuuu je comprend + rien :'(

est ce possiblre que la gp s'overcloke d'elle mm ? ou quelle 'optimise' un truc que l'on doit faire periodiquement ? ^^

> ce qui expliquerai qu'il y a des traitements parasites dans la console, genre des threads, ou le idle qui merde...

c bien possible ...

Je me demande si ton pb de compteur viens pas des libs.

Si tu compiles sous ADS avec les libs cherche pas plus loin c ca

non il est sous sdt, j ai eu un pb similaire au niveaus fps mais cela venais de ma boucle de temps, mais je pense pas que tu ais fait cette erreur la. du coup on a fait une boucle generale de temps puis une variable de pas lol de toute façon mon code est un gros bordel qu il faut que je re face ( petit question H.S comment on structure son code ???)

je calcule les fps comme ca :

long time=0 ;
short fps=0,fps_count=0 ;

do {

// boucle du jeux

fps++ ;
if(GpTickCountGet() > (time + 1000)) { time=GpTickCountGet() ; fps_count=fps; fps=0 ; }
} while(1) ;

lock ma fait remarqué que ce n'est pas tres precis, mais l'erreur ne peut etre que de 1fps
ca ne peut pas expliquer une chute (ou montée) subite de 10fps surtout que le jeux est réelement ralenti ou acceléré (c bc + fun a 52fps ) ...

est ce possible que la gp puisse adapter sa vitesse a la charge de travail a faire (pour economiser les piles par exemple) ?
car le fps est au minimum quant j'ai un seul sprite (ou meme aucun) qui bouge (tous les autre sont fixes)
il est aux maximum avec une dizaine de sprites qui bouge (et toute les colisions suplementaire a calculer)

Physiquement le LCD tourne à 50Hz soit maxi 50FPS donc tu as une erreur de 4%, ça va moi j'en ai une de 6% :-)

je savais pas pour le lcd ^^

> donc tu as une erreur de 4%, ça va moi j'en ai une de 6% :-)
donc tu as un fps de 53 ?

oui

Mais c'est nul un lCD à 50Hz() même celui d'une TI va plus vite

En effet. Les TI-89/92+ (TI-92+ HW2 du moins, je ne sais pas pour les TI-92)/V200 ont un LCD à 90 Hz.

50Hz c'est largement suffisant pour un LCD, petit rappel 50Hz sur un LCD c'est l'equivalent d'une TV 100Hz entrelacé

je sais pas pourquoi ca varie tellement, mais en tout cas ta fonction est super lente (a moins que j'en aie pas bien compris le but...)

noferov a écrit :
void afficher_bg(unsigned short * bg)
{
char cpt_y ;
short cpt_x ;
unsigned short *p_buf = (unsigned short *) (gpDraw[nflip].ptbuffer);

for(cpt_x=0;cpt_x<320;cpt_x++)
for(cpt_y=0;cpt_y<240;cpt_y++)
*(p_buf + cpt_x*240 + (239-cpt_y)) = 0xffff ;
//*(p_buf + cpt_x*240 + (239-cpt_y)) = *(bg + cpt_x*240 + (240-cpt_y)) ;
}

en faisant ca ca irait deja mieux:

#define	WORD	unsigned short
[b] [/b]
void		afficher_bg(WORD * bg)
{
	short	cpt_y;
	WORD	*p_buf = (WORD *)gpDraw[nflip].ptbuffer;
	WORD	*p_count;
[b] [/b]
	for (p_count = p_buf + 76800; p_buf < p_count;[b][/b])
	{
		cpt_y = 240;
		while(--cpt_y)
			p_buf[cpt_y] = 0xffff;
			//p_buf[cpt_y] = bg[cpt_y];
		p_buf += 240;
		bg += 240;
	}
}

(dsl pour le #define, ms ca me soule de taper unsigned short, c trop long..... )

d'ailleurs, une simple boucle de copie de 0 a 320*240 suffirait non?

et au lieu de caster en u short *, caste plutot en u int * (la gp est bien 32 bits?) ca ira aussi vite point de vue cycles processeur et la boucle sera deux fois moins longue...

de 0 a 160*240 avec un pointeur unsigned int, au lieu de 0 a 320*240 avec un unsigned short...

g testé ta fct (merci dailleur ), elle tourne entre 9 et 11ms
je l'ai passé en 32bits pour afficher 2 pixels a la fois, elle tourne entre 4 et 5ms
apres g testé le gprectfill de gp, il tourne entre 3 et 4ms
a chaque fois, le fps etait stable

par contre, si je doit afficher un bg et non du blanc la fct va aussi vite que celle de gp, et ca tourne pas assez vite (meme en affichant le bg a coup de 2 pixels)

en faisant mes test de temps d'execution, g regardé le temps d'un GpSurfaceFlip() et ce batard me bouffe entre 3 et 26ms a chaque flip de l'ecran avec une moyenne de 9ms. 26ms c plus du double de ce que prend le moteur de mon jeux (toutes les colisions + l'affichage ~12ms)

g viré le GpSurfaceFlip en faisant afficher tout le temps le buffer d'ecran 2 auquel je changais l'adresse pour lui donner alternativement celles des buffer 0 et 1 (ou le jeux est affiché)

mon prog tournait entre 72 et 116fps (alors que je suis a 42 avec le GpSurfaceFlip) mais sa clignotte a mort, je c pas pourkoi

comment se caler sur la frequence du lcd pour faire mes flip ?
comment vous faites ceux qui n'utilisent pas les fct gp ?
la technique du double buffer d'ecran est 'elle la seule possible sur gp ?

Moi je n'utilise pas le double buffer et en effet ça scintille un peu. Ca vient du fait que tu swappes des images directement à l'écran. Il faut s'arranger pour les swapper pendant que le lcd n'affiche rien. Mais je ne crois pas qu'il existe de synchro verticale sur la gp32. Mr_spiv à fait un ex de simulation de cette synchro je crois.
En tout cas le flip c'est lent, ça c'est clair !

> Mr_spiv à fait un ex de simulation de cette synchro je crois.
c ca qu'il utilise ds ses demos de scroll ?

> Moi je n'utilise pas le double buffer et en effet ça scintille un peu.
ah oki je me demandais comment faire avec les 2 buffer quant je veut restaurer le bg sous mes sprites, now je le c, pas de dble buffer lol

noferov a écrit :
g testé ta fct (merci dailleur ), elle tourne entre 9 et 11ms
je l'ai passé en 32bits pour afficher 2 pixels a la fois, elle tourne entre 4 et 5ms
apres g testé le gprectfill de gp, il tourne entre 3 et 4ms
a chaque fois, le fps etait stable

par contre, si je doit afficher un bg et non du blanc la fct va aussi vite que celle de gp, et ca tourne pas assez vite (meme en affichant le bg a coup de 2 pixels)

pour remplir de blanc t'as pas besoin de deux boucles imbriquees, ca fait plein de calculs qui servent a que dalle, pareil pour afficher le bg...
en faisant un truc comme ca ca marcherait pareil:

{
  register UINT	*p_buf;
  register int	i;
[b][/b]
  p_buf = (UINT *)gpDraw[nflip].ptbuffer;
  i = 38400;
  while (i--)
    p_buf[i] = 0xffffffff;
}

apres pour optimiser plus ca devient trop specifique et trop dependant de comment le compilateur compile ton code.
et je connais pas l'assembleur de l'arm de la gp, donc je peux pas te dire si ca vaut mieux d'indexer la mem ou d'incrementer directement le pointeur... enfin arrive la c'est sans doute pas cette fonction la qui bouffe le plus de temps dans ton prog

je v tester ca

register ca veut dire koi ? qu'on va utiliser les registres du proc au lieu de la ram ?

> enfin arrive la c'est sans doute pas cette fonction la qui bouffe le plus de temps dans ton prog
ué c clair mais bon, vu quelle a pas mal avancée comme fct, je v en faire profiter toute les autres du même style, donc c cool merci

ca tourne entre 3 et 4ms

par contre, si j'achiffe le bg c entre 13 et 14ms

sa fait 10 ms en + ca, c vraiment beaucoup pour juste une lecture en + ds la boucle

je dis ptet une connerie, mais une lecture ca doit pas etre + rapide qu'une ecriture ?

rov: cf mini-msg

noferov
a écrit : register ca veut dire koi ? qu'on va utiliser les registres du proc au lieu de la ram ?

Théoriquement oui, mais en pratique presque tous les compilateurs récents ignorent ce mot-clé et laissent à leur optimisateur le choix d'utiliser un registre ou pas pour cette variable. Par exemple, GCC ne respecte les déclarations register que si on compile sans optimisation (-O0) ou si on spécifie un registre concret explicitement (extension GNU).