Major concerns about performances of MZ

[topwolf]

Hi everyone,

I was using VX Ace before moving to MZ once it came out. I did transfert my game from VX Ace to MZ, using and script and a lot of patience (my game has a lot of advanced script, which doesn't translate while running the converting script). So I roughl spent close to 100 hours just getting back to where I was in VX in MZ.

AND then BOOOOMMMMMM. My game, which was running rather smoothly now takes at least 10 to 20 more time to load, which makes it totally unplayable. I really need help there! I also tried on a much better computer, and I still have the same issue. What can I do to fix this?

For your information, my game is not a RPG, but a strategy turn based game. In order to do this, there is a lot of loops into a lot of commons events running in sequences. So I need to process the informations much more quickly than a regular rpg with text and basic stuff. Yet, this was working fine before in VX(about 2-3 seconds per opponent / turn, now it's close to 1 minut per opponent).

Thank you for all the support you can provide me. I was really expecting a lot from this version and I am really disapointed right now. I have spent so much time and money in this game, for now facing a wall!

 

[katywings]

Actually interesting :3, just out if my own curiousity: did you try to debug / benchmark it?

 

[topwolf]

No, I’m not sure what to do. Can you help?

 

[TheoAllen]

Before you jump the gun and convert your whole project to MZ, does the vanilla MZ (as in, a fresh new project) also lags?

 

[Zeriab]

F12 brings up the dev tools when testplaying the game.
One of the tabs is for the profiler. This allows you to record a bit of you playing your game. It will then analyze the recording and tell you where it spend its time. Super valuable information when trying to optimize your game.

 

[topwolf]

Before you jump the gun and convert your whole project to MZ, does the vanilla MZ (as in, a fresh new project) also lags?

It is all converted already! Now I need to get back to acceptable performances on mz....

 

[topwolf]

I've ran a test in my game, while it was only scripting. Yet, I've got 43 seconds of idle time. Is there any way to get rid of this? I still thinks 17 seconds for scripting is a lot, but it could be "acceptable".
thanks

F12 brings up the dev tools when testplaying the game.
One of the tabs is for the profiler. This allows you to record a bit of you playing your game. It will then analyze the recording and tell you where it spend its time. Super valuable information when trying to optimize your game.

 

[TheoAllen]

It is all converted already! Now I need to get back to acceptable performances on mz....

I was asking about the vanilla MZ. Not your converted project.

 

[The Row]

I might be wrong, but isn't "idle" the game doing nothing, as in no-load? Meaning that durring that time the engine should work by doing nothing, no lag, as nothing requires any load.

As I read the diagram, you made a test that lasted, 1.1 minutes, or about 64 seconds.
17seconds of which scripts were running
0.6sec which was dedicated to loading graphics and about as long to render said graphics.
2,7seconds were the system loading/handlings things, and the rest;
43seconds were when the engine/game didn't need to load anything/work on anything.
Durring those 43 seconds you shouldn't have any lag, unless the device you ran the game on was too "weak" to run it.

In rounded number, you have scripts running about 25% of the time the game was on. That's quite a lot.

I don't know about MZ, since the code under the hood has been change quite a bit according to what I have read, but MV, had a problem of running parallel events, or more than one at the same time at the very least.
I haven't seen the scripts you are running, but if possible, try to avoid scripts that run none-stop, instead just call them when they are needed, run them once, and then leave them be. Avoid loops as much as possible, or have them run a set number of times. (As in try to avoid things like <while( i!=100, i=Random(100)){})

But I don't know I am not a programmer, and not an expert, but I thought I would give my 2cents.
Perhaps it would help, perhaps not, and as TheoAllen said, try running a fresh project, just to see the load there. You need something to compare your game to, not just your old vxace game but another MZ project aswell.

 

[topwolf]

I might be wrong, but isn't "idle" the game doing nothing, as in no-load? Meaning that durring that time the engine should work by doing nothing, no lag, as nothing requires any load.

As I read the diagram, you made a test that lasted, 1.1 minutes, or about 64 seconds.
17seconds of which scripts were running
0.6sec which was dedicated to loading graphics and about as long to render said graphics.
2,7seconds were the system loading/handlings things, and the rest;
43seconds were when the engine/game didn't need to load anything/work on anything.
Durring those 43 seconds you shouldn't have any lag, unless the device you ran the game on was too "weak" to run it.

In rounded number, you have scripts running about 25% of the time the game was on. That's quite a lot.

I don't know about MZ, since the code under the hood has been change quite a bit according to what I have read, but MV, had a problem of running parallel events, or more than one at the same time at the very least.
I haven't seen the scripts you are running, but if possible, try to avoid scripts that run none-stop, instead just call them when they are needed, run them once, and then leave them be. Avoid loops as much as possible, or have them run a set number of times. (As in try to avoid things like <while( i!=100, i=Random(100)){})

But I don't know I am not a programmer, and not an expert, but I thought I would give my 2cents.
Perhaps it would help, perhaps not, and as TheoAllen said, try running a fresh project, just to see the load there. You need something to compare your game to, not just your old vxace game but another MZ project aswell.

The thing is: I don’t feel any lag. All those events were scripts running in autorun. And I started the test at beginning of the auto run process. So I was expecting 60 seconds of scripting, or close to, as the game was never on idle during that time. So I don’t know why I got this result. I never feel lag anywhere in my game, it just takes forever to load everything. Even a simple menu where I go fetch 60 data’s takes time to load.
I’ll try a new project with just a few of my game process to run and see if there’s any change.

 

[Zeriab]

Ah yeah, those values can give an indicator, but they don't tell you that much.
Instead you'd want to dig down into the individual frames.

Here is an example where I clicked on a task for a 18.6 ms long frame. Divide 1000 with the task length to get an estimate of the FPS (all frames taking 18.6ms would lead to having around 54 FPS)


You for example click on the Bottom-Up view and sort by Self Time. This can give you an idea of particularly hot methods.
This is a test project where I have 500 semitransparent events running around at max frequency. In this particular frame I clicked with my mouse. Notice that the single method call to Game_Character.findDirectionTo takes up 54% of the time. This method is called when the player clicks on a tile with the mouse and it makes a lot of passability checks.
In this particular case I saw an unoptimized piece of code (Game_Map.eventsXyNt) and decided to see how it faired when stress test it by creating 500 events. It took only 10ms in this extreme case so I my conclusion was that it was fine for normal use and not worth spending effort on improving.

I had a particular goal, but you can also use this tool for discovery. Use it for guiding your research.

Another interesting thing I noticed is that the garbage collector can take up a significant amount of time. Near the end of the recording there is this segment:


I wonder why that happened and what can be done to mitigate it. Hmm... Perhaps pooling a lot of resources could help.

*hugs*
- Zeriab

 

[topwolf]

That look interesting and I will definitely look at it, and see the results! Thanks for your hard work there!

And for your information, I’ve been able to reduce delays by 95% by rewriting my events scripts and using stronger JS codes. As example, using array.sort () rather than trying to sort data’s with conditional branch did reduce time for this specific task by 99%. Using « for » rather than loops or label / jump did reduce time for those process by over 95% too!
As I want it to be as fluent as it can be, I m quite sure your diagnosis tools will be a great combine!