FEATURE: Deal with the low memory limits.

[dsvensson]

Modern maps may need to start ezquake with -mem 256 rather than the default. While this might seem trivial I spent an hour helping out two players with adding that command line parameter via voice. One Windows and one MacOS user. It may sound odd that people don't know what command line parameters are, but that's just the way it is apparently.

The simple solution would be to just increase the limit like other engines already have. Another solution might perhaps be some 2x resize or some other resize strategy if the map hits the limit until it loads, and let the OS oom-killer slay the process if it gets out of hand.

If I'm interpreting the FTE source code correctly it looks like -mem was removed in 2013 in favor of dynamic allocation as needed.

[Calinou]

Defaulting to -mem 256 should work fine on machines with 4 GB of RAM or more (maybe 2 GB if you're diligent with how your OS uses the rest of the RAM). This could be a reasonable solution for now.

[inf1niti]

IME, it's still possible to get crashes even with a higher heapsize allocation - but this has only happened to me while loading multiple large maps, and when warping between them throughout the course of a night of games. So there may also be some issues around bspfile cleanup between map loads.

It's also worth noting that any memory increases would need to be implemented on the MVDSV side as well.

Beyond global memory allocation, there are a number of issues IME with unexpectedly small limits, or strange bugs when trying to render more complex maps:

• textures larger than 640*480 throw a sys_error (many common SP wads these days contain 1024x1024 textures).
• hard-coded limits are present in bspfile.h, client.h, and common.h headers which cause various load problems if any of these limits are exceeded (even if they fall within the limits imposed by the bsp29 format, and are properly rendered in other engines). Is it possible to utilize a dynamic allocation strategy for these instead?
• a number of memory checks were implemented to resolve memory corruption bugs flagged in BUG: Memory corruption bugs in map parser #615, which impose integrity checks on bsp29/29a map formats. If a map fails any of these checks, they will not load. But the maps I've seen flag these errors load and run just fine in other engines...
• maps with large/complex lightmaps, or with variable texture scales/lmscales can cause strange lightmap issues in ezquake which are not present in other engines.

Obviously, ezQuake is a great engine and these modern maps aren't the main use case we see from day-to-day, but it would be nice if we were able to align the engine's loading capabilities more closely to the other quake engines in use these days, so we can benefit from improved performance & more details in our maps. 👍

[tcsabina]

@dsvensson
Does #674 fix all mentioned issues here? Can we close this?

[dsvensson]

Lets, better to add specific issues for what's left @inf1niti