optimalization questions

hi,

been asking myself alot of questions about texture size and events, what would be best way to do this and so on, been reading some post and most end with saying "worry about rendering speed",

so i decided to start some optimalization topic mostly about that. feel free to add and answer or if you have tips for some things, please post it

if you have a graphic of 512 x 512 and you resize it to 32x32, what is the final output, will it take more resources to work with the texture , than an original 32x32 graphic

an to the same, if you have a 512x512texture and make it 1024x1024 will it work faster then an original 1024

if you have like a line spread out between points, it will take the square space that is needed to draw the line, will this affect renderingspeed much, if its very big, like 2000px, or

will it not take much as its just a line?

whatever is set invisible has no influence in render speed? or does it take cpu to calculate , lets say a texture of 512x512 invisible will take less cpu then 1024x1024 invisible to translate,

is invisible the same as opacity 0 ?

is it better to cram everything together in the same for each "object" action or dont worry about it an split it up as much as you want for better overview

if you have an area of 10000 by 10000, and there is some activity in places, is there something you can do to make it less cpu intensive or will the extra eventchecking make it more intensive

if you zoom out, very far, more objects are rendered would it be a good thing to exchange the sprite with something smaller or less detailed, set the sprite to frame 2 for example

, or hide things that arent showing anyway, like particles

You might find the Optimisation tips wiki page interesting.

if you have a graphic of 512 x 512 and you resize it to 32x32, what is the final output, will it take more resources to work with the texture , than an original 32x32 graphic

"Resources" is a fairly vague term - it could mean memory usage, or processing time. Usually processing time is most important, as long as you can fit everything in to memory.

The important things here are:

• The source texture - in this case your 512x512 image
• The destination rendering size - in this case scaled down to 32x32
• Whether any pixel shader 1.1 or 2.0 effects are applied

Generally, with no effects applied and a good graphics card, it's very hard to measure any performance differences between various combinations of scaling up small textures or scaling down large textures. Graphics cards are precisely designed for that kind of thing so as far as I can remember from my own tests, they render about the same speed as not scaling it at all!

However, the source texture is always in video memory (VRAM) so a larger source image will occupy more VRAM than a small source texture. As above though, this does not seem to affect the framerate much.

[quote:1l4kb5ro]an to the same, if you have a 512x512texture and make it 1024x1024 will it work faster then an original 1024

As above it probably runs just as fast, but in this case you're using less video memory, since the source texture is smaller.

[quote:1l4kb5ro]if you have like a line spread out between points, it will take the square space that is needed to draw the line, will this affect renderingspeed much, if its very big, like 2000px, or

will it not take much as its just a line?

Do you mean like a long, thin sprite rotated at 45 degrees? In this case its bounding rectangle (its outline) is very large, but the actual drawn area is small in comparison.

If you don't have any PS 1.1 or above effects applied, it only draws the line area, which is fast.

If you have got PS 1.1+ effects applied, it renders the full bounding box area, which can be slow! However, graphics cards won't bother drawing anything offscreen, so it's never going to process a 2000x2000 area - just what you see on-screen.

So if you use effects, try to keep the objects small, and if you don't, the next best thing is to use fewer (but sprites without effects are very fast to render).

[quote:1l4kb5ro]whatever is set invisible has no influence in render speed? or does it take cpu to calculate , lets say a texture of 512x512 invisible will take less cpu then 1024x1024 invisible to translate,

is invisible the same as opacity 0 ?

Invisible objects still run events (so take some CPU time), but skip rendering completely.

Objects with 0 opacity are still rendered so have the same performance impact. So you're always better off using 'make invisible' than setting to 0 opacity. It's intentional that they are still drawn with 0 opacity, because if you used an effect which changes opacity (eg. inverts it), then the object would become visible.

[quote:1l4kb5ro]is it better to cram everything together in the same for each "object" action or dont worry about it an split it up as much as you want for better overview

I doubt you'll ever measure a difference (try it and see if you can see a change in fps) so I would advise you do whatever makes your events easiest to read.

[quote:1l4kb5ro]if you have an area of 10000 by 10000, and there is some activity in places, is there something you can do to make it less cpu intensive or will the extra eventchecking make it more intensive

I'm not sure what you mean. The fact that the layout is big doesn't have any performance impact itself. Only things on-screen affect rendering speed, and objects run events even if they are offscreen.

[quote:1l4kb5ro]if you zoom out, very far, more objects are rendered would it be a good thing to exchange the sprite with something smaller or less detailed, set the sprite to frame 2 for example

, or hide things that arent showing anyway, like particles

As I said above swapping for smaller textures probably won't affect anything - it's more the number of things on-screen will be very large.

Making things like particles invisible is a good idea. If you couldn't see them anyway, you can save the graphics card from even attempting to render them. This could speed things up a lot if you have a lot of particle effects.

Gah, Ashley beat me to it.

(Edits out most of what Ashley said)

[quote:3oi8iiaa]an to the same, if you have a 512x512texture and make it 1024x1024 will it work faster then an original 1024

One thing not mentioned is fill rate/overdraw. GPUs can only crank out so many pixels per second (pixel fill rate). If you draw two sprites, and one of them is completely obscured by the sprite in front of it, the gpu will have essentially wasted that time drawing the obscured object. Normally this isn't much of an issue (and there isn't an efficient way to tell if an object is obscured), but it helps to think about when planning a level.

[quote:3oi8iiaa]is it better to cram everything together in the same for each "object" action or dont worry about it an split it up as much as you want for better overview

Generally I've found it doesn't matter, but if you're going to do lots of intensive loops, then sticking everything in the same 'for each' might be a good idea. Otherwise you do a lot more loops than you need. You can check how long the event sheet is taking via the debugger, where you can check the ratio of time spent running events/drawing the frame.

[quote:3oi8iiaa]if you have an area of 10000 by 10000, and there is some activity in places, is there something you can do to make it less cpu intensive or will the extra eventchecking make it more intensive

You can deactivate behaviors and set the collision mode of offscreen objects to 'off'. This speeds things up dramatically.

[quote:3oi8iiaa]if you zoom out, very far, more objects are rendered would it be a good thing to exchange the sprite with something smaller or less detailed, set the sprite to frame 2 for example

, or hide things that arent showing anyway, like particles

I suggest trying it. Set the FPS to unlimited and experiment.

thanx for the great reply's definetly clears some things up,

oh and for the line question , its a sprite width set to two points and this can be any angle, any length

im using the warp effect on it, and its pretty cool, so this means it will render the full bounding area of the line? hmm no real alternative to it, it seems, not that it goes slow, but i have a hd 4780 card, so nothing gets really slow