So I finally started a new SVN branch with the collision engine modification that I sketched in the train. It’s not going to be testable anytime soon, I’m afraid. The current collision engine was already abusing some “setContext(…)” calls to set static variables into GobExpression so that you can e.g. shoot things despites the eval() has no such thing in its argument. With the new “attach” and “align” features I want to develop, that becomes a huge mess of things to capture at various places in the GOB -> GOB -> area -> state -> expression call chain that happens at every collision. I bet the best move will be to extract all this context (including some of the things that are currently plain arguments) into a GobCollision structure which would have temporary lifetime (i.e. allocated on the stack) that would be passed around …
Well, that’d be better unless the compiler is able to keep all the arguments in registers otherwise đ
Je dirais bien “assez causĂ©, implĂ©mentons ces fameuses nouvelles collisions“. Sauf qu’en fait non. Les petites modif’ faites par-ci par-lĂ dans le Boutdlard Express ne compilent pas, et si je fais ce qu’il faut pour qu’elles compilent, ça va ĂȘtre une vĂ©ritable pagaille dans le code. Genre “la famille araignĂ©e en vacances dans une boites de spaghetti gĂ©ante”, voyez? J’ai une petite idĂ©e pour rationaliser tout ça sans perdre en souplesse ni (trop?) en performance. Je vous en dis plus aprĂšs avoir fait le test.
Bouli's Homebrew Blog 
one GameObject::align(ALIGN_OP, GameObject &other) additional method should be enough to capture all the attach / position alteration that cannot be done in GobExpression alone (because it doesn't limit to manipulating the data[] array, which is what GobExpression can do :P)
LikeLike
one GameObject::align(ALIGN_OP, GameObject &other) additional method should be enough to capture all the attach / position alteration that cannot be done in GobExpression alone (because it doesn't limit to manipulating the data[] array, which is what GobExpression can do :P)
LikeLike
I'll use a “nested” structures approach: when a passive Gob process its expressions, collision[0] holds information related to the passive gob and collision[1] related to the active gob. That way, we can still handle “regular” expressions (non-collision) transparently (hopefully).
LikeLike
I'll use a \”nested\” structures approach: when a passive Gob process its expressions, collision[0] holds information related to the passive gob and collision[1] related to the active gob. That way, we can still handle \”regular\” expressions (non-collision) transparently (hopefully).
LikeLike