Tuesday, May 04, 2010

statW20->statI4 on fail

Après relecture du code "la tête froide" (comprenez, en prenant un Ice Tea sur la terrasse du Fagotin de ma fée entre la grèle et la panade pour *deline), il s'avère qu'aucun état "on pousse" n'est nécessaire pour règler les problèmes de collisions. Une meilleure sémantique pour la décision "FAIL" des contrôleurs a suffi, et je devrais pouvoir encore simplifier un peu la sauce. Cf.

I managed to find some time to study back my engine code this week-end, and it turned out that no "push" state was actually required to solve stuck-on-corner issues I observed last week. Quite good news, somehow: that means I won't need extra states when it'll come to do climb/walk transitions.

Btw, I applied to Bilou the same kind of "reuse impact speed for bouncing" than I previously used for little stars... It's pretty much working, but it is tedious to maintain the state of variable: when hitting a wall first, and then the ground, we should still bounce with the floor-hitting vertical speed (rather than wall-hitting speed).

It isn't obvious to implement at the moment, requiring to manually reset the "impact speed" in every transition that enters "Fall*" state. I'd prefer to have "impact_y:=0" defined as a "state initialisation action" ([todo] a part of the UmL state machine model I'm still missing). But first, I'll have to check whether removing the extra "landing" delay will affect it or not.

No comments: