Mitch Richters, on 16 July 2019 - 02:47 AM, said:
eduke32.exe -j "hrp" -h "duke3d_hrp_polymer.def"
eduke32.exe -j "hrp" -h "duke3d_hrp_polymost.def"
I think from a HRP developer point of view, some kind of automation via an if statement would be desirable, but what I've posted above works in any case.
The DEF hierarchy was expanded to provide this very solution after reviving the Polymost HRP part.
Mitch Richters, on 16 July 2019 - 02:47 AM, said:
I guess most users see a checkbox for "Polymer" and think "Gee, that sounds amazing" and never think about it further.
I once proposed to expand the startup window to have three radio buttons for the renderer: classic, OpenGL Polymost, OpenGL Polymer
Probably after writing the code snippet above. But it didn't happen.
Btw., implementing that "if rendertype" thingy would deny users to run the Polymer renderer/Polymost HRP combo, which can be a performance compromise for some hardware setups.
Phredreeke, on 16 July 2019 - 02:59 AM, said:
The problem is the user can switch between Polymost and Polymer at will. Should eduke32 have to force reload def files upon switching renderers?
IIRC Hendricks266 once thought about that, indeed. Not worth the effort.
Phredreeke, on 16 July 2019 - 02:59 AM, said:
Would IMO be better extending the texture and model commands to allow defining an alternative texture for Polymost (I haven't looked into the specifics of the Polymost override pack so I may be overlooking something though)
Not worth
my effort. The OVR Pack is as simple as it gets by loading a different DEF file hierarchy from toplevel.