derekfountain
commented
6 years ago Nothing obvious pops out of the state save, other than those +2 y-deltas in the jump part of the trace. Thinking about it, I think that might be the problem.
When he starts jumping the y-delta is -2. So imagine, he jumps, the code draws the sprite and then goes round and reenters the game loop. It enters act_on_collision() which runs_test_direction_blocked(). His current y-pos is one pixel underneath a block. The right-rising (or left-rising) code subtracts one from the y-pos and uses it to check the attribute directly above his head. All clear so he's allowed to move.
The next action is adjust_for_jump(), and as he's near the start the y-delta is going to be -2 (rising). His y position is decremented by 2 and he's redrawn, which moves him into the cell above him. That's where the colour clash comes in.
In short, I'm checking he can move up one pixel, then actually moving him 2. Right on the cell boundary that will cause a colour clash.
There's an occasional colour clash bug. I don't see it often and can't reproduce it at will, but it happens.
It happened just now, so I grabbed a state save. The player was on level 0, around step 3. He jumped left to right, hit the next step face first and bounced back. At the bounce back point the step he was trying to land on flickered white.
colour_clash_issue.tar.gz