Bad Performance with Self-Compiled Acwin.exe

Started by Ali, Wed 05/06/2013 18:03:21

Previous topic - Next topic

JJS

I guess that is my fault. For the PSP I decreased the default sprite cache size from 20 MB to 5 MB. This could cause a reloading of sprites for high-res games. https://github.com/adventuregamestudio/ags/blob/master/Common/ac/spritecache.cpp#L52
Ask me about AGS on PSP, Android and iOS! Source, Daily builds

Crimson Wizard

#21
E: JJS posted faster, but my post carries a possible temporary solution for the user. ;)

Okay, I got it. It is a bit complicated, for, I suppose, there are few factors that play role here.

First of all, the default cache size was reduced by JJS very long ago, exclusively for PSP build. But it appears he did not make any condition in the code, so all the builds now use that.
I wonder though why the game does not take proper value from config file (20 MB). Probably it treats it as "default option" and so does not change initial value.
At last, it might be that new engine reads files a bit slower, at least it summs up if files are being read often. I am going to look at this too, but this is almost irrelevant to this issue.

By increasing the cache size in winsetup (I set 100 MB) I was able to fix the issue! Game runs significantly faster.

EE: I think the real solution would be to change the way this option is initialized from config. We may leave default size to 5 MB, but make it so that it will read Windows-default 20 MB from cfg properly.

Ali

#22
Yes, changing the cache back to 20mb is a massive improvement. However, it still runs distinctly less well than it does when compiled with 3.2.1's engine. To get passable performance I also have to increase the cache to 100mb, and it's still jerky in places. (I sent Crimson Wizard another PM with examples).

So I have a couple of questions:

Are there any computers around these days for which 100mb(or more) caches will be a problem?
Is it possible for me to address other factors which impact on the engine's performance?

Crimson Wizard

This is not related to sprite cache at all, 20 MB should be enough to run the game. I keep looking.

Crimson Wizard

#24
Ali, I copied part of development branch to the "master". Now the master branch should run as well as the build I sent you yesterday.
Do not forget about sprite cache though, we still don't have that fixed, which means you have to set something different from default option in winsetup (like 50 or 100 MB).

In PM you mentioned there's still "tiny lags" during some big animation. What animation is that, can you point out where in game it takes place?

Speaking on perfomance in general, I must say that original 3.2.1 engine runs on top-limit with your game too. It causes about 15-17% load on my processor, which has 4 virtual cores (2 physical ones), meaning it takes about most of 1 virtual core (25%) to work. Since AGS runs on one core only, this may cause problems if you increase the amount of things happening simultaneously.

Ali

Thanks! I assumed that changing the line JSS altered in spritecache.cpp would sort out the 5mb issue. But perhaps 100 is a better defailt, since it's full of all graphics and stuff... The tiny lags for me were when Bloodbeard (the ghost) appears when you interact with the mop.

I suppose I'd better make things like parallax and vignetting optional, to avoid bad performance on slower machines. Thanks for the tip!

I'll test out the new source as soon as I can!

Crimson Wizard

Quote from: Ali on Wed 12/06/2013 23:53:03
I assumed that changing the line JSS altered in spritecache.cpp would sort out the 5mb issue. But perhaps 100 is a better defailt, since it's full of all graphics and stuff...
It may sort the issue, I was just warning you that the git sources do not have it fixed.
Setting 100 MB does not change much, I was telling to change the option to make it write something to config, because default (20 mb) does not write anything and the engine will keep its own default (which is 5 MB in Git sources).
Also, this setting only defines size of sprite kept in memory, but it does not define when those sprites are loaded. It looks like the sprites are only loaded to memory when they are first used. For example, when Bloodbeard appears, his sprites are loaded from the file no matter how large sprite cache is.

Ali

So if the situation got desperate I could cheat with big animations and run them in the background, so that they were cached in time to be run?

Calin Leafshade

We should maybe consider a View.Preload function of some kind since I have seen this issue a few times with high res games.

Crimson Wizard

I believe that they did it in "Anna Quest (vol 1)". When you start the game it shows "preloading animations" progress.
I don't know how they did it (this may be examined under debugger though to know which script functions are called), but I believe all you need to do is to make some simple not- time costly operation over sprites (without drawing them on screen, of course). This will force engine to preload them.

Perhaps, a good idea would be to do this on each room load, or between distinctive game sections.

Other than that, I'll continue trying to improve certain functionality to see if it would be possible to restore performance even closer to 3.2.1.

PS. I probably was too fast in doing that merge... other than improvement it contained also experimental stuff made exclusively in anticipation of migrating to Allegro 5, but since the latter is not happening in nearest future, it might add little extra overhead. I will revise latest changes and probably redo them in a more simple way.

Crimson Wizard

It is difficult to be completely sure, because I am getting different results on processor load every time I run, but I think this one is slightly faster:

http://www.mediafire.com/download/6pf7fta1ezax5wf/acwin_gfx_revised.exe

I will update in git soon.

SMF spam blocked by CleanTalk