Lix > Lix Main

Stop maps from crashing (OutOfMemoryError)

<< < (5/5)

Colorful Arty:
After playing the last few multiplayer sessions, I've noticed a few maps are prone to crashing peoples' machines. Simon says this is caused by the maps in question being too large, and caused people to have OutOfRAM and/or OutOfVRAM crashes. I think something should be done about this. There are a few options:

1: Lower the maximum size of custom levels. My level "The Corridors of Time" played last session was as large as possible, but with very little terrain. This still crashed, which makes me wonder why people are allowed to make levels that big in the first place. The downsides are this may cause problems with existing maps that are already that large.

2: Make the multiplayer code more efficient spatially-efficient, preventing future crashes. I don't know how easy or feasible this is though.

3: Everyone installs more RAM on their computers. ;P

Forestidia86:

--- Quote from: Colorful Arty on February 14, 2018, 07:23:42 PM ---After playing the last few multiplayer sessions, I've noticed a few maps are prone to crashing peoples' machines. Simon says this is caused by the maps in question being too large, and caused people to have OutOfRAM and/or OutOfVRAM crashes. I think something should be done about this. There are a few options:

1: Lower the maximum size of custom levels. My level "The Corridors of Time" played last session was as large as possible, but with very little terrain. This still crashed, which makes me wonder why people are allowed to make levels that big in the first place. The downsides are this may cause problems with existing maps that are already that large.

2: Make the multiplayer code more efficient spatially-efficient, preventing future crashes. I don't know how easy or feasible this is though.

3: Everyone installs more RAM on their computers. ;P

--- End quote ---

Option 1 sadly seems to be the most realistic in my eyes at the moment, although it would be only a workaround. Improving the code would be of course the best.
I'm not sure if more RAM would help since the game seems to have a memory leak and crashes even if still free RAM is left. Maybe more VRAM would help. Simon has explained what happens here:
The game makes autosavestates of the bitmaps and if not enough VRAM is available it goes into RAM. Whereas VRAM is cleared by the game from time to time, the RAM sadly is not.

Maybe restarting the game before playing a huge map and restarting afterwards could alleviate that.

Simon:
Yeah, this is the nastiest problem in the game.

Solution 1 (limit size) is hackish, but a reasonable workaround because everything else is hard. I have to guess how widespread graphics cards behave with what sizes of image. It's hard and inconsistent. (Forestidia posted this same link.)

Then enforce a max size that doesn't crash anybody's machine. Map size limit is purely client-side; the server relays levels, but doesn't interpret the level file.


--- Quote ---game seems to have a memory leak and crashes even if still free RAM
--- End quote ---

Game is largely garbage-collected (0.9.10 and newer run the GC more often than before), and some parts are reference-counted (these don't seem to leak). The leak comes mostly from the graphics card that swaps to RAM, but doesn't free this RAM before end of application. I call the graphics hardware via Allegro 5 and don't see a way to tell the card to free such swapped RAM.

What maps did crash so far? Infinitus 8p crashed, and Arty's clock map at maximum size crashed.


Solution 2 (efficient storage) is the best, but needs the deepest reworking. The Clones solution split the map into 128x128 chunks, and save only the chunks that change over time.

-- Simon

Simon:
Here are the plans for 0.9.12.

Warn on large maps: On all previews of maps with more than 3 million pixels, I'll print a warning that these maps can crash Lix.

Still allow everybody to play these large maps, nonetheless. You can ignore the warning and press ready for multiplayer, play the map in singleplayer, or load it in the editor. This way, 0.9.12 won't be a downgrade, and it leaves player in control.

Example of large maps where the warning will show:

* IchoTolot's 3-player What Could Possibly Go Wrong at size 1,792 x 1,824 = 3.3 million pixels

* Rubix's 8-player Infinitus at size 2,560 x 1,280 = 3.3 million pixels

* Arty's 8-player Corridors of Time at size 3,200 x 2,000 = 6.4 million pixels (the maximum allowed)
These 3 maps have crashed in the past. If you experience crashes on any other maps, please tell me, and I'll revise in-game warning. These crashes will generate a message box that says either "OutOfMemory: Memory allocation failed" or "OutOfVramException".

I've merely guessed a map size (3 million pixels) and hope that it works as a catch-all. Ideally, we'll find a better solution than such a warning in the long run.

-- Simon

Forestidia86:
The problem is probably related to the weak 32bit garbage collection (cf. here).
The current Win Lix release is 32bit, whereas on Linux it is commonly 64bit since most have 64bit systems.
That would explain why people on Win crash but the ones on Linux not.

A 64bit build should at least lessen RAM usuage, which could maybe solve this problem.
The problem for a 64bit build was in earlier time that Visual Studio was needed for linking (cf. here).

But now the compiler LDC has released a beta that is self-sufficient, that doesn't need Visual Studio. Only the Visual C++ 2015 runtime to run the game could be needed still, but there are quite a few games that install that with it, so it is likely that people have it already.

So there are good chances that in future big maps can be played again.

At the moment there are still quite a few problems open, though.

Navigation

[0] Message Index

[*] Previous page