de la 3d pa belle - Page 1

snif en plus c lent à crever
et pya y glande plus rien
juste pr dire gros branleur ke g fé le compteur de fps

les chiffres:
pour le duck 12-15 fps en rempli, 5-7 fps en texturé et 10-13 fps en wire...
vala... ah ué sinon, vu qu'on attend la synchro de lécran, ça peut jamais dépasser 59 fps... (apparemment rafraichissement de 60hz...)
ha ué o fait, vba chie tous les pixels... il affiche pas pixel par pixel, il fé une infame bouillie (cf le chiffre des fps, et ça vient pas des sprites...)

just un chti truc, me sui éclaté ac les textures

vive le ""
"" powaaaaaaaa

et pui PpHd av raison... si je vire la boucle d'écriture de la texture, ça passe de 13-15 à 59-60 fps (au dessus en fait, puisque le moteur attend la vsync et que l'écran se rafraichit à 60hz...)

enfin bon fé chier c kan même pas les 3000 polys mappés/sec de l'otre la http://www.raylight.it/bluerosesdoc.htm

qqun an une idée de koi améliorer??

vala la boucle en question:

for(;dsts<gni;)
{
  *(dsts++)=*(dstt+(txtm2>>10)+(((tytm2)>>10)<<4));
  txtm2+=txtm3;
  tytm2+=tytm3;
}

any idea?
(v dormir chui ko)

heu.. je sais pas mais vite fait je dirais:
(((tytm2)>>10)<<4));
((tytm2)>>6)&(2^(la_taille_en_bit_de_ton_type)-65);


enfin je sais pas, au juste que veux tu faire?

moa j'aime bien la texture

Agnar>

Timad>hum, g pas bien compris ton truc, ms la je vien de coder comme un porc en asm x86 pendant six heures d'affilée, et la a presque 3h du mat g un pe la tete ds le q dc je regarderai ça demain voir si je capte mieux...
sinon... bah c simple... pour que la texture soit potable, j'utilise la virgule fixe avec <<10

la je redécale pour obtenir les bonnes coords...
c tt
par contre (tytm2>>10)<<4 ne PEUT PAS s'optimiser en tytm2>>6 !!
il doit d'abord y avoir l'arrondi du >>10 pour ensuite multiplier par la largeur en pixels de la texture... dc non :/
ah et o fait, depuis g rajouté un truc...
on pouvait déjà faire une sélection de la zone a mapper sur le poly dans la texture, maintenant ça supporte le tiling ms c un pe + lent

*(dsts)=*(dstt+((txtm2>>10)&15)+((((tytm2)>>10)&15)<<4));

bon, v o dodo...

tien o fait ça donne ça maintenant avec le tiling:

o fait g essayé le fps réel sans la boucle d'affichage: 75 fps...

c vachement loin des 3000 polys texturés/sec de leur truc... même le moteur ki tourne a vide sans rasterizer atteint pas cette vitesse...

c'est peut etre programmé en asm..

certainement... ms c kan mêm louche ke ça fasse gagner autant...
en plus la je compile avec l'option -O3 dc optimisation maxi de gcc... finalement le c c'est pas si bien que ça pt de vue vitesse... (sauf pour tester les algos )
bon ben me reste plus qu'a apprendre l'asm arm...

Attends 3000 poly/s à 60 fps ca fait k 50 polygones à l'ecran

T pas tres loin d'eux

-

Aghnar>pff salop je temmerde moi ça fé 6 polys a 11-12 fps pas 50 a 60 fps
Orion>ué ms bon je doute que ça influence bcp... v le faire en asm arm et pi c tt...

-

mué bof...
ah sinon g trouvé comment virer le décalage par 10 ms bon y fo passer en asm...
o lieu de décaler de 10, décaler de 16 sur un long et au moment d'ajouter le bordel, faire un swap sur le long, ajouter l'incrément, et re swapper après... ça évite le décalage et la sauvegarde des regs... bon v dabor le faire sur ti en asm, apres on verra...

puti de kilio!! ces enfoirés m'ont viré mon compte!!!!

a non c bon... tain ça foire kilio en ce moment...

-

oh si y sert y a des pages, ms tu les vois pas si t'as pas les url

moi je connais des urls

Je dirais meme mieux , j'ai les pass moa

héhé

Au fait, l'árm n'a PAS d'instruction de divisions.
Pis Gcc doit compiler en mode THUMB, donc plus lent...