Contents  Introduction  Stepping to the  plate...  Mr. Structure  The New Shape  Maker  Update takes a few  practice swings  Let's Get Moving!  Time to Clear the  Bases?  The Final Batters  The Loop and His  Team  Until Next Time...  Printable version     The Series  Part 1  Part 2  Part 3  Part 4  Part 5  Part 6

The Loop and His Team

The loop is a very complex manager. He does his best to organize things though. He has state variables that way e doesn't process what he doesn't need to, and he also uses many different timers to make sure things are getting done. Have a look at his innards.

As you can see, if the user selects to have a new game, "loop" makes a bunch of calls. First he make a call to initialize our grid, then one to create a new shape. Next he makes a couple to get the starting time for input and the starting time for updates, and then, finally, he sets the game state to playing.

We have now entered the game. So, every frame, he draws the bitmap onto the back buffer and decides if it is time to process some input. If so, he makes a call to process the input and then he reacts based upon the keys that are pressed. With that completed he re-initializes the input time. Otherwise, if enough time hasn't passed, he skips the input phase altogether.

The same thing is done with Updating. He first finds out if it is time. If enough time has NOT elapsed, he skips over the updating and makes calls to draw everything. If it has, then he calls the update function and reacts to what update has to tell him. If Update fails then that means it is time for a new shape. But, first we call the test to see if there are valid lines. We keep doing this until no more valid lines exist, and then we create the new shape and re-init our update time.

If, during this time, the call to create a new shape fails then the user has died and the game state is set to reflect that. Finally he updates the display by flipping our primary and back buffers. Then he does it all over again, synchronizing it to the desired frame rate.

The one thing I want to comment on here is the use of time based updates. This is a very crucial part of developing a game. If we had updated the input every frame, things would be flying everywhere, and the user would be in a state of shock. The same thing with updating the shapes. Also, your machine may achieve 100 FPS and yet another machine would only be able to do 25 FPS. This means that, if you are using frame-based code, the game will look/react in different ways across the two machines.

By using time, you can close to guarantee it will look the same across all capable machines. The reason for this is time, unlike a frame rate, can not change across machines. The rate at which a second occurs is the same no matter what you run it on.

The code we have here is a simple implementation of this premise. You can definitely get more complex. Still, this code works, and works well for what it needs to do.

Next : Until Next Time...