mardi, novembre 27, 2012

Landing bug, from the state machine

Since the introduction of 1st September release, I observed curious behaviours with Bilou landing. First, it could occur that Bilou looks "dislocated" just when landing, which would last for a few frames before he starts walking. That can be explained by the fact the OAMs the hardware uses have received new graphics, but still with the ordering (and layout) of the last frame. It "sticks" that way because the "walking" animation starts with a 'MOVE' command, which actually instructs the game engine to wait for the GOB to have accumulated sufficient amount of inertia to be able to "step" by 3 pixels to the right. This has been fixed just yesterday.

But there's another, harder to catch, subtle bug that hides in the "state machine" that controls Bilou, more precisely between "fall", "idle" and "walk" states. In those rare cases, Bilou lands in "walking" state although you're no longer pressing the DPAD in any direction. He keeps walking forward at a very slow rate (~1px/second), unless some block prevents him from doing so or you press some button on your DS.

There sure are curious things in that state machine, such as clearing the DPAD memory before entering idle state so that you force dpadController to generate an event for "getting pressed". I have the feeling that none of this remains useful now that I have "impact speed" variables that can offer a direct fall->walk transition.

It looks like the bug was in the momentum controller code, however: it would fail to decrease any speed below 8/256th of pixel per frame, and would generate no event for "reaching speed zero".


PS: the '90,000 views' bar has been hit this morning, according to Google, but I strongly doubt that it's true. Google is terribly sensitive to all those page-ranking cheaters that pretend they're referencing you just to attract your attention to their web domain.

2 commentaires:

Cyril a dit…

NQotD[1]: what are the OAMs?

1: Noob Question of the Day

Sylvain Pypebros a dit…

OAM stands for Object Attribute Memory. That's the control blocks for hardware sprites. They had a 1:1 mapping with game sprites in the "GreenZone" engine, but now that we've got game entities made of several sprites (CompoundGobs) and sprites mapped to OAM slots on-the-fly to enforce a particular depth order, I cannot hide the technical term under a generic game reviewer term anymore.