Code Optimization

[C-Dawg]

I'm getting to the point where Zodiac is starting to creak under the strain of so many scripts running at once, even on my P3 3ghz. Here's the situation that seems to be causing the problem:

10 or so FFCs are running a script that, each frame, runs through 10 or so if statements to determine what sort of creature it's supposed to be acting as. Then another 10 - 20 ifs depending on what it finds, and writing to the FFC's X, Y, data, and the ghosted enemy's X and Y.

At the same time, another script is checking, for every enemy on the screen, whether it is within eight pixels of a custom weapon, or on a line with certain beam-based weapons.

I can get slowdown in two situations:

1. Where there are upwards of 20ish enemies on the screen at once; and
2. Where I use 20ish or more FFCs running the custom SHMUP script mentioned above.

I'm a bare amateur when it comes to coding. I could optimize my code, but it would be harder to read, and harder for me to add to over time by just adding another if statement to make a new enemy or item. I could split my scripts to minimize problems but I'd lose generality. I'm sure people smarter than me have dealt with these sorts of problems before, and have some solutions for them.

Any suggestions on what to do? Or any compiler optimizations in the pipe that will correct for my ham-handed programming?

[DarkDragon]

There's one optimization I can do at my end to speed up accessing enemy pointer, but I'm not sure how much of a difference it will make.

Without looking at the code, here are a few generalities:

- Avoid writing to Link->Item[] more than necessary.
- Drawing primitives are slow by nature.
- Dereferencing invalid NPC pointers is slow, because the interpreter then performs file IO to write an error message to allegro.log. Use isValidNPC() to avoid this problem. (NOTE: note all "invalid NPC" messages are your fault; I fixed a bug for the next beta that solves a problem where the interpreter refuses to access the first NPC on the screen.)
- Use "else if" instead of "if" wherever possible to avoid unnecessary checks.
- The ZScript compiler does not perform any optimizations. You can improve performance using standard hand-optimization tricks; for example, instead of reading a value that won't change, such as Link->X, in each pass through a for() loop (that doesn't contain a Waitframe()), instead read it once outside the loop, store it in a variable, and use that variable in the loop.

[Gleeok]

There's one optimization I can do at my end to speed up accessing enemy pointer, but I'm not sure how much of a difference it will make.



Please, please, please!!!!!


I have had a migrane trying to optimize and re-optimize enemy loop checks. I've been getting slowdown from enemy pointers for awhile, even without actually doing anything to access data from them. I made a short test script and stuck 150 shooters on a screen, and the worst of it was like 20 fps. Through some extra variables I was able to get this to 40 fps, and I have a now standard "lag removal" system that I encorporate into all enemy loops, which upped it again to 45-50 fps. Anything you can do to speed up enemy pointers will be much appreciated. :)






And C-, Next demo you put out I'd be happy to add the changes I made, then ship it back to you. If I noticed a 20 fps increase, maybe it will run perfect on your machine?

[C-Dawg]

Knock yourself out. I don't use for loops, though. Usually I just run a while loop that checks the enemies.