vicious: I'm a terrible teacher, but I still spent a lot of time on
this topic, so I'll link it. It shows a lot of ways it can go wrong, and why the logic is the way it is with some simple diagrams. If you can deal with words-words-words, my harsh tone, and a few pages of problems that deal with a specific program rather than a general guide, it may be useful.
As well, you can find a few super fast ways to do it
here.
There is stuff that's not collision detection there too,(which is totally worth reading too even if you don't understand it all) since it's not the focus of that topic. But you can see a simple 6502 bounding box routine get simplified and optimized in a way you might be able to understand.
That said, I like specific questions. If you end up getting stuck with collision, I will absolutely try to help in my own bumbling way if you post some code or some specific points of a guide you find that you do not understand.
tepples wrote:
I see your sarcasm, but bounding box collision often does not work in games designed to meet prevailing production values for commercial PC games.
But this doesn't matter at all because this topic is about NES, and because there are still easy to find guides all around the internet about collision logic that would work on NES. It's not as if all the guides written years ago have suddenly disappeared because 3D/crazy processing power is prevalent now. I guess it's true it's not
always the same, but a list of exceptions that don't have much to do with the target platform doesn't need to be given to someone who doesn't need it. It's like finding fault in someone saying random number generator instead of psuedo random, because there's no such thing as a random number generator.
Bounding box collision is still useful to teach, and people still write guides about it because it is simple to understand. Also, as you've pointed it, it's useful to try before you even start with more advanced collision, since it will still reject VERY impossible collisions before wasting CPU time doing the more extreme checks for each set of objects. I'd would think a guide that doesn't teach this isn't really useful, because it's skipping a pretty much "free" optimization that can get extreme results depending on the number of objects. And PC games with processing power to spare LOVE lots of objects.
Quote:
Players won't stand for what they consider crappy hitboxes, and they'll one-star the game on all the review sites if the instant replay of the moments before a character's death (sometimes called a "killcam") shows a bogus kill.
True, but this topic is about NES. I have never seen such a feature in any classic game I've played. Except Cattrap (Game Boy), but that game has tile by tile movement anyway. Even if there are old games that do this, or if vicious wanted to do this, it's certainly much harder to program than collision. He'd have to already have a great deal of 6502 knowledge before such a feature would reveal "errors" in his collision detection. And by then I'd bet he'd be able to fix it.