Game Optimization Tips

[marathon332]

This 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

[marathon332]

Found this on WikiPedia. It's an interesting read with some additional information related to Frame Rate in games

http://en.wikipedia.org/wiki/Frame_rate ... ideo_games

[Game A Gogo]

a full-screen game will always have a better fps, because it has a better direct access and also directdraw dosntr have to constently refresh the windows GUI.

[marathon332]

Makslane:

To speed things up, does Game Editor take advantage of the Game API (GAPI) on WM5 devices?

If not, will it?

--Steve

[makslane]

Game Editor uses PocketHAl thats provide faster access than GAPI.
From PocketHAL page:

"PocketHAL has a more efficient way of accessing the display hardware then GAPI. As a last resort (and backup procedure), PocketHAL will use the same system calls as GAPI to access a Pocket PC display."

[makslane]

I have tested OpenGL ES too, but the frame rate for current 2D games is very frustrating.

In my benchmark test, in a Dell Axim X50v, I get about 8 fps with OpenGL enable, and 30fps with current engine.

[marathon332]

Makslane:

Thanks for the information. It's very useful...

I visited the websites for PocketHAL and OpenGL ES and now I understand how Game Editor works with the screen a lot better and I see why you chose PocketHAL

So, in your opinion there should be no performance difference on a WM5 device. Is that correct?

BTW, I also own an Axim x50v...

--Steve

[makslane]

I can see differences only due the clock and memory speed, but not due operating systems differences.

[marathon332]

Thanks Makslane..

One more thing...

I think I read somewhere in the forum that Game Editor has it's own internal compressed image format that it uses in the final output. Is that correct?

So does loading a lower resolution image into the game such as a 16 or 256 color gif or other compressed image format have any impact on FPS in the final output?

If so, what image format is the best as far as frame rate is concerned?

What do you recommend as the best image type to use to achieve better FPS?

--Steve

[makslane]

All images, regardless input format, will be converted to the same internal format. For Pocket PC, all images are converted to 16bbp for a optimized blitter.

[Game A Gogo]

All images, regardless input format, will be converted to the same internal format. For Pocket PC, all images are converted to 16bbp for a optimized blitter.

or you meen 16bbp whit 8bbp of transparencies?

[makslane]

Will use 8bit alpha channel only for segments of image that aren't solid.

[Game A Gogo]

k, so its like on a non solid area, it has

Code: Select all

2072672color(16bbp) and 2color(1bbp) for solid and complete transparent

and on semi transprent area

Code: Select all

2072672color(16bbp) and 255(8bbp)(why 255 transparent whhille the other rbg valu only has 127 color each?) for semi transparent area

if you changed that 8bbp to a 6bbp(127 colors) it wont change anything, and maybe increase the fps valu a little bit.(since it wont have render 255 color for transparent for nothing since only half of it is used)

[marathon332]

Great answers...

So colors and input format have no effect and there is no need to optimize.

In Game Editor using alpha transparency set other than 0 will cause a slowdown but if I use alpha transparency say at 50 percent set from an external image editor like Photoshop, does it lower the frame rate too?... or not?

--Steve

[makslane]

Yes if you use transparency will slowdown the render of the segment.