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.
- Bilou behaviour script using one-letter state hinting (e.g. statW% for walking, statI% for idle)
- controllers.cxx, saving impact speed
- GameObject.cpp moving GOB by (stepx, stepy) before investigating state transitions
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:
Post a Comment