View Poll Results: How do you order you game code?

Voters
16. You may not vote on this poll
  • Order #1

    16 100.00%
  • Order #2

    0 0%
  • Order #3

    0 0%

How do you order your game code?

This is a discussion on How do you order your game code? within the A Brief History of Cprogramming.com forums, part of the Community Boards category; How do you order your game code? Order #1: Code: int DoStuff() { // Get user input. // Figure out ...

  1. #1
    Registered User Queatrix's Avatar
    Join Date
    Apr 2005
    Posts
    1,342

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

  2. #2

    Join Date
    May 2005
    Posts
    1,041
    Order 1
    I'm not immature, I'm refined in the opposite direction.

  3. #3
    60% Braindead
    Join Date
    Dec 2005
    Posts
    379
    I havent gotten to the point where I need to render objects -,-. I guess I'm closest to option #1.
    Code:
    Error W8057 C:\\Life.cpp: Invalid number of arguments in function run(Brain *)

  4. #4
    Peace
    Join Date
    Aug 2001
    Posts
    1,510
    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).
    "There's always another way"
    -lightatdawn (lightatdawn.cprogramming.com)

  5. #5
    Registered User
    Join Date
    Jan 2005
    Posts
    847
    Since you're continuously looping the only difference between the three orders is which step you start from.

  6. #6
    Cat Lover
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    109
    I would generally use #1, but maybe #2. Doubt I'd ever use #3 though.

  7. #7
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    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.

  8. #8
    S Sang-drax's Avatar
    Join Date
    May 2002
    Location
    Göteborg, Sweden
    Posts
    2,072
    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.
    Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

  9. #9
    Sr. Software Engineer filker0's Avatar
    Join Date
    Sep 2005
    Location
    West Virginia
    Posts
    235
    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.
    Insert obnoxious but pithy remark here

  10. #10
    chococoder
    Join Date
    Nov 2004
    Posts
    515
    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.

  11. #11
    S Sang-drax's Avatar
    Join Date
    May 2002
    Location
    Göteborg, Sweden
    Posts
    2,072
    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.
    Last edited by Sang-drax : Tomorrow at 02:21 AM. Reason: Time travelling

  12. #12
    Sr. Software Engineer filker0's Avatar
    Join Date
    Sep 2005
    Location
    West Virginia
    Posts
    235
    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.
    Insert obnoxious but pithy remark here

  13. #13
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    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.

  14. #14
    Sr. Software Engineer filker0's Avatar
    Join Date
    Sep 2005
    Location
    West Virginia
    Posts
    235
    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.
    Insert obnoxious but pithy remark here

  15. #15

    Join Date
    May 2005
    Posts
    1,041
    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.
    I'm not immature, I'm refined in the opposite direction.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 14
    Last Post: 04-01-2008, 02:23 AM
  2. 2D Game project requires extra C++ programmers, new or experienced
    By drallstars in forum Projects and Job Recruitment
    Replies: 2
    Last Post: 05-16-2007, 10:46 AM
  3. Problem with game code.
    By ajdspud in forum C++ Programming
    Replies: 5
    Last Post: 02-14-2006, 05:39 PM
  4. Game Engine Link Prob
    By swgh in forum Game Programming
    Replies: 2
    Last Post: 01-25-2006, 11:14 PM
  5. My Memory Game
    By jazy921 in forum C Programming
    Replies: 0
    Last Post: 05-05-2003, 05:13 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21