c'est volontaire, histoire de voir les défaut, comme par exemple les normales qui ne sont pas aligner sur les bord des sous partie, se qui fait une légère déformation des lumières
après normalement tu a se qu'il faut pour compiler un sample, enfin faut dépoussiéré le main.cpp ...
bref ... quand pensser vous ? perf, rendue, etc ...

Ha ok.

Sinon, difficile de se faire une idée juste.

Pour les perf, il manque les textures, mine de rien, cela a une incidence sur le framerate. Donc a voir même si cela semble pas mal
Pour le rendu, pareil, pas de texturation, donc cela semble bien, à confirmer en situation complète .

Globalement, c'est du bon travail.

Mag, Perso je te dirai demain, il y a trop de chose à analyser pour mon petit cerveau, en tout cas bravo à tous les deux, c'est du boulot de pro !

Mouhai j'ai pas encore tout compris, j'ai du boulot sur la planche avant de pouvoir donner un avis juste sur le terrain à proprement parlé donc je passe mon tour.

je continu ma décortication de code:

j'ai pas testé mais je dirais que les calculs avec 'y' sont dupliqués 'width' fois, donc je les mettrais en dehors de la boucle 'x'

j'ai vu que tu utilise aussi des <vector>, est-ce vraiment nécessaire ? si mes souvenir sont bon, c'est super lent

oui on pourais faire

si j'ai bien comprit se dont tu parlais, cela diminurais un temp soit peut le chargement, mais sa se compte en ms.

d'une par pour se qui est de vecteur, sache que si tu veut faire un mesh tu est oblgier dans utiliser, pour les vertex et les normal par exemples
d'autre par les vector comme tu le dit sont long a alouer comme tu a pue le constater, mais pas temp que sa à utiliser, du coup ça ne change pas grand chose sur les perf de l'affichage

Magun :

oui on pourais faire

Code c++ :

    for (u32 y = 0; y < Height; ++y)
    {
        const f32 xx = (f32)x/(f32)Width;
        for (u32 x = 0; x < Width; ++x)
        {

Je sais bien que t'a compris mais ça peut t'arriver d'oublier des trucs.
je te dit ce que je voit dupliquer:
const f32 yy = (f32)y/(f32)Height;
y*mtc.getScale().Z
y*Width
Evidement le gain est infime, mais peut importe, l'important c'est de ne gaspiller aucune ressource, si possible

As-tu fait des test pour les <vector> ? car il me semble que ça rame autant en écriture qu'en lecture

non il est vrai je n'est pas fait de test, mais de toute façon, nous ne pouvons pas faire autrement, même en géometry shader on passe par des vector
après je ne ses pas si tu a fait la comparaison des deux moteur, mais se qui est sur c'est que le mien n'est pas tout à fait finie, bon j'avoue je les fait il y a 4 mois, et vue tout se que je doit faire sur mon projet, j'ai continuer sur plusieurs bug, du coup je ne me suis pas réellement repencher dessus. néanmoins je pense qu'il est intéressant et qu'il faudrait se pencher dessus.

si j'ai le temps, je vais voir pour corriger les points négatif.

ps: ah ... oui excuse j'avais pas fait attention que j'avais mis y pour le premier for, en général je commence par x ... bref oui, tu peut modifier ça, merci de signaler

ok,
là j'ai tout juste compilé ton code Magun , ce soir je fait celui de Tmyke, et après je pourrai commencer des stresstests

Pour votre histoire de <vector> ça irait pas plus vite d'utiliser des <list> (si c'est possible bien sur). Bien sur il ne faut pas avoir besoin de rechercher un élément en particulier (sinon c'est encore plus lent )

@thesus, on ne parle pas des std::vector et compagnie mais d'une structure pour stocker des vecteurs ( xyz )
discution en référence: http://irrlicht-fr.org/viewtopicaim.php?pid=9633#p9633

hum non désolé Magun on s'est mal compris, je parlais bien des std::vector lol c'est pour ça que j'ai mis les <>
Je disais donc que je trouve ça super lent, aussi bien les list que le reste, dans certain cas c'est fort utile(et propre) mais pas super rapide. non ?

Tmyke j'ai un soucis avec video::ECOLOR_FORMAT::ECF_A8R8G8B8
il me dit qu'il est pas déclaré dans le scope
t'as une idée  ?

ps:merci thesus 

essais directement video::ECF_A8R8G8B8

ben du coup je ne voie pas le rapport étant donner que je n'utilise pas de std::vector, mais les array d'irrlicht ...
et la pour le coup il ne sont pas lent

Dernière modification par Magun (31-01-2011 21:20:56)

merci tmyke
ouai je me suis trompé Magun, j'ai vu push_back ça m'a trompé, si les array d'irrlicht sont rapide alors tant mieux je le savais pas

Ou as tu entendu que les std::vector étaient lents?
On m'a toujours conseillé de les utiliser en c++ à condition de les attaquer par derrière.
On m'aurait menti à l’insu de mon plein grès ?

Bonjour, ci-dessous un lien bien pratique pour choisir quel conteneur à utiliser en c++:

http://cpp.developpez.com/faq/cpp/?page … _conteneur

Ça peut toujours servir, ...

   Bonne journée.

tmyke:
ogl->min: 225fps
dx->min:203 fps
bizarre non ?

Magun:
ogl->min 550 fps
dx->min 980 fps

evidement impossible de comparé les deux vu que le rendu n'est pas le même
Donc je sais pas quoi vous dire, perso j'abandonne les comparatifs c'est trops nul

hop je repasse mon tour ! je laisse parler les pro quel sont vos avis ?

en désactivant les shader sur le terrain de tmyke, et pour le mien en rajoutant une texture tout en enlevent un quad au rendue, on pourrais arriver a deux systeme se raprochant, on pourrais mieux différencier les perf  ...
si tu as le courage tmyke ... !

Dernière modification par Magun (01-02-2011 17:20:22)

Les différences de perf entre OGL et DX ne sont pas nouvelles et dépendent de pas mal de paramètres.
Cela ne me surprend pas, d'ailleurs chez moi pour ce qui est de mon moteur j'ai en moyenne 500 fps
sous DX et 350 avec OGL, donc l'inverse

Magun :

si tu as le courage tmyke ... !

Ce WE j'aurais peut-etre un peu de temps, mais pas avant

perso je pense qu'on rame trop là, le temps qu'on compare équitablement les 2 terrains, irrlicht 2 sera déjà sorti
Ce que je propose->On se met d'accord sur un agencement bien pensé de la classe Terrain. et ensuite libre à chacun d'apporter son lot d'amelioration.
Qui est chaud pour créer un topic sur l'organisation ? on établi des règles de codage, faut qu'on se mette d'accord sur le nom des fonctions... le nombre de classes...et ensuite on essaye d'implementer les fonctions les plus performantes


oui je sais jsuis impatient

uhm disons que c'est beaucoup plus simple a mon humble avis de partir sur des source existant, pourquoi ? deux raisons...

d'une par on a un rendue concret, et une gross partie du travail macher, et les membres particip a l'amelioration du code, donc les contributaires sont encourager ( dans le sens ou la personne proposant sont code, se retrouve avec un même code optimiser/debuguer surtout utils pour les develloper autonome/autodidacte ) et puis c'est toujours sympas de se dir, "sur se project j'ai fait t'elle partie", bref...

d'autre par l'architecture par elle même, il est par nature beaucoup plus simple de laisser une seul personne pensser au implentation nécessaire, ce qui permet d'aller "droit au but", si dans un project chaque personne s'occupe de l'implémentation et gestion de sa 'section' se n'est pas pour rien, ( edit >> en plus sa évite que chaqu'un etudit le code de l'autre ) . ( dsl mais je sèche pour un exemples ), mais sa n'ampeche en rien qu'une autre personne retravail par dessus.


en tout cas établir des spec pour coder c'est bien, le probleme secondaire c'est que je trouve personelement que la programation nécessite beaucoup d'inspiration et par conséquent on est plus liez/limiter.
dernier point un 'validateur', qui valide les modification ... par ce que optimiser c'est bien, mais encore faut-il que cela ne résulte pas d'une contre optimisation sur un matériel différent, un autre os, ou des instabiliter :]

ps: jespère que c'est compréhensible, pasque les explications moi ....

Dernière modification par Magun (02-02-2011 02:56:09)

qui a t'il nico ?

Désolé, je suis moins présent, et oui, j'ai repris le boulot, donc... (moi j'ai pas le net au travail, juste un IPhone pour lire seux trois truc de temps en temps  )

Personnellement, mon avis diverge légèrement. L'objectif de AIP est justement de se démarquer un peu
d'Irrlicht, en proposant (en essayant tout du moins) des codes plus avancés et donc forcement différent
dans certains cas.

Il est certain que dans bien des cas, à la base ce sont des codes qui seront initiés par une seule
personne, mais si ils sont structurés et ordonnés, rien n'empêche d'autre contributeurs d'apporter leur
grain de sel et d'aller donc de l'avant.

Donc je suis plutôt pour des codes plus complets et plus travaillés, surtout si cela se justifie. Et je pense
que la partie terrain est à revoir pour doter A.I.P sur ce point de quelque chose de plus évolué. Et il y a
de la place pour coder quelque chose.

Je vais créer un topic d'organisation d'ici à demain, cela permettra de mettre à plat un certain nombre
de choses, que les non pro du codage puissent aussi s'exprimer, et on verra ou cela nous mène. On aura
un code que l'on finalisera, et si un ensemble de membres sont pour alors il prendra la place du moteur
de terrain actuel

Pourriez-vous vous mettre d'accord sur le terrain qu'on va utiliser ? svp