If you ever get bored you can stop by and say hi over at our IRC chat room . I go by the nick Red_Mist on the server http://sorcery.net/ over at #pixelation

Keep up the good work :>

-Red_Mist-

Looking around Tummai games, I’m pretty stoked about what can be done with a compiler, an
NES emulator and some serious time to kill. Right now, I’m really trying to find a good starting place to learn the 6502 language – any suggestions?
(A bit of background: I just got my degree in Electrical Engineering, and although I’m not a hardware guy, I learned 8051 assembly a few years ago. My little brother, an animation student, and some of his friends are hoping to make an NES game, and I’m trying to help out with the difficult part : )

Thanks-

:off topic:
@tummai: you have PM at ROMHacking.net. ^_^

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.

I should contact Disch and see if he’ll let me host a copy of his document here.

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.