F-zero - Page 7

Je suis en 128 mais je pense descendre en 64 pour pouvoir faire rentrer les matrices prérotationnées dans les calculatrices de base (sinon il y aurait 512ko de bouffés par les fichiers de précalcul alors que là j'aurais "seulement" 256ko)

heu "seulement" 256ko pour des tables précalculés c'est toujours beaucoup trop a mon gout.

D'où les ""
Chacun pourra choisir s'il veut la version avec precalcul ou pas et donc avoir le double de resolution ou pas
Bon apparament, je peux calculer seulement 1/8 de tour pour obtenir le tour complet en swappant x et y et en changeant des signes.
Donc je reste en 128 directions possibles et ca fera 256ko de precalculs

tu pourait pas gagner plus en réduisant a 64?
Ca me semble suffisant non?

64 directions donneraient 128ko de precalcul
mais hier Kevin Kofler m'a prouvé qu'avec une précision de -16 à +16 pour les sin et cos, 128 directions c'était bien et pas 64 (erreur trop grande)

Precalculs -> poubelle
Je gagne pas assez de fps...

Genre en précalculant quoi au lieu de quoi ?

je precalculais les rotations des coordonnées de la map correspondant aux pixels sur l'écran sur 1/8 de tour au lieu de le faire pour chaque pixel en temps réel.
Je gagne seulement 4fps (c'etait 11fps avant) alors que j'augmente la taille de jeu de 256ko, le rapport poids vitesse sux trop pour que ca reste (j'esperais gagner 10fps)

Au moins, tu sais que les calculs de rotation sont bien optimisés^^

[00:33] <LionelA> bref ca sert a rien les précalculs dans ce cas
[00:34] <LionelA> (j'avais trop bien optimisé avant)

y'a toujours un compromis à trouver entre taille et vitesse mais là ... 256ko... au moins c'estvite vu

moi je voudrai juste savoir quan d la beta 2 sortira.

je sais pas si il y en aura une, peut etre que je sortirai la version finale directe, dans quelques mois environ (parce que j'aurais plein de temps libre (stage))

pas grave mais j ai telement ate d'y jouer depuis que j'ais vu les derniers screens.

J'ai remonté rapidement le topic, et j'avoue que je trouve ta consommation RAM très élevée, et je pense qu'il y a moyen d'optimiser tout ça
Je viens d'essayer pour voir si un moteur en tiles 1 bit était faisable. Le résultat n'est pas si désastreux (testé sur VTI 2.5, mode7 fullscreen de précision moyenne, niveaux de gris, résolution 80x50 étiré en 160x100):
Mode 2 octets par pixel: 90 points (4.5 fps)
Mode 2 bits par pixel: 84 points (4.2 fps)
A mon avis, la différence est suffisamment minime comparée au gain de place occasionné, donc perso je prendrais le mode 2 bits sans hésiter.

Heu, les tiles décompressés ne sont plus dans la ram maintenant (enfin depuis pas mal de temps déjà) donc c'est pas si grave et puis je ne suis pas sur de gagner aussi peu sur mon moteur...
A mon avis Pollux n'a pas utilisé le même genre d'otpimisation pour rien

Bon c'est vrai que tu dois avoir d'autres optimisations qui foireront peut-être en mode 2 bits. Dans mon cas, ça ne change pas énormément car le framerate est déjà assez bas (sur vraie TI 6 fps en 2 octets par tile, 5.5 en mode 2 bits).
Toi quand tu dis 11 fps, c'est en quel mode (résolution, étirement, gris, etc.)?

Je suis a 11fps sur VTI en 80x25 etiré 2x dans les 2 sens -> 160x50, et bien sur en 4ndg.
Le probleme si j'utilise 1 bit par pixel, il faut calculer en plus un offset sur le l'octet et faire une operation de plus pour ne recuperer que le pixel qu'il faut

Le seul changement est donc que tu supprimes un calcul d'offset (offset+pos_x&15) et tu le remplaces par un calcul de masque (valeur&masque[pos_x&15]) dans ton cas aussi?
Sinon vraiment impressionnant la vitesse

heu je n'ai plus de calcul d'offset du tout donc forcement ca va bien plus vite
Pour la vitesse merci mais si je compte bien ton truc n'est pas loin du mien 80x50 -> 4.5fps, et moi 80x25 -> 11fps (enfin bon si je me met en mode petites maps j'obtient beaucoup plus de fps et avec 8 bits par pixels, et si je disable les rotations je dois atteindre les 40fps (mais c'est pas du tout interessant si on tourne pas sur des map minuscules))

Si t'atteint 11 fps sur vti, c que tu dois pas être trés loin du double sur vrai TI, non ??

C'est tellement varaible, on ne peut pas vraiment généraliser... et à la fois ça me semblerait beaucoup

ahh comment ca serait bon, mais non, VTI emule vraiment comme une HW1 dans ce cas, et je n'ai que des HW2 donc je suis à 12~13fps sur vraie

heu je n'ai plus de calcul d'offset du tout donc forcement ca va bien plus vite

Heu mais tu dois bien retrouver la case dans ta map et calculer la tile qui correspond non? C'est de cet offset que je parlais. (heu à moins que tu n'aies pas ça non plus?)
Sinon tu entends quoi par "petites maps"? Quelle différence de taille? Perso je vois pas ce que ça change du point de vue du code en fait, si ce n'est que tu peux gagner un peu si tes maps ont une taille multiple de deux.
Et désactiver la rotation? Désolé, je comprends pas là...

ok, je vais (essayer d') etre précis
j'ai deux shorts : coordx et coordy qui sont les coordonnées du point sur la map afficher (calculés pour chaque point de l'ecran) si je supprime la rotation je ne fais plus de multiplication par des cos etc.. donc je gagne a fond. sur des petites maps j'ai ce calcul :
bytemap = coordx+coordy*dimx;
offsetmap = 1 << (bytemap & 0x7);
bytemap >>= 3;
sur des moyennes maps j'ai ca :
offsetmap = 1 << (coordx & 0x7);
bytemap = ((long)coordx+(long)coordy*(long)dimx) >> 3;
et sur les tres grandes map (ca ne marche plus tout a fait pareil car dans les 2 precedentes l'image de la carte est calculée entierement dans un gros bitmap et là c'est une map de pointeurs) :
mapoffset = maptiles[((coordy >> TILES_SHIFT) << (10-TILES_SHIFT)) + (coordx >> TILES_SHIFT)] + ((coordy & (TILES_SIZE - 1)) << TILES_SHIFT) + (coordx & (TILES_SIZE - 1)); \

Dans le cas des grandes map evidemment j'ai un offset mais juste pour savoir quel est l'octet correspondant au pixel a afficher (en fait c'est peut etre ce que t'avais dit )

Et j'ai aussi une option pour les grandes maps qui est de forcer la taille a 1024 tiles d'ou le 10 dans la formule mais sinon en petites maps la dimension dimx peut ne pas etre une puissance de 2 ( .. * dimx)

Ah je vois, ok (je n'avais pas soulevé ce problème en fait). Perso j'utilise une méthode un peu différente: while(ye<49) {      X=idX[ye]+xe*dX[ye];      Z=idZ[ye]-xe*dZ[ye];      i=((X)>>(VIRGULE_-TEXTURE_));      j=((Z)>>(VIRGULE_-TEXTURE_));      offset=(carte[(((j>>4)&31)<<5) | ((i>>4)&31)]) | (j&15);      if (textureC[offset]&mask[i&15])          {           *ptr|=masque;           *(ptr+30)|=masque;      }      if (textureF[offset]&mask[i&15])          {           *ptr2|=masque;           *(ptr2+30)|=masque;      }      ptr+=60;      ptr2+=60;      ye++; }
Comme X et Y sont de type long, je ne devrais pas avoir trop de problème non? (la map est clippée sur 32x32 pour le moment, ce qui pourrait être supprimé). Mais je suis vraiment étonné par ta vitesse. La différence est très grande avec moi, pourtant il me semble difficile de réduire encore les opérations une fois arrivé à ce point non? Quelqu'un aurait-il des conseils?

Les seuls tests fiables sont ceux faits sur vraie calculatrice. Ceux faits sur VTI (et plus généralement, émulateur) n'ont AUCUNE signification.

juste pour dire que j'ai remplacé un strncpy (qui bugge dans PedroM) par un memcpy (dans mon cas c'est equivalent) et maintenant F-Zero marche parfaitement sous PedroM

Faut pas dire "juste un petit truc"; c'est une nouvelle importante ça!

Et alors une beta? une release??