[Orion3d-dev] =?iso-8859-1?Q?Re:_=5BOrion3d-dev=5D_RE:_=5BOrion3d-dev=5D_Re:_=5BOrion3d?= =?iso-8859-1?Q?-dev=5D_Bug_release_r=E9gl=E9?=

[<nik...@al...>]

ok, que de bonnes idées :)

pour les "wait", tu boules sur tout ceux qui attendent (enfin, avec un nbr
d'itérations limités peut etre)
en attendant que les différents conflits se règlent ?

pour les plugins empilé, à priori, oui, c comme ça que je comptais coder les
différentes passes (faut juste que je rajoute
des callback pour après le rendu, et c'est une idée naturelle de les
dérouler dans le sens inverse).

ciao

Gabriel


----- Original Message -----
From: "Antoche" <an...@al...>
To: <ori...@li...>
Sent: Tuesday, December 24, 2002 2:54 PM
Subject: [Orion3d-dev] RE: [Orion3d-dev] Re: [Orion3d-dev] Bug release réglé


Je suppose que les dll de la libc de debug font un peu de "prévention",
genre quand t'alloues qq chose ça remplis la mémoire avec des trucs et ca
alloue un peu avant et après en cas de débordement (il me semble avoir lu ça
dans le MSDN), tandis qu'en release ça fait rien du tout du coup la valeur
n'est pas la même...
Je viens de corriger le même genre de problème dans les Track : j'avais
rajouté une cache de la dernière valeur calculée (et du temps associé) pour
que, quand l'anim est en pause, le track ne recalcule pas à chaque fois la
valeur. Manque de bol, j'avais oublié d'initialiser le temps de cette
dernière valeur dans un des constructeur.

Hier j'ai installé Rational Purify et j'ai joué un peu avec, c'est vachement
pratique parce que ca te dit non seulement quand tu fais des memory leaks ou
que tu écris à des endroits pas autorisés, mais ça t'informe aussi de ces
UMC ("uninitalized memory copy"). Comme ça j'ai pu corriger qq mem leaks
(par exemple dans le Shell Kernel qui delete pas les fonctions à la fin).
C'est vraiment super sympathique quand tu sais t'en servir et que ça plante
pas. Je vais m'en servir sur tous les samples pour cleaner bien le code.

Pour le système de plug-in, je pensais que ce serais pratique de les ajouter
sous forme de "pile" : l'utilisateur ajoute les plug-ins un à un. Le
renderer appelle d'abord une première fonction "StartRender" pour chaque
plug-in dans l'ordre d'ajout, puis "EndRender" dans l'ordre inverse. Comme
ça, imagine qu'on ait un plug-in "motion blur" : celui-ci doit faire des
trucs avant tout le dessin et après tout le dessin. Donc l'utilisateur
ajoute d'abord le plug-in "motion blur", puis le plug-in "hierarchy tree",
etc, et comme ça ça peut fonctionner.

Autre idée, plutôt à propos de la serialization, qui pourrait éliminer les
post-export pass reloues : quand le serializer a fini de lire un
serializable, il appelle une fonction (genre SerialInit) qui renvoit soit
"OK", soit "Fail", soit "Wait". Dans le 3e cas, le serializer rappellera
cette fonction à la fin quand il aura chargé le reste. Ainsi, si un
serializable dépend d'un autre qui n'a pas encore été loadé parce qu'il est
plus après dans le fichier, il attend que cet bidule soit chargé pour
répondre "OK". Ca résoud très simplement les dépendances entre objets. Paul
Nettle (ak Midnight, un gourou de flipcode) utilise ce système pour un de
ses projets massivement basé sur les plug-ins, et ca m'a l'air très
pratique.

Voilà, à part ça, ben joyeux noël ! :)

Antoche

-----Message d'origine-----
De : ori...@li...
[mailto:ori...@li...]De la part de Gabriel
Peyré
Envoyé : lundi 23 décembre 2002 17:11
À : ori...@li...
Objet : [Orion3d-dev] Re: [Orion3d-dev] Bug release réglé


ok cool ...
mais pourquoi ça marchait en debug ??

dés que j'ai le temps (c'est les vacances :), je clean le code d'orion3d
avec la série de plugin promis, ce qui devrait alléger le code.

si Toche tu as des idées pour améliorer les plugins (et/ou en faire pour les
bsp/q3), ne te gène pas !
et pis j'essaierais de recompiler le plugin sous max5

gabriel


----- Original Message -----
From: "Antoche" <an...@al...>
To: "Orion3D-dev" <ori...@li...>
Sent: Monday, December 23, 2002 4:23 PM
Subject: [Orion3d-dev] Bug release réglé


Il y avait un problème (parmi d'autres) lorsqu'on lançait un exe utilisant
Orion3D hors du debugger, particulièrement horripilant, qui faisait qu'en
fait on ne voyait rien de rien, la fenêtre restait désespérément noire... Je
viens enfin de localiser et d'éradiquer cette petite saloperie. Je vous la
donne en mille rien que pour le plaisir : l'attribut IsActive de OR_Viewport
n'était pas initialisé dans le constructeur, du coup le debugger le mettait
à 1 et quand on le lançait en dehors du debugger il valait 0...
Donc voilà, maintenant on voit la même chose dans tous les modes (c'est gabi
qui va être content), je met le fix sur le CVS bientôt.

Antoche




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Orion3d-dev mailing list
Ori...@li...
https://lists.sourceforge.net/lists/listinfo/orion3d-dev



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Orion3d-dev mailing list
Ori...@li...
https://lists.sourceforge.net/lists/listinfo/orion3d-dev




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Orion3d-dev mailing list
Ori...@li...
https://lists.sourceforge.net/lists/listinfo/orion3d-dev