LGV Il serait temps que j´évolue aussi...

Je suis d´accord au niveau des calculs trigonometriques : ce ne sont pas eux les plus gourmands : ce qui pompe de la ressource c´est d´animer tout ca

Par contre, LGV, j´ai rien compris : fillrate ? gne ?

Augmenter la resolution des sprites, cela revient a augmenter la taille du fichier, donc du telechargement, ainsi que la taille des fichiers que Flash manipulera, donc chute de performance . ..

Je pourrais rajouter quelques bandes dans mon moteur Mode7, mais la, bing pareil, chute de performance . .. en gros, je peux faire difficilement mieux que la version actuelle sans me prendre une grosse claque . ..c´est Flash apres tout : pas tip top pour du gros calcul qui tache

ok ok comme je connais pas du tout, ce que je ferais habituellement ne doit pas s´appliquer ici.
Tu travailles en pixels, ou en polygones, pour l´affichage ? ( ou en sprites..)
si tu travailles en pixels, pour afficher une surface plus grande, il faut traiter un nombre plus grand de données, donc ca coute bcp. Si par contre tu travailles en polygones, la partie " remplissage" est probablement déléguée au hardware ; en sprites, ce serait les blits qui seraient delégués. Dans ces deux derniers modes, afficher une zone plus grande ne demande pas de traiter plus d´informations, ce sont les memes données qui servent à générer l´image, mais c´est les performances matérielles qui limitent alors. Ex, pour dessiner un triangle, 3 vertices suffisent, qu´on le fasse en 160x120 ou en 1600x1200 : pas plus de données, apres c´est le fillrate du matos qui va dire si c´est rapide ou pas. Bon évidement, en disant ça, je suis plutot tourné API 3D ( on se refait pas...) ; mais comme je ne connais pas flash, je me dis que l´implementation repose p-e sur une surcouche de ce type, et que ces constats peuvent p-e s´appliquer ici aussi :-?

Quant aux ressources, c´est plutot leur nombre, ou leur poids, qui influe sur les performances ? ( mais bon, je pense comme je disais plus haut, que les points où il faudra ruder pour accelerer appairaitront d´eux meme quand ça commencera à ramer un peu)

he he : c´est du mode 7 : y a pas de polygones ! que des sprites 2D . .. c´est pas de la vrai 3D

( a moins que je n´ai pas compris ce que tu voulais dire ? !? )

vi vi, ok pour le mode 7, mais je m´interrogais sur la façon dont c´était dessiné au final en fait, surtout ; tu écris les pixels " à la main", un par un, ou tu envoies des instructions à flash pour lui dire " dessine moi ça, dessine moi ça" ( i.e. dessine moi un quad avec telle texture pour faire la maison) ?

En therie Flash est optimisé pour afficher en utilisant le hardware de la machine ( cad il ne fait pas de point par point), enfin je crois.

Franchement bravo
35fps
amd3000+ @2.4GHZ et 1024 de ram

LGV : non, Flash ne dessine rien ( a part les bandes horizontales du mode7, ou j´attache dedans des morceaux de mon " sol" ) - les objets, eux sont des gifs pre rendus de mon modele 3D tournant sur lui meme, il va juste prendre la bonne image selon le point de vue du joueur - donc, pour faire simple, je ne manipule pas des pixels, mais des images

donc en gros, si je comprends bien, on a en gros du " dessine moi telle image a telle position et telle taille" ; si c´est le cas, comme je disais plus haut travailler sur une grande image ne devrait pas generer plus de donner a traiter, et il devrait etre possible d´augmentation la taille de la fenetre sans impacter massivement sur le FPS ( c´est ici que le coup du fillrate intervient..). Si augmenter la taille de la fenetre traitee ralentit considerablement l´affichage, c´est qu´il doit y avoir qqch d´autre de plus percinieux qui intervient entre tes ordres d´affichage et le " rendu" effectif ( ou alors flash gere avec les pieds, mais je ne suis pas connaisseur :-?)

nan, foncierement, une grosse image, c´est " plus" de donnees : plus de points, plus de filesize . .. c´est pas tellement au niveau processeur que cela pose probleme, a ce niveau, c´est surtout le poids de mon fichier final qui me soucie : une image + grosse sera embeded dans mon fichier Flash, et augmentera donc son poid en consequence . ..

Ensuite, si tu regarde Doom par exemple, tu verra qu´eux aussi, a l´epoque avaient fixe une limite assez " basse" sur la resolution des bitmaps qu´ils manipulaient - je pense qu´il s´agissait, la aussi d´une balance Processor Hogging / filesize

Je ne sais pas du tout ce qu´on peut en conclure :-?
Toujours est-il que de mon point de vue, j´aurais tendance a dire que la taille a dire que la taille des ressources ne va que ralentir le download, mais sans repercussion sur le framerate. Si l´affichage est effectivement delegue au hardware, ca devrait etre le cas. Ajd on supporte facilement des textures de 512 voire 4096 sans perte de performance ( le seul point a faire attention etant de ne pas saturer la carte, sinon c´est le port AGP/PCIe qui va s´amuser...)
Si tu dis " dessine moi mon image de telle a telle position", et que c´est delegue au hard, le boulot de ton appli s´arrete la, apres ca passe dans la carte, et que tu dessines en petite ou grande taille change pas grand chose ( c´est la capacite de la carte en remplir de la surface qui limite, le fameux fillrate ; si le rendu est complexe, notamment bcp de blending, shaders, etc. le FPS chute, mais pour des primitives simples, ca reste quasi constant)
Si on bosse en pixels, la c´est autre chose, et Doom dont tu parles le montre bien : tout en software, donc chaque pixel coute, plus on en dessine, plus c´est long ( et si on suit ce que je disais plus haut, ce n´est pas forcement le cas avec les technologies actuelles, pour des choses raisonnablement simples).
Tout ca pour dire au final que j´en sais rien :D mais ce serait cool de pouvoir mettre la main sur les specs de flash, pour savoir vraiment comment ca se passe, et pouvoir en tirer parti au mieux

35fps c´est pas énorme non plus, avec un petit frustum culling il y a moyen de gagné un max de fps ( le triple peu être)

Et c´est quoi ce frustum culling?

si on sort de la map et qu´on regarde du " vide", il n´y aucun gain de FPS : les primitives, clippees ou non par le raster ne coutent " rien". faire un culling est toujours un mieux et je ne peux que le conseiller comme DS-Shadow, mais si on gagne ne serait-ce que 20% de perfs sur cette version, ce sera beau ( et ce serait tres louche, la encore le mechanisme du rendu flash serait interessant a connaitre)

Flash ne dessine qu´en vecteurs . .. il sait faire des lignes, et les remplir avec des couleurs uniformes, ca s´arrete la . ..

On ne parle vraiment pas de la meme chose : Flash n´a AUCUN support 3D : pas de shaders, pas de polygones, pas de bones ni de mesh . ..pas de possibilite de texturer une surface sans tricher ( et cela devient vite TRES lent ) . ..rien . ..nada . ..on peut tenter " d´emuler" la 3D avec les fonctions de dessin vectoriel, mais cela tue au niveau des ressources . .. Tout ce que tu peux voir en 3D en Flash n´est que de la tricherie : Flash est un pur logiciel 2D

Et y´a bien assez de fonctions comme ca

lol . .. arretez d´utiliser des concepts 3D . ..pitie ! !! je le repete : on est en 2D, mes images sont toutes en Gif ou en Jpeg et je travaille avec des modeles pre-rendus . ..

mais on l´a bien compris :D ( d´ailleurs, on n´hesite pas a faire le maximum de choses en 2D, ca coute autrement moins..) Mais seulement le rendu lui ne doit pas etre effectue par Flash directement, par un couche graphique plus bas niveau, c´est la que ca peut etre interessant ( si les " billboards" sont blitte par DirectX par ex. ce qu´on dit n´est pas completement denue de sens :D )

Oui, je comprends bien, mais moi, je n´ai aucun control la dessus : je suis " emprisonne" dans Flash, et dans ce qu´il sait, ou ne sait pas faire : par exemple, a moins de dessiner dynamiquement un masque sur mon image ( ce qui equivaudrait a pomper de la ressource pour chaque changement de point de vue ) je ne peux pas faire un affichage selectif d´une image . .. donc pas de culling

Je sais toujours pas ce que c´et moi le culling