PpHd Le 28/06/2004 à 15:23 Trop pixelise a mon avis.
Au fait, c'est en C pur (compilé en -Os), donc je trouve que c'est pas trop mal.
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
lionelA> Je pense que tu peux gagner pas mal en vitesse en deroulant au maximum tes boucles et surtout en reecrivant ton moteur en asm. Mais sinon tu comptes t'y prendre comment pour rendre une map de tiles? Parce que c'est quand meme bien different que de travailler sur un unique sprite.
Cad "en deroulant au maximum les boucles" ?
pour ce qui est de la map pour l'instant le moteur affiche une image contenant tous les pixels et donc il suffit de creer cette image a partir de tiles et c gagné
PpHd Le 28/06/2004 à 17:07 Tu perds l'interet d'utiliser des tiles, non ?
Une solution est de precalculer "l'image" de seulement une petite partie de la map, et de la reactualiser regulierement pendant le rendu, en fonctions des deplacements de la camera (si possible pas a chaque frame).
-> oui je garde l'utilité des tiles, ca permet de pas stocker les grosses images dans des fichiers
-> Si je devais loader les tiles a chaque fois que yen a besoin je perdrais enorment de temps
-> L'initialisation est longue parce qu'il ya des calculs de floatants pour la matrice de projection (il est possible de le faire avec des short mais je l'ai pas encore fait) et je calcule deja une table de 64 directions pour les cos et sin
Si vous avez pris le source c'est la fonction m7_CreateMatrix() qui doit etre optimiser pour l'init
-> les instructions de tests et de branchements (bouclage) sont tellement rapides qu'il n'est pas necessaire de derouler les boucles (de toute facon le moteur est configurable donc je ne connais pas forcement le nb d'iterations et puis si je fais le rendu en 40x25 ca fait deja 1000 fois la suite d'instruction : vive l'optimisation du code en taille mem !)
-> pour la ti92p c'est normal, je fais des masques sur la config ti89, trouve les touches equivalentes et ca sera bon (quand le moteur de mode7 sera fini il n'y aura pas de gestion du clavier car cela n'a rien a voir)
en asm une boucle for se resume a ca : "DBRA (registre de boucle), etiquette"
c a d 1 instruction (je dis pas que gcc genere exactement ca mais a peu de choses pres oui)
ma fonction de rendu imbrique 2 boucle presque sans aucun traitement dans le premier niveau et 75 lignes de code dans l'autre
je ne vois pas comment je pourrais derouler une partie et pas tout...
Au fait, tu atteinds combien de fps avec une resolution de 80x50?
essaye de disabler les tests de depassement de la carte, ca redessine la carte avec des decalages a l'endroit ou il doi y avoir du noir et on ne voi pas la difference au niveau des fps, je prefere laisser ces tests qui sont insignifiants en terme de temps d'execution par rapport aux acces memoire des matrices et aux memcpy
sinon je ne compte pas generer la carte au fur et a mesure du deplacement car la memoire de la ti permet largement de contenir un niveau en ndg donc je genererai la carte a chaque changement de map
Entre deux instructions qui peuvent faire la même chose, on a parfois des différences de 2 cycles (voire 4). Ça peut paraître insignifiant, mais si ça intervient dans l'affichage de pixel, ça intervient quand même 8000 fois (en 150x50), ce qui fait gagner 16000 cycles (ce qui te fait gagner 1.3 ms par frame affichée, donc si ton fps est de 50, il passe à 54 pratiquement, juste pour une différence de 2 cycles, souviens toi, ça veut dire que si tu arrives à gagner 10 cycles - et ce n'est pas compliqué en ASM de réussir à gagner 10 cycles - ton fps arriverait à 75)
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Salut !
J'ai essayé d'optimiser le moteur pour avoir des graphisme plus joli et je me suis aperçu que deux petits "if" (2 lignes) multiplient les fps par 6
c'est ces lignes qui sont coupables :
if((pix0 << offsetmap) & 0x80)
dispbyte0 |= PIX;
if((pix1 << offsetmap) & 0x80)
dispbyte1 |= PIX;
Si quelqu'un a une idée du pourquoi ca fait ramer autant, dites le moi et je pourrait peut etre optimiser
en 80x50 sans ces lignes j'atteint presque 30fps (a la louche) ce qui veut dire que ca serait la revolution si je pouvait optimiser
Bah, que sont pix0 et pix1 déjà ?
Sinon, pour la lenteur, c'est peut être dû aux décalages ainsi qu'aux ifs en eux mêmes (les branchements prennent pas mal de cycles je crois)
les if y'en a des tonnes au dessus dans la meme boucle, c'est surement les decalages mais je comprend pas car c'est une instruction du 68k le decalage...
si j'enleve presque tout le code de la boucle et que je laisse juste ces test ca rame presque autant qu'avec tout le code
Si j'enleve que ces lignes ca booste a fond
je pense qu'il faut que je fasse un btst ou quelque chose comme ca pour remplacer le if en entier (plu de decalage et de & )
