Where is a good place to check for collisions?

[tokumaru]

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.

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]

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

[thefox]

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.

[Sik]

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.

[tokumaru]

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.

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...

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]

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

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).

[tokumaru]

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.

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.