Where is a good place to check for collisions?

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
tokumaru
Posts: 11757
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Where is a good place to check for collisions?

Post by tokumaru » Wed May 20, 2015 10:21 pm

thefox wrote:Why do you update the player object first? (Because its position is needed for the enemy-player collisions?)
Yes. Many objects collide with the player, and I'd rather have it consistently positioned for all collision tests. If the player took part in the object randomization, objects processed before the player would see it in one place and the ones after it in another.
tepples wrote:Perhaps because the camera follows the player.
This was true at some point, but eventually I decided to have the camera follow the previous position of the player. I made this decision because the previous position is known to be valid, while the current position could still be modified by objects pushing the player.

I have to confess I'm starting to forget some of the decisions I made regarding this aspect of my Sonic-like game. I haven't looked at the source in years, so there is a possibility I'm talking nonsense! =)

psycopathicteen
Posts: 2937
Joined: Wed May 19, 2010 6:12 pm

Re: Where is a good place to check for collisions?

Post by psycopathicteen » Wed May 20, 2015 10:28 pm

Have you ever posted a demo? I want to see Sonic on the NES.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Where is a good place to check for collisions?

Post by thefox » Thu May 21, 2015 2:40 am

tokumaru wrote:
thefox wrote:Why do you update the player object first? (Because its position is needed for the enemy-player collisions?)
Yes. Many objects collide with the player, and I'd rather have it consistently positioned for all collision tests. If the player took part in the object randomization, objects processed before the player would see it in one place and the ones after it in another.
I guess another reason for updating player before everything else could be to do any kind of calculations required by the other objects. For example, if object-object collisions are done by checking for bounding box overlap, the player's bounding box could be precalculated (no need to calculate it again for each enemy).

When it comes the time to draw the player in the object loop though, do you draw it with the previous frames coordinates? I think you'd need to save a copy of the previous frames coordinates specifically for player in that case.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Where is a good place to check for collisions?

Post by Sik » Thu May 21, 2015 7:00 am

tokumaru wrote:This was true at some point, but eventually I decided to have the camera follow the previous position of the player. I made this decision because the previous position is known to be valid, while the current position could still be modified by objects pushing the player.
You should update the camera position at the end, after all the objects have been processed (especially if there's anything else that could affect the camera position besides the player - e.g. a boss that brings attention to itself to make it easier to see what's going on).

Good cameras can end up being extremely complex anyway.

User avatar
tokumaru
Posts: 11757
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Where is a good place to check for collisions?

Post by tokumaru » Thu May 21, 2015 8:30 am

psycopathicteen wrote:Have you ever posted a demo? I want to see Sonic on the NES.
No, I never got past the stage of backgrounds made of colored boxes and dumb objects that are moved around without physics. Nothing particularly interesting to see.
thefox wrote:For example, if object-object collisions are done by checking for bounding box overlap, the player's bounding box could be precalculated (no need to calculate it again for each enemy).
Yes, that's something I considered, but never got to implement.
When it comes the time to draw the player in the object loop though, do you draw it with the previous frames coordinates? I think you'd need to save a copy of the previous frames coordinates specifically for player in that case.
I believe I did, but things are indeed fading from memory... :cry:
Sik wrote:You should update the camera position at the end, after all the objects have been processed (especially if there's anything else that could affect the camera position besides the player - e.g. a boss that brings attention to itself to make it easier to see what's going on).
Ideally, yes, but that would require a second pass over the objects in order to draw them afterwards. This is the NES, where each CPU cycle is worth gold if you're trying to code something that can compare to 16-bit games, so the goal is to iterate over the objects only once, and do the AI and the drawing in one go, and the camera position has to be final so that sprites can be drawn.

A 1 frame delay in the camera in a game running at 60Hz should be unnoticeable. I was counting on it! =)

Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Where is a good place to check for collisions?

Post by Sik » Thu May 21, 2015 10:13 am

tokumaru wrote:
psycopathicteen wrote:Have you ever posted a demo? I want to see Sonic on the NES.
No, I never got past the stage of backgrounds made of colored boxes and dumb objects that are moved around without physics. Nothing particularly interesting to see.
I still got curious about how the graphics would look like =P
tokumaru wrote:Ideally, yes, but that would require a second pass over the objects in order to draw them afterwards. This is the NES, where each CPU cycle is worth gold if you're trying to code something that can compare to 16-bit games, so the goal is to iterate over the objects only once, and do the AI and the drawing in one go, and the camera position has to be final so that sprites can be drawn.
Technically only the objects that can affect the camera are the ones that matter (usually just the player, and maybe the bosses if they affect the camera beyond locking - bosses have enough data to be worth considering making them separate from normal objects).

User avatar
tokumaru
Posts: 11757
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Where is a good place to check for collisions?

Post by tokumaru » Thu May 21, 2015 11:08 am

Sik wrote:I still got curious about how the graphics would look like =P
I shared some of it in the past, but recently I compiled a bunch of graphics from various stages of development to show someone, and since I don't see any reason to keep this stuff secret I just posted them in the graphics forum for anyone that wants to see.
tokumaru wrote:Technically only the objects that can affect the camera are the ones that matter (usually just the player, and maybe the bosses if they affect the camera beyond locking - bosses have enough data to be worth considering making them separate from normal objects).
Objects that push the player (like moving walls) would indirectly cause the camera to move too. The screen coordinates for the sprites are calculated from the coordinates of the camera, so the position of the camera has to be final before the objects are processed because they're drawn during that time too. The simplest way to to that is to lag the camera by 1 frame, something I doubt anyone will notice. The only object to receive special treatment is the player, since he's the object that's interacted with the most, but this treatment wouldn't be so special anymore if several other objects started receiving it too.

Post Reply