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 ...
Hors ligne
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.
Hors ligne
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 !
Hors ligne
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
Hors ligne
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
Hors ligne
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
Hors ligne
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
Hors ligne
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
Hors ligne
@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
Hors ligne
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
Hors ligne
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)
Hors ligne
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
Hors ligne
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 ?
Hors ligne
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.
Hors ligne
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 ?
Hors ligne
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)
Hors ligne
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
Hors ligne
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
Hors ligne
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)
Hors ligne
qui a t'il nico ?
Hors ligne
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
Hors ligne
Pourriez-vous vous mettre d'accord sur le terrain qu'on va utiliser ? svp
Hors ligne
Options | Liens officiels | Caractéristiques | Statistiques | Communauté |
---|---|---|---|---|
Corrections |
![]() ![]() ![]() ![]() |
xhtml 1.0 css 2.1 Propulsé par FluxBB Traduit par FluxBB.fr |
882 membres 1429 sujets 11119 messages |
Dernier membre inscrit: LiseBuisson96 18 invités en ligne Aucun membre connecté RSS Feed |