Animation Issues

[Custerly]

@Snarky, @Crimson Wizard, @eri0o:

I will amass the requested info and files and post here at my first opportunity. Thanks for looking into this.

[Custerly]

@Snarky, @Crimson Wizard, @eri0o:

Well, it seems there were several factors in the animation choppiness you good folks were helping me troubleshoot. I ran through the advice given, and had some interesting findings.

Firstly, I just moved around the mouse to see how the game overall was running. I noticed chopiness there, and after some investigation, I realized that AGS uses a default frame rate limiter of 40 FPS. I find this pretty strange, as most displays (mine included) are 60 hz. I changed the frame limitier to 60 FPS, and noticed a marked improvement in mouse motion clarity and the smoothness of the quick animations used in my dialogue portraits.

The issue was not totally resolved though, as I noticed a very slight stutter on the aforementioned portrait animations. Unexpectedly, this corresponded with a 5ish FPS drop only on the first time the animation ran per game. If I ran the animation again before restarting, it would not effect the frame rate. I tested this by pre-running all game animations on startup, and the frame rate remained clean when running the animations later in the typical gameplay context. This was all in the 4k (overkill, I know) build of the game. I tested again in the 1080p build, and noticed only a 1-2 frame drop during the first animation per game.

Adding to the confusion, for a period of time I noticed that, in the 4k build of the game, running animations for the first time per run would tank the frame rate down to the mid 40s. Testing the same build on subsequent days, I saw the frame rate in the same scenario drop to mid 50s. So I assume that there was some load on my computer that I wasnt aware of at some point, and that probably is what made me notice the frame rate hitches in the first place.

TLDR:
Ultimately, the solution was a combo of increasing frame rate limiter to 60 FPS, dropping the game resolution to 1080p, and my computer seamingly no longer having an unexplained secondary load on it.

A few questions for you guys, if you still have some patience for meL
- Why does AGS default to a 40 FPS limit?
- Why is there a greater frametime impact on the first run of these animations, and is there a way (other than the aforementioned pre-running of animations) to mitigate this?
- Is a 512 mb cache sufficent for 1080p graphics?
- I have been saving the graphics, after editing, via Photoshop 'export as PNG'. Is there a more size/performace optimal way of doing this?

[Crimson Wizard]

Right, AGS has this old problem that it loads sprites only on first demand when they are displayed. Which means that if an animation plays for the first time, then it will be loaded simultaneously. Then the loaded sprites are put into the "cache". If the animation plays again, then the ready sprites are taken from the cache, and displayed momentarily. Actually, since 3.6.1 there's now a second "texture cache" that improves this even further, by spending more video memory.

The cache is limited by settings, and system RAM. Low-res games rarely reach this limit, but games with huge amount of assets, as well as high-res games, will eventually will. When this happens, the engine discards the sprites that were not used longest (it keeps record of that). If the sprite is requested again after, then it will have to be loaded again.

- Why does AGS default to a 40 FPS limit?

Purely historical reasons, I think this is how classic adventure games were run.
I must also note that unfortunately at this point in AGS FPS is both rate of render and rate of logic update. This should not cause much issues with 60 FPS, but may if you like to have higher (or very low) speed of game update for some reason.

- Why is there a greater frametime impact on the first run of these animations, and is there a way (other than the aforementioned pre-running of animations) to mitigate this?

Historically people used various hacks to trigger sprite preload during some "loading" screen. E.g. something like sequentially displaying these sprites on an object behind a opaque gui, or drawing small parts of them into an arbitrary DrawingSurface (the latter hack does not require to display anything).

Since 3.6.1 there's are explicit functions called Game.PrecacheSprite and Game.PrecacheView.

- Is a 512 mb cache sufficent for 1080p graphics?

I guess it may be. But in practice this depends on how many different sprites you display at the same time (or in short term).

There will always be limits, if not for you then on some player's computer. It's better to not push as much as possible in the game, but try to optimize things, especially if it uses high-resolution assets. Keep the resolution to a minimal suitable level. If there are too many sprites then try to reuse them for multiple purposes. Do not make fullscreen animations if only a portion of the screen needs to change, animate only parts that need to change instead, etc. Well, this is a big topic on its own.

- I have been saving the graphics, after editing, via Photoshop 'export as PNG'. Is there a more size/performace optimal way of doing this?

AGS converts imported sprites to its own format, which is basically raw RGBA. But it also compresses them according to the options in General Settings -> Compiler section. In 3.6.0 the choice is "No compression", "RLE" (good for simplistic low-res gfx) and "LZW". Since 3.6.1 there's also "Deflate" which is same compression that PNG uses.

For long fullscreen animations I'd suggest try video instead.

[Custerly]

@Crimson Wizard Thanks for all of your insights! Very informative, as always.