#50 

14-02-2007 03:46:57

Copland
Modérateur
Lieu: ZarbiLand
Date d'inscription: 22-09-2006
Messages: 657
Site web

Après quelque recherche, je suis tombé sur se post sur un forum Ode :
http://ode.petrucci.ch/viewtopic.php?t=11
Vous en pensez quoi vous ?
Irrlicht aurrai éventuellement une précision différente en OpenGL, ce qui pourrait expliquer l'un et l'autre, d'autant plus que j'ai noté d'énormes différences visuelle au niveau précision avec mon Fake Glow en Directx et en Opengl, OpenGL étant nettement plus fin et propre en rendu visuel.
J'ai noté une grosse différence également entre AMD et Intel avec Ode depuis le début de cette aventure mon problème de saccade ne pourrait-il finalement pas venir d'un problème lié à ça vu qu'il n'apparait sur aucun pentium chez moi (uniquement sur mon AMD AthlonXP 2600+ et directX) ?
Ils parlent également dans leur post si j'ai bien compris du fait que DirectX pourrait changer la précision des variables à la volé ?


Config : I5 2400, ATI HD6870 1Go DDR5, 4Go DDR3.
Single Boot : Windows Seven.

Hors ligne


#51 

14-02-2007 08:00:54

benicourt
Membre
Lieu: Albi(81)
Date d'inscription: 31-01-2007
Messages: 45
Site web

Oui Kedu, pareil pour C++, mais tout dépend de ce qu'on met derrière le mot accès concurrent. Ici, il ne s'agit pas d'accès concurrent à une variable, mais à un ensemble de données (les mesh). Je me demande s'il n'est pas nécessaire d'empêcher toute modifications par ODE sur les objets durant nos propres opérations sur ces mêmes objets. L'exemple de Copland est flagrant (problème durant les rotations, etc.), cependant je ne comprends pas comment il a  résolu le problème à l'époque en n'utilisant le mutex que d'un coté. Ce que je pense, en l'occurence, c'est que son mutex est inutile utilisé ainsi. Oui, en .NET c'est pareil - C'est juste que dans le post que j'ai cru lire que la technique de protection n'avait pas été utilisée.

Par contre, j'ai du mal à croire que le problème puisse venir d'une différence au niveau d'ODE, ou de DirectX/OpenGL, ou même d'Irrlicht. Pourquoi ne pas tester sans Thread pour en avoir le coeur net ?


"Par ce qu'il est dans la nature même de l'homme, d'aller à l'encontre de la nature" (Robert C.W. Ettinger)

Hors ligne


#52 

14-02-2007 13:43:31

Copland
Modérateur
Lieu: ZarbiLand
Date d'inscription: 22-09-2006
Messages: 657
Site web

Sans thread le problème semble être le même donc ça me laisse croire qu'il y a un léger petit conflit Ode/Irrlicht.Je vais essayer de programmer un essai encore plus simple avec juste un cube, une force et la camera qui suit pour voir si on retrouve se genre de délire, je vous tiendrai au courant.


Config : I5 2400, ATI HD6870 1Go DDR5, 4Go DDR3.
Single Boot : Windows Seven.

Hors ligne


#53 

14-02-2007 16:59:45

Jerry Kan
Habitué
Date d'inscription: 21-11-2006
Messages: 265

kedu :

Je pense que c'est un faux problème ; seuls les accès concurrents en écriture sont problématiques. (pour .net en tout cas, je ne maitrise pas c++)


quelque soit le probleme le langage et le systeme, les acces concurrent en lecture ne sont pas un probleme,  ou alors c'est que la lecture implique une écriture

ce qui fait souvent aboutir les systemes vers le truc des "lecteurs - rédacteurs" pendant une phase on ne fait que des lecture sans organisations, et pendant une autre phase on ne fait que des ecritures en exclusion mutuelle

Dernière modification par Jerry Kan (14-02-2007 17:00:10)

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
882 membres
1429 sujets
11119 messages
Dernier membre inscrit: LiseBuisson96
14 invités en ligne
Aucun membre connecté
RSS Feed