Improve development of higher resolution games in AGS

[ericoporto]

Recently, many different developers have looked into AGS with the expectation of using it for developing high resolution games - 1600x900 and 1920x1080 games. At the same time, they have reported different problems when using AGS regarding performance, either sprite loading is slow, or they hit memory limits, or they get stuttering animation.

At the same time, it's apparent AGS developers lacks a minimal game, even better if the project is open sourced, that uses high resolution assets where all these reported problems reproduce so profiling and testing can help trace bottlenecks. Note that this game project will be very big in size because of not only the assets, but also spritecache.

This issue is for gathering these reports so there can be discussion around this goal and linking related issues that already exist can be linked here and smaller tasks that enable reaching the goal of using AGS with high resolution assets and making high resolution games.

This issue is not about fundamental changes in how AGS works (no discussion on skeletal animation or vectorial games). Also issues with AGS Scripting or other possible performance issues, not related to these specific high resolution assets should not go here either.

forum posts: 1, 2, 3, 4, 5, 6.

Editor side:

• #702 . Editor crashes when importing a large number of sprites

Engine side:

• #969 . Persistent "render data" for each drawable object in game

UPDATE:

This issue was written a long time ago, these are some changes that happened in the meanwhile:

• Editor can now recreate the acsprset.spr file from sources, which means you don't need to push it to your git remote Editor: feature recreating full spritefile from sources #1594
• Additional sprite compression based on palette is in, and LZW compression too Sprite file supports storing 16/32-bit sprites as indexed images with palette #1461
• Hardware Accelerated GUIs has been added Render GUI Controls as separate textures #1393
• Buffered streams for reading resources has been added too AGS3 Buffered streams #756

[ghost]

only a small note -
#702 will probably become obsolete, if we remake Editor to get sprites from disk directly, and only build sprite file as a part of assembling the game.
#969 is probably not much related, since it's more about data organization. The perfomance benefit from this will be negligible in the big picture.

[ghost]

Only to outline basic directions (!!), following seem to be three main problems when dealing with high-res (and generally "resource-heavy") games:

• Disk space.
• Runtime memory.
• Runtime speed.

---

In regards to disk space, improving compression seem to be a natural choice, but at the same time it increases the speed problem, because for every compression there has to be a decompression (duh), unless we are talking about lossy compressions (but then this is something that AGS should not probably do on its own, and let user decide before importing an item into a project).
Existing proposals: #983

An alternate approach could be in finding ways of reusing assets and avoiding duplicate data where possible. This involves giving game developer both tips and instruments of doing so (I am just noting this as an abstract idea, because I don't have a practical example ready... ok, maybe something like #996, but in larger scale).

---

Regarding runtime memory, the primary idea is to keep as little in memory at once as convenient, but at the same time this has to be balanced with ability to load it up again when needed.
Creating runtime caches may reduce a need to keep alot of things in memory (e.g. see my old proposal here: #731), which may be also important if the game generates lots of data dynamically. Of course such caches increase disk space requirements... And, of course, again we should provide some instructions for game developers on efficient handling of dynamic data (like deleting these dynamic sprites they use only in 1 room when they are no longer necessary). Or find ways to enforce this practice...

There's an interesting idea discussed in the past on forums, where developer makes a graph for the game, defining connected areas, and when player moves around the game, the engine loads up data from neighbour areas and unloads/saves in temp files what has been left behind. This may not be a big priority here, but perhaps something to consider after we have a proper resource streaming system in the engine.

Again, there has to be no unnecessary duplicates. For example, right now the raw sprites (bitmaps) are shared between objects, but DDBs (textures) converted from a sprite are not, which is pretty silly and suboptimal (a ticket is a due).

---

For runtime speed, the solutions are in
a) improving i/o operations times;
b) decreasing number of steps between resources on disk and final form of said resources;
c) doing most load & preparations in background threads;
d) being able to prepare resources preliminarily, either automatically by analysing the game, or letting game developer to set up certain rules, for example, telling which items should be prepared for particular room in its script.
e) optimize rendering and any graphic updates where feasible.

NOTE: I heard that @sonneveld was experimenting with buffered input streams and threaded resource loading, so probably there's already some work being done on items from the above list.

[ericoporto]

Regarding disk space, my main concern is the spritecache size for the developer making the game and the fact that he must store that in his/her source version control system, because it can't be rebuilt from the source images and an index in the Game.agf alone.

[rofl0r]

the spritecache size for the developer making the game and the fact that he must store that in his/her source version control system

agsutils' agsprite tool can build acsprset.spr and sprindex.dat from input files in the FS

[ghost]

Regarding disk space, my main concern is the spritecache size for the developer making the game and the fact that he must store that in his/her source version control system, because it can't be rebuilt from the source images and an index in the Game.agf alone.

Rebuilding sprite cache was in plans for 3.5.0 development, but we did not fully implement this because of few internal workflow problems in the Editor. Eventually, according to @morganwillcock's plans, sprite file will be removed from the project sources and only be made as an output for game packaging. That should solve this problem.

[ericoporto]

Hey, since many pain points have since been solved, and it's hard to act without specifics, I am closing this one.