Handling Shareware VS Registered

[erysdren]

How should we handle the split of shareware vs registered? In the current codebase, there's dozens of #ifdef blocks that separate functionality between the registered and shareware builds. In my outlook, these separations should be removed and should be controlled some other way.

It's my understanding that the shareware levels will run fine in the registered build, but of course the reverse is not true. I think we'd be best served using some heuristics to determine if it's a registered or shareware session. I believe this would mainly come from looking for the registered WAD and level files, if they aren't present (but the shareware files are) then it must be a shareware session. Then we can enact some of these changes. Quake sourceports have it easy, they can just look for the pak1.pak data file (specifically the pop.lmp file inside of it) and do the necessary mode-switching based on that.

@fabiangreffrath Thoughts?

[fabiangreffrath]

Strictly speaking, we don't have to emulate the behavior of the shareware executable if the registered executable is able to play the entire shareware episode just as well.

Things are much more complicated in Wolf3d source ports, because these have pendants of #ifdef SHAREWARE in the middle of enums, so symbols get different meanings between builds. This doesn't seem to be the case here, but I haven't looked any deeper into it yet.

[erysdren]

The hardest part would be controlling what assets get precached in shareware vs registered - the shareware HUNTBGIN.WAD has a subset of the final game's assets, so some of the precache routines will need to be adjusted. I've been playing with a patch, but I have nothing concrete yet.