FPS and Frame Drops

[CraneSoft]

Im on VXACE and recently I have noticed some frame skips under specific conditions when playtesting and would like some assistance on the matter. For starters, the game runs at 60fps normally on any map (even large ones) by default - no issue so far, the problem then arises when I'm trying to display GUIs and cosmetics in the form of pictures - up to 25 of them can be on the screen at once and I am also managing the updates with exactly 1 common event under parallel process, which updates one of the picture every 2-5 seconds using a wait command with varying intervals.

When the parallel process is running along with the 25 or so pictures displaying, the FPS then shifts randomly within 40-59 range, the maps with more events around 40-45 while others in the 50~ range, the actual size of the map doesn't seem to matter as it seems to be tied to event amounts (and to clear things out, NONE of the maps in question have ANY parallel processes on their own) along with the number of pictures on the screen. Naturally this caused quite some noticeable "frame skips" on the more crowded maps, but even on fresh empty maps the FPS fails to reach 60 anymore. The same thing happens during a battle where it also stayed in the 40-45 range.

Then I test it on a fresh project under the same conditions - and the FPS drops the same way - however triggering just the parallel common event alone (without the GUI pictures) themselves would not cause the FPS to drop. From the observation it seems like the abundance of picture use might seem to be the culprit behind the lags (Ruby limitation?). Is there anyone who had come across the same issue and is there any workaround for this besides reducing picture use? Any advice is much appreciated!

 

[Heirukichi]

The problem with lag is real and it depends on how the engine handles pictures, events and parallel process. As a general rule I would not recommend using that many pictures at once. Rather than doing that it is much better to use a script to handle the GUI, not because ruby itself is limited but because the way the engine handles pictures is sub-optimal when using it to design a GUI.

The number of events, on the other hand, can increase the number of operations per second a lot, increasing lag and leading to a small (or big, depending on how many you have) drop in frame rate. To solve that you can use an anti-lag script. There are many anti-lag scripts for Ace, you can check the script list for them. I know for sure Theo has one and Victor too, I do not know if there are any other ones around, but since you only need one of them, knowing two of them is already more than enough.

 

[Andar]

yes and no.
pictures can take a lot of resources and that can affect lag, but most probaby the cause is the wrong waits in your parallel process.

if you have too few waitframes, then the parallel process is being worked on more often than neccessary and this creates true lag.
if you have too many waitframes, then the parallel process needs to wait on its loops before processing. This looks like lag to the player, but it is not - it's just excessive waits.

and unfortunately the correct number of waits can only be experimented and guessed on - and it will change even depending on how many picture commands are in a loop. So the fact that it doesn't lag without the pictures does NOT automatically mean that it's the pictures (or the pictures alone) that is responsible for the lag.

That said, please make the following test to check for how much the pictures contribute:
make copies of all the pictures displayed in one moment into a temporary folder. do not copy pictures that are not displayed at the same time.
convert all those pictures into BMP in that folder
check how large the folder is now

BMPs have no compression, and that means that the BMP-filesize is what the pictures need in RAM (the filesize of PNGs is compressed and only shows the requirements for HDD-space).
If the sum of the pictures now goes beyond about 1 GB in space then yes, that can drain your computers RAM.
If that sum is lower for the pictures of one screen, then it doesn't really matter - the same is if there are pictures that will not be used at the same time because that doesn't require all pictures to use RAM at the same moment.

 

[Heirukichi]

if you have too few waitframes, then the parallel process is being worked on more often than neccessary and this creates true lag.
if you have too many waitframes, then the parallel process needs to wait on its loops before processing. This looks like lag to the player, but it is not - it's just excessive waits.

This is absolutely true. As a matter of fact, the main reason why I recommend using a script is because GUI scripts often use methods to determine if the GUI needs a refresh or not. Without that you are refreshing your GUI every time the parallel process runs.

The excessive wait could still be avoided by triggering a switch when the GUI has to be refreshed and then turning it off. Doing it this way means your parallel process event only runs the calculation part (the one to check if the GUI has to be refreshed) and does not re-draw everything each frame it is called, effectively avoiding unnecessary operations.

One way to do is to have a parallel process event check if the GUI has to be refreshed and then call a different common event (when necessary) that only updates the GUI. The common event to update the GUI should not run on its own. Its trigger should be set to "none". If you do not want to do it this way you can have everything in the same common event, as long as it does not execute the refresh part each frame. It is less efficient than separating it, but it still works.

 

[CraneSoft]

The parallel process event itself is an eye-blinking animation that needs to be run every few seconds. (with the actual pause between blinks are wait commands in the common event itself)
As for the wait commands sadly to say the lags still occur (perhaps to a slightly lesser extent) without the parallel process running when the pictures are present, it does have some amount of conditional checks and a lot of minor wait commands however to the its nature - so I removed everything but one single 60 frame wait command in the parallel process but unfortunately saw no noticeable difference.
For the testing, the total size does not exceed 50 MB after conversion as they are very small cosmetic parts to begin with.

 

[Andar]

in that case your lag is entirely created by what you're commanding inside your parallel process.
and to help you there we need to see screenshots of your event with all of its settings and the exact number of waits and where they're placed.

 

[CraneSoft]

The common event in question there are over 200 picture commands with equal amount of 3 frame wait commands between each of them separated within nested conditional checks so screenshoting is going to be pain as it is now and I don't see how a parallel process that doesn't run is responsible for creating the lag, in any case I'd do a bit more tests for now.

 

[TheoAllen]

If your parallel process include a variable change, it also contributes to the lag, especially in the map with many events even though they are not directly connected. Every variable/switch changes WILL refresh all the events in the map. If you do it in the parallel process, it will also refresh all the events depends on how frequent the variable is changed.

 

[Engr. Adiktuzmiko]

Showing 25 pictures aside from the stuff that the game draws will surely contribute to a lot of lag especially due to the processing done by the game on these pictures... If optimizing everything especially the parallel process still dont fix the frame drops, its time to start thinking how to reduce the amount of images that you are showing.

 

[gstv87]

GUI images should be handled by the core engine, and a dedicated GUI object, not screen pictures.