Comme le gestionnaire d'évènement est plus important que les réseaux bayésiens, je vais interrompre les développement de ces derniers pour me concentrer sur la mise au point d'une table d'interception des évènements.
Toutefois, je vais finir la partie déjà commencée des
BNT, c'est à dire la partie mathématique : gestion des ensembles mathématiques.
A ce propos, j'ai déjà eu plein de problèmes qui m'ont ralentis, des problèmes liés à l'optimisation des fonctions inlines de GCC ou, tout au moins de mingw ( car je n'ai que ca en ce moment).
En effet, certaines fonctions sont, pour des raisons d'optimisation de vitesses, de simples fonctions mathématiques/logiques très peu lisibles :
orxINLINE orxBOOL orxIntervalFloat_IsLess(orxINTERVAL_FLOAT _stInter1, orxINTERVAL_FLOAT _stInter2)
{
return (_stInter1.fMax<_stInter2.fMin) ||
((_stInter1.fMax==_stInter2.fMin) &&
(((_stInter1.u32Flags&orxINTERVALFLOAT_MAX_INCLUDED)|(_stInter2.u32Flags&orxINTERVALFLOAT_MIN_INCLUDED))!=orxINTERVALFLOAT_ALL_INCLUDED));
}
C'est très efficace mais le problème est que gcc doit mal implémenter la gestion de la cache car sur certains appels, si les calculs via ces fonctions sont encahinés, leurs résultats sont faux ou partiels, alors que si les calculs sont entrecoupés de fonctions (non-inline) d'affichage (par exemple, en tout cas qui ne modifient pas le calcul), les calculs sont
magiquement
correct.
La pensée du jour sera donc :
Toujours vérifier les appels inlines, tu feras !
Commentaires récents