#25 

30-01-2011 16:25:10

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 899
Corrections: 1
Site web

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


#26 

30-01-2011 16:57:58

tmyke
Administrateur
Date d'inscription: 24-03-2008
Messages: 1025

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 wink
Pour le rendu, pareil, pas de texturation, donc cela semble bien, à confirmer en situation complète .

Globalement, c'est du bon travail.


Force et sagesse...

Hors ligne


#27 

30-01-2011 17:15:22

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

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


#28 

31-01-2011 14:45:22

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

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é wink donc je passe mon tour.

je continu ma décortication de code:

Code c++ :

video::S3DVertex vtx;
    for (u32 y = 0; y < Height; ++y)
    {
        for (u32 x = 0; x < Width; ++x)
        {
            const f32 z = data->getData(x, y);
            const f32 xx = (f32)x/(f32)Width;
            const f32 yy = (f32)y/(f32)Height;

            vtx.Pos.set(x*mtc.getScale().X, Scale*z*mtc.getScale().Y, y*mtc.getScale().Z);
            vtx.Normal.set(data->getnormal(x, y, Scale));
            vtx.Color = SColor(255,32,32,32);
            vtx.TCoords.set(xx, yy);
            Mesh->Vertices[y*Width+x] = vtx;
        }
    }


wink 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 sad

Hors ligne


#29 

31-01-2011 15:18:29

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 899
Corrections: 1
Site web

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)
        {


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 smile

Hors ligne


#30 

31-01-2011 16:22:10

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

Magun a écrit:

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 wink 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 wink

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

Hors ligne


#31 

31-01-2011 17:20:03

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 899
Corrections: 1
Site web

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 wink
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 smile

Hors ligne


#32 

31-01-2011 18:52:44

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

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 wink

Hors ligne


#33 

31-01-2011 20:09:43

thesus
Membre
Date d'inscription: 11-08-2009
Messages: 19
Corrections: 1

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 big_smile )

Hors ligne


#34 

31-01-2011 20:35:36

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 899
Corrections: 1
Site web

@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 smile

Hors ligne


#35 

31-01-2011 20:54:38

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

hum non désolé Magun on s'est mal compris, je parlais bien des std::vector wink 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 wink
t'as une idée  ?

ps:merci thesus  smile

Hors ligne


#36 

31-01-2011 21:12:38

tmyke
Administrateur
Date d'inscription: 24-03-2008
Messages: 1025

essais directement video::ECF_A8R8G8B8 wink


Force et sagesse...

Hors ligne


#37 

31-01-2011 21:19:48

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 899
Corrections: 1
Site web

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 hmm

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

Hors ligne


#38 

31-01-2011 21:25:31

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

merci tmyke wink
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 wink

Hors ligne


#39 

01-02-2011 00:09:55

TUpac
Habitué
Date d'inscription: 08-09-2009
Messages: 387
Corrections: 1

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 ? big_smile


"Si vous ne partagez pas votre stabilité avec les pauvres, les pauvres partageront leur instabilité avec vous."

Hors ligne


#40 

01-02-2011 08:21:22

Gehogor
Abonné
Lieu: Paris
Date d'inscription: 02-06-2009
Messages: 130
Corrections: 7

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.


Et hop... wink

Hors ligne


#41 

01-02-2011 16:49:01

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

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 hmm
Donc je sais pas quoi vous dire, perso j'abandonne les comparatifs c'est trops nul tongue

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

Hors ligne


#42 

01-02-2011 17:19:09

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 899
Corrections: 1
Site web

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  ... wink
si tu as le courage tmyke ... !

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

Hors ligne


#43 

01-02-2011 18:20:15

tmyke
Administrateur
Date d'inscription: 24-03-2008
Messages: 1025

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 a écrit:

si tu as le courage tmyke ... !

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


Force et sagesse...

Hors ligne


#44 

01-02-2011 19:55:21

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

perso je pense qu'on rame trop là, le temps qu'on compare équitablement les 2 terrains, irrlicht 2 sera déjà sorti sad
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 wink


oui je sais jsuis impatient smile

Hors ligne


#45 

02-02-2011 02:52:22

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 899
Corrections: 1
Site web

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 wink ), 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


#46 

02-02-2011 12:23:34

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

sad

Hors ligne


#47 

02-02-2011 13:57:25

Magun
SleekThink Producer
Lieu: Punakha
Date d'inscription: 18-11-2007
Messages: 899
Corrections: 1
Site web

qui a t'il nico ? smile

Hors ligne


#48 

02-02-2011 18:24:15

tmyke
Administrateur
Date d'inscription: 24-03-2008
Messages: 1025

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  smile )

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 wink


Force et sagesse...

Hors ligne


#49 

02-02-2011 20:53:18

nico
Webmaster
Date d'inscription: 07-08-2009
Messages: 563
Corrections: 9

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

Hors ligne


Options Liens officiels Caractéristiques Statistiques Communauté
Corrections
irrlicht
irrklang
irredit
irrxml
xhtml 1.0
css 2.1
Propulsé par FluxBB
Traduit par FluxBB.fr
Analysé par
872 membres
1422 sujets
11104 messages
Dernier membre inscrit: Glider
9 invités en ligne
Aucun membre connecté
RSS Feed