search

fabiangreffrath / taradino

SDL2 port of Rise of the Triad
GNU General Public License v2.0
35 stars 9 forks source link

Handling Shareware VS Registered #81

Open erysdren opened 3 months ago

erysdren commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.