The Slope Bug (maybe?)

That bug has been haunting me for a while. Since I introduced slopes, actually. Even in Apple Assault, it may happen that you remain "stuck" at the bottom edge of a slope, no matter how hard you press the DPAD. Jumping is your only way out.

As I was trying to figure out how to allow Bilou Compound GOBs to climb up and down the ruler, I've found something suspicious that would be worth some more investigations:

• the "Walking" controller do not directly affect GOB's position. Instead, it updates cdata[STEPX] and cdata[STEPY] to indicate "how far away you should move";
• when we have a "selfmove" animation for the state, these STEP* remains accumulated until we have a value higher than the one required by the animation (reading->_.mspr.dx, for instance)
• climbing up slopes is allowed by realising that the animation does not provide a vertical move itself, but tolerates any vertical move you'd want to use. Some bits of .mspr.id control that.

Now, suppose your walker decides that you should move by -3,+3 pixels to follow a slope, but that your animation is only ready for moving by 2 pixels, you'll end up at -2,+3 and not at -2,+2 as you should. I haven't found out (yet) whether this is the real cause, and how that could lead to move Bilou into a wall (for instance), but it sure doesn't smell good.

fixed!