# Unity Fundamentally, how does collision work? How did it work on the NES?

This topic is 1023 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Fundamentally, how does collision work?  How does one keep an object from entering into a wall?

Right now I am revising my game to use a custom physics/collision model, rather than the one provided by the engine.  This is because I am trying to more-closely emulate the way a game controlled and felt on old systems such as the NES, and modern physics are providing too much realism.

My first logical thought is that I would move an object according to the velocity it has been given, (which I am doing manually with my own code,) and then check to see if it is colliding with anything where it is at.  If it finds anything, it then instead moves its position to be above the object it is hitting.  (Or ideally to the side; right now I have only built it for the downward motion of gravity.)  Since it checks and adjusts the position in the same frame, the object never appears to be in the wall, where its position technically was.

What I programmed is indeed functional, but it feels fundamentally flawed.  It feels like a duct-tape solution.  I did not actually stop the object from moving through the floor, I just teleported it back above the floor.

So I wonder, how do most games fundamentally handle collision?  Is there a better way to do this?  How was this handled in NES games?

Also, another clue I have seen in NES games is how they handle certain situations.  In Castlevania, if you walk up some stairs and there is a block at head-level at the top, when you reach the top you will be inside that block.  If there is empty space to the side, you can walk to that empty space.  If you try to walk into the block, you are stopped.  But with the code I devised, if you walk into the block, you will be instantly pushed out the side.  So that's not how that game works.
If I revised my code to simply halt motion when it detects a wall, then it would be possible to embed yourself in a wall by walking into it.

So how is the game handling its collision if you can get stuck like that when you legitimately appear in a wall?

...Some additional information about my game specifically, in case it comes up.

I somewhat understand that NES games checked collision with the world by checking what point on the map they are in, and they read what kind of collision there is in that square.  However, I am building my game in Unity, and since there is no pre-existing map system that works like that, I am using the colliders that come with the engine.  I use Physics2D.OverlapPoint, along with a layer mask, to see if there is a collider at that point.  I directly set the object's location by feeding the transform a location.  Unity does not seem to have a problem with colliders overlapping if I set their position this way, so if every object in the game is using this code, I expect to have no problems with just giving every object a collider that is used for collision testing.  Plus, to properly emulate an NES game, I want my objects to move in whole-pixel increments, and thus setting positions directly lets me make sure all objects move in whole numbers; nothing ever has a location with a decimal point.

##### Share on other sites

I somewhat understand that NES games checked collision with the world by checking what point on the map they are in, and they read what kind of collision there is in that square.

Not a programmer. Produced NES games but didn't program them. But I think it's safe to say that it worked however you programmed it to work. The console didn't have native collision-checking built in. You define objects and their coordinates and offsets, then you check for collisions manually.

##### Share on other sites
There are two approaches to collision.

1. When you move the player, you check to see if the player volume would hit any object and move them to the point of contact then slide along the wall.

2. Move the player then after they moved see if they are overlapping any object. This seems to be the approach you are taking.

Each approach has their advantages and disadvantages. #2 is usually simpler to implement and works well with many dynamic objects. However, fast moving objects can pass through walls or other objects. #1 will keep objects from passing through wall, but sweeping volumes can be tricky to implement

However, you could probably get unity to work how you want without having to resort to making your own collision detection. First of all, use a character controller to move your player around. Character controllers lets you specify how much you want the player to move and it will handle collision for you.
https://unity3d.com/learn/tutorials/modules/beginner/2d/2d-controllers

##### Share on other sites
Don't know about NES, but Commodore 64 have had pixel exact collision detection in hardware for sprites.
Ooops - revealed my age?

You can emulate this efficiently with bit shifts and masking (something people that did not own a C64 tend to forget, so i mention it).

To resolve collisions, for that kind of games it may work best to check if it is allowed or forbidden to enter a target position and react with any logics you need.
For modern physics engines that would pretty much impossible - penetration can't be avaided.

I want my objects to move in whole-pixel increments, and thus setting positions directly lets me make sure all objects move in whole numbers; nothing ever has a location with a decimal point.

That's ok for things like screen position and surely also for static colliders, but for physics like super mario you need at least fixed point numbers.

##### Share on other sites

IIRC the idea was to take a float, typecast to int and index into a collision array. The player could be simulated with a few of these points, and whenever a collision was detected the player center (also a float) could be truncated to snap back to the center of the tile.

I'm not sure if actual floats were used on the NES, but this is the concept for some of those older platformers.

##### Share on other sites

As for retro systems, either they had a built in per pixel collision (which was not used by far for all games) or, more commonly, used manually calculated rect collision.

##### Share on other sites

Combine the parts from Happycoder and Endurion, and you get the full algo:

for slow objects, move then check and unmove if collided.

for fast objects, use stepped movement (sweep). same basic idea as slow, but you do many small moves to ensure you don't move completely through something and out the other side in a single move.

checks are done first with bounding boxes (runs fast). if the bounding box detects a possible collision, a slower pixel perfect collision check is done to determine if a collision actually occurred or not.

i didn't look, but this is probably the algo in the link posted by SeanMiddleditch.  it was a pretty industry standard way of doing things back then, when 2d side scrollers and pixel perfect collisions were all the rage.

Edited by Norman Barrows

1. 1
2. 2
Rutin
21
3. 3
A4L
15
4. 4
5. 5

• 13
• 26
• 10
• 11
• 9
• ### Forum Statistics

• Total Topics
633736
• Total Posts
3013603
×