You’re right, a relative hitbox would be better. Nice find!

I’m not sure I understand exactly what you mean re: move checks. By 8 bit do you mean 8 pixels? The character sprite is 16×32 pixels, but her hitbox is much smaller. Metatiles are 16×16 pixels, but are represented in RAM as bytes. Could you elaborate more on your solution? Anything that can make collision detection cleaner is something I want to take a look at.

Wouldn’t a relative hit box be slightly better. By that I mean, storing the jump from sprite X/Y to the corner, then to the next, and so on, rather than all hit box coordinates being relative to the sprite X/Y. It would mean less fetching of the sprite location each time. And wouldn’t checks on whether the sprite was safe to move be checkable by the sprite X/Y or at least the lowest couple of bits. I’m assuming that you are using 8 bit tiles and an 8 bit wide character. Only when the sprite X/Y was outside a user defined central box would it be necessary to check for collision. Of course, if you are using a character that is n*8 bits wide it could be more complicated.

About the stairs, yes. You go up and down the stairs way too fast right now. It’s like she’s sprinting up those things :). I’ll stick a pause in there eventually. Maybe I can work on it today if I can finish up the switch/stairs thing I’m working on right now. Fading out and in is a great idea! I think I’ll do that.

I know it needs a sound effect too, but my sound engine is too basic right now. I don’t have the noise channel implemented at all yet and I think I’d need that for a “stairs” sound. Pitfalls need a sound too.

I know you are still getting the basic stuff going on right now, but are you thinking of maybe making the screen fade out when you get on stairs, make a sound effect, and fade back in? Kind of like Dragon Warrior, if you know what I mean.