10 replies to this topic

[Evan20000]

I just wanted to try and get a brief list of all the things you can do in Zscript that can cause framerate drop.

 

So far I'm aware of:

 

Giving/Removing an item every frame.

Writing to Screen->D every frame.

Loading every L_Weapon or E_Weapon on a screen during a single frame. (Only when there's a decent number of them though)

 

 

What else are you guys aware of? I have a feeling this information will be very useful for optimizing scripts that cause framerate drop.

[Saffith]

Aside from repeatedly adding or removing items, the biggest issues just boil down to inefficient design. Cycling over every enemy, weapon, or combo is generally okay; it's when you've got nested loops or simply a lot of functions doing it that it becomes a problem.

It's not a big thing, but the most common inefficiency I've seen around here is a failure to use else.

if(counter==1)
    // ...
if(counter==2)
    // ...
if(counter==3)
    // ...

That's a lot of unnecessary tests, and they can add up. Potentially buggy, too, since one case might make a later condition true.

I also see a lot of code duplication - copying and pasting a bit of code repeatedly with few or no changes. That's not always a factor in framerate issues, but it can almost always be done better

[Moosh]

What about scaling and rotating large chunks of drawn tiles? Should this be causing lag?

[Evan20000]

On the topic of code duplication, is it just more efficient to just make a function for it if you need to call the same block of code several times? I was under the impression that the only difference between calling a function and having a standalone block over and over was how easy it is to read. (The advice is greatly appreciated. I'm a pretty terrible programmer.)

[Saffith]

What about scaling and rotating large chunks of drawn tiles? Should this be causing lag?

That's not going to be particularly fast, but it's never been an issue in my experience.
 

On the topic of code duplication, is it just more efficient to just make a function for it if you need to call the same block of code several times? I was under the impression that the only difference between calling a function and having a standalone block over and over was how easy it is to read. (The advice is greatly appreciated. I'm a pretty terrible programmer.)

It'll be slightly slower (without exception, I think - I don't believe the compiler's smart enough to do any sort of optimization), but readability and maintainability are generally more important.

[Moosh]

That's not going to be particularly fast, but it's never been an issue in my experience.

Should the slowdown scale with the number of things being drawn? I have a script that's drawing three scaling and rotating tile blocks and it drops my frames when uncapped to about 1/3. Combining that with Evan's other scripts I'm unable to hold a steady 60 any more. Have I just become Nick's computer or something?

[Saffith]

More drawing and more complex drawing will slow it down more, but I wouldn't expect that big a dip just from three drawing functions. Have you tried commenting those lines out to make sure they're the ones responsible?

[Evan20000]

On screens without the drawing, there didn't seem to be any significant issues on Moosh's end. I had another tester try it, and they didn't experience any issues so I'm unsure if it's just Moosh's computer or the script itself is inefficient.

 

For reference, here is the script. http://pastebin.com/qUVnkEq4

 

EDIT: The indentation seems to have gotten messed up going onto pastebin. O_o

[Moosh]

More drawing and more complex drawing will slow it down more, but I wouldn't expect that big a dip just from three drawing functions. Have you tried commenting those lines out to make sure they're the ones responsible?

Removing the draw commands altogether causes ZC to run at its normal speed for my computer which is about 200-240 fps when uncapped. With the script drawing the tile blocks but not scaling or rotating them it runs at 160-180 which is normal for a scripted quest for me. With the scaling and rotating and no other ffc scripts onscreen it runs at 60-80 meaning I basically can't uncap. With Evan's other scripts it runs at 30-50 fps and occasionally jumping back to 60.

[Saffith]

Huh. Yeah, I guess scaling and rotating large tile blocks is just slower than I realized. Unfortunately, that's all done in Allegro, so it probably won't get fixed...

I don't see a lot you can do there, but it would probably help to draw the opaque layer from an offscreen bitmap. That would save one scale per frame, at least. Quad() might be faster, too

[Mero]

Post Removed

Edited by Palpaleos, 29 December 2013 - 03:53 PM.