questions about maximizing an application's speed

[Larry]

A slew of questions about maximizing game speed:

1. All other things being equal, which will make your game run faster: if you code a command in many lines, or bunch everything onto one line?

For example, if you say "If Global Value A = 1, then create a box, candle, horse, etc." all in one line.

But you could do it the other way to. Enter separate codes for each item: "If Global Value A = 1," then create a candle." Next line: "If Global Value A = 1, create a horse," etc.

Does it make any difference to the speed of your application?


2. Does using "DirectX" make your application slower or faster? Or no difference?


3. Does it slow down the game if you have huge unused canvases for your active objects? Let's say you have a rock that's about 10x10, but the canvas for it, since you were too lazy to crop it, is 90x90. If the sprite has to lug this big empty area around, will it slow down the game, or will it make no difference since that is, after all, empty space?


4. Let's say I want a ball to flash red and blue. Two ways to code this: The first is to have two frames of animation only, and simply alternate between them.

The other way is to make, say, 50 frames of blue animation staggered with 50 frames of red animation for the time that I need it flashing.

Will it make a difference to game speed which way I code it?


5. All other things being equal, which will result in a faster game speed: having an active object assume 13 different animations, or create 13 different objects?

Take the "prize" in Ms. Pac Man. This could have appeared as a lot of things (apple, banana, cherries, etc.), yet its behavior was the same.

But let's say you have a lot of those roaming around your screen at the same time. In this case, does it make your game faster if you create several different objects (with different names), or if you simply change the animation sequences of one single object?


6. I assume that if you limit your game to 320x240 and only 256 colors, it'll run a lot faster. But I'm only assuming. Is this true?


7. Does it make a difference if I code an object's behavior in the object's properties versus in the events editor?

For example, when ball hits bat, ball flies away. I can code this into the ball's global behavior, or I can write a specific for it in the events editor. If we're talking about a lot of objects here, will it make a difference for game speed?


8. What lags the program more: having to destroy aan object and then create it again, or having to make it invisible and then make it reappear? Is there a difference?

For example, say I want the 7 snowballs to suddenly disappear and then reappear later. If the speed of my game is paramount, should I code this as destroying/recreating or becoming invisible/reappearing?

Thanks all.

[Nifflas]

I'm gonna answer with guesses. I honestly don't know, I'll just reply which one that seems most logical.

1: Every condition check requires CPU, and every action requires CPU too. So logically, less conditions = less CPU usage. Still, checking a global value is so fast, that it's much more important that you code it in a way that looks good and is practical for you, than the minimal difference in CPU usage it will make.

2: It depends. Sometimes it slows the application down, sometimes it makes it run faster. The best way to find out, is to set the framerate to something really higher than your computer can handle (500?), run the application, and check the debugger for which mode you get the highest framerate.

3: An active object is more cpu friendly if the size is smaller. However, I have no idea if MMF automatically crops the images before running or compiling the application, so I'm unsure about this one.

4: Why not set the animation speed to something really low and make it loop?

5: In this case, do what is most practical, rather than worrying about CPU usage. Remember that you can always use qualifiers to controll a bunch of objects with the same events, and it should be a nice solution.

6: Yes. Less colours and less resolution = less data to render.

7: I don't know.

8: I'd go for removing the objects. Remember that an invisible object still exists and requires CPU. At the other hand, if you need an object to disappear for a very short interval, make it invisible.


My most important suggestion to speed up your application is
* Handle background collisions even out of window should be OFF. Make sure you only program enemies to work with that setting.
* Set "inactivate object if far from frame" to Yes for every object it's possible with.
* If you have a complex group with a lot of events that controlls an enemy, have two events that opens or closes that group depending on if that enemy is on the screen. This way, a lot of conditions will not have to be checked and actions performer, if the enemy is not seen.
* The speed test I mentioned in point 2 is super practical for every situation. If you're unsure what eats most CPU, that's the best way to find out.

[LAJ]

[]1. All other things being equal, which will make your game run faster: if you code a command in many lines, or bunch everything onto one line?[/]
If there are multiple identical lines of code MMF will have to check to see if each is true. If you're just testing a global value then the difference will be too small to make any impact, but if you're performing heavy calculations then it's best to keep the duplicate events down to a minimum so that MMF doesn't have to calculate the same calculation more times than it needs to.

[]Enter separate codes for each item: "If Global Value A = 1," then create a candle." Next line: "If Global Value A = 1, create a horse," etc.[/]
In this instance I would use a loop and run it once. So:

Global Value = 1
-Start loop 'Create' 1 times

On loop Create
-Create object Candle

On loop Create
-Create object Horse

etc

The principle I follow is that the less code you have, the easier it is to maintain (and the less MMF has to do per event loop). This means keeping repetition of code down to a minimum. If you used a loop like above then if you wanted to change the code so that the objects are created when the global value equals 2 instead, then you only have to change one event rather than several.

[]2. Does using "DirectX" make your application slower or faster? Or no difference?[/]
On your list this would probably make the biggest impact. From the MMF2 help file: The Direct X mode uses Direct X to display the image and is usually slower than the standard graphic mode. The Direct X + VRAM mode uses the video RAM for the screen buffers. This mode is usually faster, especially with scrolling applications, but can be much slower if you use ink effects like semi-transparency in your application. Do not use ink effects or fade-like transitions in your application if it uses the DirectX+VRAM mode. Otherwise, use the Standard mode.

[]5. All other things being equal, which will result in a faster game speed: having an active object assume 13 different animations, or create 13 different objects?[/]
Having the same active will reduce required memory (not by much though), but I doubt it would effect speed substantially. The advantage would be that the same code is used by all of them so it is easier to maintain, but if you used multiple objects then you could give them each the same qualifier, and then instead of the code referencing each object it references the qualifier that they share.

[]6. I assume that if you limit your game to 320x240 and only 256 colors, it'll run a lot faster. But I'm only assuming. Is this true?[/]
The difference will be smaller depending on how powerful the PC running it is, but yeah, it would be a lot faster. 256 colours uses 1 byte per pixel, which is half that used in 32768 and 65536 and a third of that used in 16 million colours, so there's less data for the PC to handle. A smaller resolution helps on the same front.

[]7. Does it make a difference if I code an object's behavior in the object's properties versus in the events editor?[/]
I think behaviour code is just added at the end or beginning of the events list at runtime, so there wouldn't be any difference.