Game Optimization Tips
Posted: Sun Aug 06, 2006 2:29 pmThis thread is for the discussion of ideas and methods on how to make your games faster and smaller. There wasn't alot available when I searched this forum, so I decided to start this thread.
I'm not an expert yet, so feel free to add your tips here as well. By sharing our ideas everyone will hopefully be able to make better, smoother and more playable games.
Q. Why is optimization needed?
A. Smoother Game Play = Better Game
Your final game will be more enjoyable and less frustrating for the player.
This is especially true for Pocket PC's and Smartphones where memory and processing power are very limited. It's also true for more complex desktop games that contain lots of graphics and complex animations.
Optimization comes down to one thing. Getting the maximum frames per second (FPS) up to the maximum speed we need for our games to run well on our target platform(s).
How fast should our game be? That depends on the type of game and the device you're designing for but Game Editor's default setting is 30 fps which is an industry standard according to what I've read. 30 FPS is also the speed of Internet video and gives pretty smooth playback.
As part of some pre-planning for a game idea I have, I tested Game Editor's performance on a couple of Pocket PC's I own (624 and 312 mhz XScale Processors).
With a complex background and a simple 2 frame animation, they ran at 43 and 77 FPS.
But when I ran the 1945 demo project that contains hundreds of animations, graphics, and a few sounds and music, that performance degraded to as low as 4-6 frames per second in some places in the game. Needless to say, game play was choppy and clearly not acceptable as a final product.
In my work as a Flash developer, 15 frames per second is what I usually develop for on the web, so I want to at least get into that ballpark in my Game Editor game.
So I have to come up with a way to get the frame rate up to an acceptable level, which is what spurred me into looking for methods of speeding up my game.
In order to get a handle on the issue of game speed, we need to have a better understanding of our games from the computer's standpoint.
Today I'll begin with the basics and in future posts get into the ways we can overcome slow frame rates.
The following is adapted from the book "Flash Games Studio" page 37 published by Friends of Ed.(2001) What it has to say applies to all computer animation so it's worth a read.
I put the name Game Editor in place of Flash and added whatever applys to Game Editor and ignored the rest.
The Frame
=========
When we watch TV, we are watching a series of still images -- frames that zip past at a rate of about 30 frames per second. So, in one second, 30 consecutive images have flashed by and created the illusion of motion.
In Game Editor, we have the option to choose our desired frame rate under the game properties panel.
In theory, this all makes sense and there's nothing more to do. However, things aren't quite that simple. Frame rate in Game Editor can really only be called a "desired frame rate" because many things are going to foul up our plans for that perfectly smooth 30 FPS game.
As each frame passes, Game Editor must look after a number of things. For a start, it must execute all of the C code in a single frame of your game. So, if you have monsters running around, gravity pulling you down, physics moving you along and scores to keep, then Game Editor is already processing a substantial amount of information -- that's before it has even started drawing the images.
Add to that, whatever else the computer may be doing in the background and you'll appreciate just how busy your computer really is.
Graphics
========
Graphics are the single greatest thing that are going to slow down your game.
This is simply because there are so many millions of decisions to be made to render the graphics on screen. The task is colossal and there are a certain number of decisions to be made before you even attempt to bring your image to the screen. If we take it right down to the basic elements, those decsions should become a lot easier to make.
The Pixel
=========
A screen is made up of a grid of dots called pixels. The word pixel is derived from "picture elements".
The word to describe the number of pixels on the screen is resolution. Modern desktop computers allow you to vary the screen resolution but devices like Pocket PC's and Smartphones usually have fixed sizes. The higher the resolution, the more pixels you have on the screen and the more detail you can fit on it.
It's important for us to take into account how a computer does what it has to do at the lowest level. At it's core, a computer has a clock that ticks at a certain number of times per second.
The Clock
=========
The master clock is an independent electrically powered quartz cystal in the CPU of your computer, responsible for keeping every action in your CPU synchronized. Everytime this crystal vibrates or "ticks", it delivers an electrical charge and your computer is able to do one instruction.The number of times that this clock ticks determines the speed of your CPU. 800 Mhz is 800 million vibrations/ticks per second. 1.7 Ghz is 1.7 billion ticks per second. The faster this clock ticks, the faster your computer can do things.
Every single action your computer performs takes a certain number of clock ticks.
For example, let's say that we want the computer to draw one single pixel on the screen, in the upper left corner.
Your program goes through several steps to carry out this operation:
Tick 1: The game tells the computer a graphic instruction is coming up
Tick 2: The game tells the computer a pixel draw is coming up
Tick 3: Your game tells the computer the x coordinate of the pixel
Tick 4: Your game tells the computer the y coordinate of the pixel
Tick 5: Your game tells the computer the color of the pixel
Tick 6: The computer renders the pixel
Ticks 7-12: Overhead calculations the computer has to perform to actually take the virtual rendered pixel and put it onto the real screen
Say we want to fill the whole screen from top to bottom in one solid color. At an 800 x 600 resolution, that's 480,000 pixels. That's a grand total of 5,760,000 clock ticks to fill the screen. By the time your screen is filled, the computer has done nearly 6 million clock ticks.
Now, let's say we're running on a 600 Mhz machine, which means 600 million clock ticks per second. 5,760,000 clock ticks divided into 600 million is about 104. That means the computer can completely redraw the screen in one solid color 104 times per second or put another way, at 104 frames per second.
That's a nice frame rate! But keep in mind this is an idealistic example of the computer's efforts. In reality, the computer has a lot more to do than just dedicate all it's energies to filling the screen for us. In the world of a multitasking operating system like Windows or Linux, a computer is never doing just one thing at a time. So, realistically speaking, of those 600 million cycles, maybe only 300 million are available strictly for our drawing test.
Which means our frame rate is:
300 million / 5,760,000 = 53 complete screen draws per second
So, our maximum frame rate here is 53 FPS. Well, that's still pretty good. The only thing not good about it is that we have achieved a completely blank screen, whatever the color. As soon as we start adding images, things are going to start slowing down pretty fast, and we only have 23 FPS to play with before our 30 FPS target is eaten into.
That's the reason why the 1945 demo project I tested got such poor results. It really is just a model to illustrate game development techniques and not a finished project until it's been optimized.
Whew!
This post is long-winded but it shows us just how important it is to simplify things as much as possible in order for the computer to be able to do its job.
That's really what is meant by the term optimization.
Optimization = Simplification
We need to reduce the number cycles it takes for the computer and Game Editor to completely redraw the screen in each frame.
Makslane has done an excellent job of programming Game Editor to do a lot of the work for us but we need to complete the process to really make our game polished and complete.
We can do this in two basic ways. Graphics simplification and code simplification.
That's it for the basics. I hope it's been useful to you.
My future posts will focus on tips.
Please add your comments and tips so that we develop a really great optimization resource for others to read and learn from.
To get started, here's a code snippet posted by DilloDude in the forums.
create a real array of size 50, called prevframes, and create an integer called frameno. Add a draw actor on your text number actor, Code:
prevframes[frameno] = real_fps;
frameno += 1;
if (frameno >= 50)
{
int i;
double addframe = 0;
for (i = 0; i < 50; i ++)
{
addframe += prevframes[i];
}
textNumber = addframe / 50;
frameno = 0;
}
Thanks DilloDude!
I tried this and it works great. It displays the average frame rate acheived
and makes the frame rate easier to read when using the real_fps variable.
Put this in your game to help you measure you optimization success.
--Steve
I'm not an expert yet, so feel free to add your tips here as well. By sharing our ideas everyone will hopefully be able to make better, smoother and more playable games.
Q. Why is optimization needed?
A. Smoother Game Play = Better Game
Your final game will be more enjoyable and less frustrating for the player.
This is especially true for Pocket PC's and Smartphones where memory and processing power are very limited. It's also true for more complex desktop games that contain lots of graphics and complex animations.
Optimization comes down to one thing. Getting the maximum frames per second (FPS) up to the maximum speed we need for our games to run well on our target platform(s).
How fast should our game be? That depends on the type of game and the device you're designing for but Game Editor's default setting is 30 fps which is an industry standard according to what I've read. 30 FPS is also the speed of Internet video and gives pretty smooth playback.
As part of some pre-planning for a game idea I have, I tested Game Editor's performance on a couple of Pocket PC's I own (624 and 312 mhz XScale Processors).
With a complex background and a simple 2 frame animation, they ran at 43 and 77 FPS.
But when I ran the 1945 demo project that contains hundreds of animations, graphics, and a few sounds and music, that performance degraded to as low as 4-6 frames per second in some places in the game. Needless to say, game play was choppy and clearly not acceptable as a final product.
In my work as a Flash developer, 15 frames per second is what I usually develop for on the web, so I want to at least get into that ballpark in my Game Editor game.
So I have to come up with a way to get the frame rate up to an acceptable level, which is what spurred me into looking for methods of speeding up my game.
In order to get a handle on the issue of game speed, we need to have a better understanding of our games from the computer's standpoint.
Today I'll begin with the basics and in future posts get into the ways we can overcome slow frame rates.
The following is adapted from the book "Flash Games Studio" page 37 published by Friends of Ed.(2001) What it has to say applies to all computer animation so it's worth a read.
I put the name Game Editor in place of Flash and added whatever applys to Game Editor and ignored the rest.
The Frame
=========
When we watch TV, we are watching a series of still images -- frames that zip past at a rate of about 30 frames per second. So, in one second, 30 consecutive images have flashed by and created the illusion of motion.
In Game Editor, we have the option to choose our desired frame rate under the game properties panel.
In theory, this all makes sense and there's nothing more to do. However, things aren't quite that simple. Frame rate in Game Editor can really only be called a "desired frame rate" because many things are going to foul up our plans for that perfectly smooth 30 FPS game.
As each frame passes, Game Editor must look after a number of things. For a start, it must execute all of the C code in a single frame of your game. So, if you have monsters running around, gravity pulling you down, physics moving you along and scores to keep, then Game Editor is already processing a substantial amount of information -- that's before it has even started drawing the images.
Add to that, whatever else the computer may be doing in the background and you'll appreciate just how busy your computer really is.
Graphics
========
Graphics are the single greatest thing that are going to slow down your game.
This is simply because there are so many millions of decisions to be made to render the graphics on screen. The task is colossal and there are a certain number of decisions to be made before you even attempt to bring your image to the screen. If we take it right down to the basic elements, those decsions should become a lot easier to make.
The Pixel
=========
A screen is made up of a grid of dots called pixels. The word pixel is derived from "picture elements".
The word to describe the number of pixels on the screen is resolution. Modern desktop computers allow you to vary the screen resolution but devices like Pocket PC's and Smartphones usually have fixed sizes. The higher the resolution, the more pixels you have on the screen and the more detail you can fit on it.
It's important for us to take into account how a computer does what it has to do at the lowest level. At it's core, a computer has a clock that ticks at a certain number of times per second.
The Clock
=========
The master clock is an independent electrically powered quartz cystal in the CPU of your computer, responsible for keeping every action in your CPU synchronized. Everytime this crystal vibrates or "ticks", it delivers an electrical charge and your computer is able to do one instruction.The number of times that this clock ticks determines the speed of your CPU. 800 Mhz is 800 million vibrations/ticks per second. 1.7 Ghz is 1.7 billion ticks per second. The faster this clock ticks, the faster your computer can do things.
Every single action your computer performs takes a certain number of clock ticks.
For example, let's say that we want the computer to draw one single pixel on the screen, in the upper left corner.
Your program goes through several steps to carry out this operation:
Tick 1: The game tells the computer a graphic instruction is coming up
Tick 2: The game tells the computer a pixel draw is coming up
Tick 3: Your game tells the computer the x coordinate of the pixel
Tick 4: Your game tells the computer the y coordinate of the pixel
Tick 5: Your game tells the computer the color of the pixel
Tick 6: The computer renders the pixel
Ticks 7-12: Overhead calculations the computer has to perform to actually take the virtual rendered pixel and put it onto the real screen
Say we want to fill the whole screen from top to bottom in one solid color. At an 800 x 600 resolution, that's 480,000 pixels. That's a grand total of 5,760,000 clock ticks to fill the screen. By the time your screen is filled, the computer has done nearly 6 million clock ticks.
Now, let's say we're running on a 600 Mhz machine, which means 600 million clock ticks per second. 5,760,000 clock ticks divided into 600 million is about 104. That means the computer can completely redraw the screen in one solid color 104 times per second or put another way, at 104 frames per second.
That's a nice frame rate! But keep in mind this is an idealistic example of the computer's efforts. In reality, the computer has a lot more to do than just dedicate all it's energies to filling the screen for us. In the world of a multitasking operating system like Windows or Linux, a computer is never doing just one thing at a time. So, realistically speaking, of those 600 million cycles, maybe only 300 million are available strictly for our drawing test.
Which means our frame rate is:
300 million / 5,760,000 = 53 complete screen draws per second
So, our maximum frame rate here is 53 FPS. Well, that's still pretty good. The only thing not good about it is that we have achieved a completely blank screen, whatever the color. As soon as we start adding images, things are going to start slowing down pretty fast, and we only have 23 FPS to play with before our 30 FPS target is eaten into.
That's the reason why the 1945 demo project I tested got such poor results. It really is just a model to illustrate game development techniques and not a finished project until it's been optimized.
Whew!
This post is long-winded but it shows us just how important it is to simplify things as much as possible in order for the computer to be able to do its job.
That's really what is meant by the term optimization.
Optimization = Simplification
We need to reduce the number cycles it takes for the computer and Game Editor to completely redraw the screen in each frame.
Makslane has done an excellent job of programming Game Editor to do a lot of the work for us but we need to complete the process to really make our game polished and complete.
We can do this in two basic ways. Graphics simplification and code simplification.
That's it for the basics. I hope it's been useful to you.
My future posts will focus on tips.
Please add your comments and tips so that we develop a really great optimization resource for others to read and learn from.
To get started, here's a code snippet posted by DilloDude in the forums.
create a real array of size 50, called prevframes, and create an integer called frameno. Add a draw actor on your text number actor, Code:
prevframes[frameno] = real_fps;
frameno += 1;
if (frameno >= 50)
{
int i;
double addframe = 0;
for (i = 0; i < 50; i ++)
{
addframe += prevframes[i];
}
textNumber = addframe / 50;
frameno = 0;
}
Thanks DilloDude!
I tried this and it works great. It displays the average frame rate acheived
and makes the frame rate easier to read when using the real_fps variable.
Put this in your game to help you measure you optimization success.
--Steve