Mapper choice and collision

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
User avatar
za909
Posts: 249
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Mapper choice and collision

Post by za909 »

So I'm back and every now and then when I have some free time I'd like to exercise my brain in a productive way and do some stuff with the NES! Preferably a game project. And no matter what, there are two things that scare me when it comes to planning development.
1. Which are the best and most common mappers to use? I'd probably go for one of the easiest to reproduce/find mappers in order to make the buliding of a cart easier, but not something that remains unused. So naturally I wouldn't want to waste a good MMC5 on a small game or something.
So hopefully the answers won't be more advanced stuff than the MMC3. I'd either pick that, or for even more simplicity, UNROM with CHR RAM or MMC1.

2. If I want a game that revolves around more than images and text, I have to have collision detection, but how exactly do you go about that? I understand having a map of the current screen in RAM (I'd have a single screen for the playfield and fade transitions in-between, drawing the next room while it's dark and then fading in for simplicity. The other nametable would be the pause menu with items and whatever which is scrolled to. I want a Zelda-like overhead view.) but that's about it. Also, does it help to keep track of which 16x16 block the player is in to make the collision check easier?

Thanks for everything!
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mapper choice and collision

Post by tepples »

za909 wrote:So I'm back and every now and then when I have some free time I'd like to exercise my brain in a productive way and do some stuff with the NES! Preferably a game project. And no matter what, there are two things that scare me when it comes to planning development.
1. Which are the best and most common mappers to use?
For your first game, I'd recommend NROM because it's simplest.
Also, does it help to keep track of which 16x16 block the player is in to make the collision check easier?
You can calculate that at any time from the player's current (x, y) position by shifting the X and Y coordinates four bits to the right.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mapper choice and collision

Post by tokumaru »

za909 wrote:Which are the best and most common mappers to use?
Don't design the game around the mapper. Think about what features your game will need and then we can discuss mappers. Most beginners just go with NROM (i.e. no mapper at all), to avoid unnecessary complexity on their first projects.
I have to have collision detection, but how exactly do you go about that?
Collision detection is all about moving the objects, checking if they went into something solid, and pushing them back if they did. It gets a little more complicated if you have slopes, but working exclusively with blocks is almost straightforward.

Collisions are indeed a big aspect of action games, but don't forget about physics, AI, and other concepts that aren't exactly trivial either.
Also, does it help to keep track of which 16x16 block the player is in to make the collision check easier?
I don't think so. This will change so frequently that you can just sample the blocks around the objects every frame. Also, objects often make contact with multiple blocks at a time depending on their position.

Here's a quick rundown of how collision could work:

1- Move the object horizontally (by the amount of pixels calculated in your physics code);
2- Get the coordinates of object's top right and bottom right (displacement to the right) or top left and bottom left (displacement to the left) corners;
3- Convert the coordinates from pixel space to level map space (i.e. divide by 16 if the blocks are 16x16 pixels);
4- Check the solidity of all blocks from the top coordinate to the bottom coordinate;
5- If any of them are solid, push the object back by the amount of pixels it's into the wall (need to look at the pixel coordinate again, to see how much past the left or right edges of the block it is);
6- Do the same for vertical motion, always compensating for the direction of the movement (top vs. bottom);
Post Reply