How do you order your game code?

How do you order your game code?

Order #1:

Code:

---

int DoStuff()
{
  // Get user input.
 
  // Figure out what happens.
  // (Whats really happening).
 
  // Render objects on screen.
}

---

Order #2:

Code:

---

int DoStuff()
{
  // Render objects on screen.
 
  // Get user input.
 
  // Figure out what happens.
  // (Whats really happening).
}

---

Order #3:

Code:

---

int DoStuff()
{
  // Figure out what happens.
  // (Whats really happening).
 
  // Render objects on screen.
 
  // Get user input.
}

---

I do Order #1. I have seen code like
in Order #2, but never like Order #3.

Order 1

I havent gotten to the point where I need to render objects -,-. I guess I'm closest to option #1.

I would think that anything other than Order 1 would increase the chance of unintuitive results from user interaction to the world when the application is experiencing certain kinds of lag. Depending on the application type and its structure, its a conceivable situation that the other two orders could actually break the user interface in a carelessly coded/designed project (especially Order 3).

Since you're continuously looping the only difference between the three orders is which step you start from.

I would generally use #1, but maybe #2. Doubt I'd ever use #3 though.

Order #1. As lightatdawn put it, I find any other order causes game lag. The only other order I might use is to stick game input into a thread of it's own so it can always respond instead of linearily respond.

Code:

---

void GameLoop()
{
  BuildRenderList();  //Frustum and occlusion cull here
  Render();              //Render the list
}

void Setup(void)
{
  StartInputThread();
  StartSoundFXThread();
  StartMusicThread();
  StartScriptThread();
}

---

This way game input is done in parallel (somewhat) with the rendering.
Instead of washing the dishes and then drying them, we wash them and dry them.
:)

Quote:

---

Originally Posted by Quantum1024

Since you're continuously looping the only difference between the three orders is which step you start from.

---

Exactly, those three are all equivalent.

Quote:

---

Originally Posted by Sang-drax

Exactly, those three are all equivalent.

---

Not quite. If the loop contains a delay, the user input should be the first thing processed after the delay.

I'd probably use multiple threads (if possible), with the user input thread being the highest priority, the interaction thread (game logic) the second highest, and the rendering the lowest of the three. But then again, I don't write a lot of games.

That sounds like what I'd do as well, but then indeed I too don't get around to writing games.
Too busy writing software for a living to spend my nights writing it for fun most of the time.

Quote:

---

Originally Posted by filker0

Not quite. If the loop contains a delay, the user input should be the first thing processed after the delay.

---

What do you mean by delay? The biggest delay is usually the graphics rendering.
If you (for some mysterious reason) add some extra delay in the loop, they would effectively be equivalent anyway, if the framerate isn't extremely low.

Quote:

---

Originally Posted by Sang-drax

What do you mean by delay?

---

Exactly what I said. A delay. To limit the rate at which events occur. To allow for users (and in multi-user, networked games, other users) to react. If you run the physics at full CPU speed, the gameplay will be quite different on a machine with fast graphics and a 3GHz CPU vs. that on a 1.2GHz CPU and lower-end graphics.

That is why I brought up the thread thing, with rendering at the low end of the priority scale. If rendering is a background task, the main gameplay tells the rendering engine what the current state of affairs is and lets it do its work. On a faster machine, you get a higher frame rate, but the game remains responsive on a slower machine.

When dealing with networked games, the user actions and remote communications must have roughly equal priority, processing remote changes before determining the effect of the user actions. "Fairness" comes into play, and I'm not going to give an Operations Research lecture in this forum to explain what that is and how it's done.

Note that the same sort of considerations must be made for any interactive program that deals with asynchornous events, such as a terminal emulator (or terminal firmware), embedded microcontroller, or avionics display.

Adding a delay in a game loop is ludicrous. Be assured the rendering will add that for you, either with or without your approval.

Tis why fast rendering algos are an absolute must for graphics and 3D games. You must get the polygons and tri's down to a manageable value in order to produce the required FPS.

Quote:

---

Originally Posted by Bubba

Be assured the rendering will add that for you, either with or without your approval.

---

Be assured that if you write the game in this manner, with no rate limiting on the physical model, your game will be unplayable as machines get faster and faster. In modern "real-time" (vs. turn based) games, the rendering is done asyncronously. User control events are very infrequent in terms of CPU time, and the physical model (that reacts to the users actions and sets up the data structures that the rendering engine uses to represent the world) must run at a fairly constant rate, independent of what the frame rate is.

I have written video game code for a commercial product.

Quote:

---

What do you mean by delay? The biggest delay is usually the graphics rendering.
If you (for some mysterious reason) add some extra delay in the loop, they would effectively be equivalent anyway, if the framerate isn't extremely low.

...

Adding a delay in a game loop is ludicrous.

---

It really has mostly to do with physics. If you haven't written a differential equation solver (no matter how simple) then you wouldn't have to worry about trying to run things at a fixed FPS.

Bubba's projects that I have seen seem mostly graphics related (nice ones too) but they don't appear to have much implemented as far as physics go (I could be wrong). Subsequently, limiting the frame rate really doesn't apply to him...speed is key, the one and only holy grail.

When you do start implementing physics, your target is to have your differential equation solver remain as stable as possible...this means fixing the framerate that the physics is allowed to run at. The reason for this is that you must test and custom tailor a fixed timestep that makes your differential equation solver's solutions converge on accurate results (the failure in this department results in 'explosions,' especially with mass-spring systems that represent suspension on simulated vehicles, especially tricky situations like that).

This is especially important when you start integrating complex mathematical constructs such as quaternions and/or rotation matrices, in which there are strict stipulations that must be followed or manually enforced, else you get very weird 'in your face results' (non-unit length quaternion, or a rotation matrix in which the columns [or, for bubba, rows] are not orthogonal means that they represent something other than rotations...these build up from inaccuracies in the equation solver).

In my physics manager, I target 100.0f frames per second...and I'm still having an oh-so-fun time getting the suspension for my hovertanks to work properly.

The reason you cannot allow the graphics to run faster than the physics is that you would be rendering the same frame over and over again (no movement happens until a physics frame has been run). On the flip side, if your Physics framerate rendering is happening at 100.0f fps, and graphics slows to 50.0f fps, you end up rendering two physics frames per graphics frame.


>>I have written video game code for a commercial product.

Which title. What, exactly did you work on? Sounds neat.

Quote:

---

Originally Posted by BobMcGee123

Which title. What, exactly did you work on? Sounds neat.

---

I worked on underlying code that ended up in a few games from a company called MediaStation. "Extreme Tactics" and, er, "Rocky and Bullwinkle". The latter was a children's game that lacked physics at all -- it was a collection of puzzle solvers with a few "action" games that were, in effect, turn-based with the user-input handled in "real time" and the game movements based on a timer. My game-studio gig was less than a year.

[edit]
I should point out that I was working on the game platform code for a non-PC platform; these games existed as PC games as well, and I didn't write the code for that. But I had to understand what was going on to do what I did.
[/edit]