Skip to content

Lift savebuffer limits

Hanicef requested to merge Hanicef/SRB2:lift-savebuffer-limits into next

SRB2 had an upper limit to how much data could be saved in a savebuffer, which is normally fine on savegames where the buffer normally doesn't fluctuate much, but can be a huge problem in netcode sync due to it containing various dynamic elements including mobjs, Lua fields and FOF states, which could easily smash the buffer and crash the game.

For some history, DOOM also had this limit, due to how it's allocator is unable to deallocate a single block of data and thus requiring the engine to have a fixed-size buffer for save files. However, source ports have almost universally lifted this limit (and that includes even pure vanilla source ports such as Chocolate Doom) due to it's serious consequences when those limits are hit. So the fact that SRB2 is still carrying around this limit actually boggles my mind, especially since other limits such as the infamous visplane limit have been lifted in the engine already.

All in all, we should've gotten rid of this a long time ago, but since nobody has done it yet, I'll do it now. I also went ahead and removed the save_p global and passed it via arguments instead to get rid of some technical debt.

Merge request reports

Loading