Game loop order

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
nyanberrycake
Posts: 23
Joined: Mon Mar 30, 2020 4:35 pm

Game loop order

Post by nyanberrycake »

What's the general order for a (platformer) game loop?

I've got hit detection squared away, I just don't know where to put it in my loop.

I feel like it would be a good idea to call my collision detection routine AFTER I interpret the player's behaviour based on input, but it also makes sense to call it before I interpret the player's input and stay one step ahead of it and eliminate the need to react after I spend all that time updating the player. I can't seem to find a straight answer on game loop design, I'd appreciate a good reference article
User avatar
Dwedit
Posts: 4922
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Game loop order

Post by Dwedit »

What I ended up doing was putting a collision check inside the code that handles the Enemies or Projectiles. Their code called a function to check for collision with the player.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
nyanberrycake
Posts: 23
Joined: Mon Mar 30, 2020 4:35 pm

Re: Game loop order

Post by nyanberrycake »

Dwedit wrote: Sat Apr 17, 2021 6:47 pm What I ended up doing was putting a collision check inside the code that handles the Enemies or Projectiles. Their code called a function to check for collision with the player.
That sounds the easiest. then I can avoid calling it for objects that don't need it. I think I have been overthinking/over-engineering my sprite objects. Thanks!
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Game loop order

Post by Bregalad »

nyanberrycake wrote: Sat Apr 17, 2021 6:39 pm What's the general order for a (platformer) game loop?

I've got hit detection squared away, I just don't know where to put it in my loop.

I feel like it would be a good idea to call my collision detection routine AFTER I interpret the player's behaviour based on input, but it also makes sense to call it before I interpret the player's input and stay one step ahead of it and eliminate the need to react after I spend all that time updating the player. I can't seem to find a straight answer on game loop design, I'd appreciate a good reference article
Why don't you try different orders and see if this creates any difference ? (such as loss of control responsiveness)

I'd say the only very important thing is to update your shadow OAM as a last step before waiting VBlank and then doing the sprite DMA during VBlank. That way you are sure that what is displayed on screen is the most recent, up to date, according to your game state with ~half frame delay.

Otherwise you get things such as sprites scrolling one pixel ahead, visible for example in Super Mario Land 3 - Wario Land (Gameboy).
Useless, lumbering half-wits don't scare us.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Game loop order

Post by tokumaru »

It really depends on the kinds of interactions that objects can have in your game... In a simple game where objects are not solid, cannot push or carry other objects, then the order in which you process everything hardly matters.

However, if objects can affect the positions of other objects, you might want to go for something more well structured. I prefer to do an update pass first, where objects update themselves while completely ignoring other objects (except if an object is being carried by another object - in this case, it will first make sure that the other object has been updated, and then will apply that object's displacement to its own position), and then a second pass where each object tests for collisions against any objects of interest, and notifies them of any collisions so they can react accordingly.

I can take shortcuts if I know there will be no side effects. For example, since the player objects are the first to be updated, I can have objects test for collisions with them during the update pass, to avoid having to call these objects multiple times.

Like Bregalad said, do pay attention to the fact that sprite coordinates need to be in sync with the scroll so you don't end up with sprites jittering of lagging behind (this happens in so many games with moving platforms!). One thing you can do that helps with that is to update the camera BEFORE all other objects, effectively having it track the player's position from the last frame, which is known to be valid. This way you don't have to worry about when the OAM entries are generated, because the scroll position is already final when the objects begin updating and nothing will change it.
User avatar
Dwedit
Posts: 4922
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Game loop order

Post by Dwedit »

You don't even need to lag the camera behind by a frame. Moving the camera only has to happen before the OAM entries are created.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Game loop order

Post by tokumaru »

Dwedit wrote: Mon Apr 19, 2021 9:56 amYou don't even need to lag the camera behind by a frame. Moving the camera only has to happen before the OAM entries are created.
Yes, ideally you'll have everything in their final positions before having the camera follow the player, and then create all the OAM entries. But if by any chance you're trying to save some time by generating OAM entries during the object update phase (maybe on objects that can't be moved by other objects, such as bullets, platforms, etc.), one way to do that safely is to lag the camera one frame behind. I haven't really tested this, but I doubt it'll be noticeable.
User avatar
nyanberrycake
Posts: 23
Joined: Mon Mar 30, 2020 4:35 pm

Re: Game loop order

Post by nyanberrycake »

tokumaru wrote: Mon Apr 19, 2021 7:03 am I prefer to do an update pass first, where objects update themselves while completely ignoring other objects (except if an object is being carried by another object - in this case, it will first make sure that the other object has been updated, and then will apply that object's displacement to its own position), and then a second pass where each object tests for collisions against any objects of interest, and notifies them of any collisions so they can react accordingly.
This is what I am looking for, thanks

I'm not fussing with scrolling on my first game, but I really appreciate the tips about the camera, as I will eventually need it
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Game loop order

Post by Bregalad »

I'm not fussing with scrolling on my first game, but I really appreciate the tips about the camera, as I will eventually need it
Even if your game is not scrolling, it's nice to have good practice from the start.

So basically do shadow OAM last and you'll be fine.
Useless, lumbering half-wits don't scare us.
Post Reply