[mjr4077au]

I wanted to make shortcuts for the HRP that load either the Polymost or Polymer DEF file and set the renderer appropriately, but I'm unable to pass parameters to set the renderer.

Two things that could be done. If you can disable the setup window with "-nosetup", every option on it should be available from the command line (perhaps, -polymer 0 & -polymer 1 etc). The other is doing something Quake-style with "+set setrendermode 3" or "+set setrendermode 4".

I can see Hendricks266 has talked about something similar to the latter as far back as 2009: https://forums.3drea...7&postcount=180

Quote

Rather than that, how about a command switch that will execute console commands, that could potentially be used for this? Like:

Quote

eduke32 -console "set r_texcache 0"

I can work around this by keeping separate config files and passing them in each shortcut, but it's a bit clunky and if I change a keybinding, it's not a global change, etc. Would it be possible to expose this functionality?

[Hendricks266]

The closest thing currently exposed would be autoexec.cfg files.

[mjr4077au]

Hendricks266, on 16 July 2019 - 02:40 AM, said:

The closest thing currently exposed would be autoexec.cfg files.

I could probably use that if I wrote a script to rename a polymost.cfg/polymer.cfg file to autoexec.cfg at runtime, but it's a bit dicky.

Obviously the lowest of the low priorities given it's been ~10 years and it hasn't been included, but would some kind of ability to pass console commands at runtime be a significant thing to implement? I don't understand the complexities it might involve to code that so please forgive my ignorance.

[Kyanos]

Thinking outside the box, try making two sub directories with an autoexec.cfg in them one for each polymer and polymost. Use the command line argument -j to add the right directory to the path for what renderer you want to use. This way your eduke32.cfg stays common.

[mjr4077au]

Photonic, on 16 July 2019 - 01:58 PM, said:

Thinking outside the box, try making two sub directories with an autoexec.cfg in them one for each polymer and polymost. Use the command line argument -j to add the right directory to the path for what renderer you want to use. This way your eduke32.cfg stays common.

I got pretty excited reading this. I tried it, and yes it would work well (still a bit dicky but eh), however EDuke32 terminates reading the autoexec file when it has 'setrendermode "3" or "4"' for each respective autoexec.cfg. Passing something like 'r_showfps "1"' works fine. I guess it's because the renderer setting isn't in settings.cfg, but in eduke32.cfg?

Quote

EDuke32 r7800
Built Jul 16 2019 02:43:05, GCC 7.2.0, 64-bit
Using D:/Program Files (x86)/Steam/steamapps/common/Duke Nukem 3D/gameroot/ for game data
Using D:/Program Files (x86)/Steam/steamapps/common/Duke Nukem 3D/gameroot/addons/dc/ for game data
Using D:/Program Files (x86)/Steam/steamapps/common/Duke Nukem 3D/gameroot/addons/nw/ for game data
Using D:/Program Files (x86)/Steam/steamapps/common/Duke Nukem 3D/gameroot/addons/vacation/ for game data
Application parameters: -j autoexec/setrendermode_polymost -nosetup
Using D:/Full Games/Duke Nukem 3D/eduke32_win64/ for game data
Using autoexec/setrendermode_polymost/ for game data
Running on Windows 10 (build 10.0.17763)
Initializing SDL 2.0.8
Searching for game data...
Using "DUKE3D.GRP" as main game data file.
Compiling: GAME.CON (188911 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45658 bytes)
Compiled 168008 bytes in 25ms
Initialized 96.0M cache
RTS file "DUKE.RTS" loaded
Initializing OSD...
0 joystick(s) found
Executing "settings.cfg"
Executing "autoexec.cfg"

Damn, man... so close to success!

[Phredreeke]

I think eduke32 requires you to set up a 32-bit video mode before it lets you set Polymost or Polymer in autoexec.cfg

[Forge]

I have 2 shortcuts in my HRP game directory, one for polymer, one for polymost & each with their own commandline parameters to use specific def files
-hduke3d_hrp.def
-hduke3d_hrp2.def



duke3d_hrp.def is:

// Extra additions to the game - High Resolution Pack

//if polymost then
include duke3d_hrp_polymost.def
//else
// include duke3d_hrp_polymer.def
//endif




duke3d_hrp2.def is:

// Extra additions to the game - High Resolution Pack

//if polymost then
// include duke3d_hrp_polymost.def
//else
include duke3d_hrp_polymer.def
//endif



All the hrp & def files are in the svn

these will select the proper HRP to use, but you still have to manually set the render mode & check the polymer box.
If you want to have them pre-set, then you'll need to make specific cfg files to do that & ad the -cfg[filename.cfg] commandline to the shortcut

[mjr4077au]

Phredreeke, on 16 July 2019 - 03:19 PM, said:

I think eduke32 requires you to set up a 32-bit video mode before it lets you set Polymost or Polymer in autoexec.cfg

My main eduke32.cfg already has that set, so should be good?

[Screen Setup]
Polymer = 0
ScreenBPP = 32
ScreenHeight = 2160
ScreenMode = 1
ScreenWidth = 3840

Forge, on 16 July 2019 - 03:47 PM, said:

I have 2 shortcuts in my HRP game directory, one for polymer, one for polymost & each with their own commandline parameters to use specific def files-hduke3d_hrp.def-hduke3d_hrp2.defduke3d_hrp.def is:// Extra additions to the game - High Resolution Pack//if polymost then include duke3d_hrp_polymost.def//else// include duke3d_hrp_polymer.def//endifduke3d_hrp2.def is:// Extra additions to the game - High Resolution Pack//if polymost then// include duke3d_hrp_polymost.def//else include duke3d_hrp_polymer.def//endifAll the hrp & def files are in the svnthese will select the proper HRP to use, but you still have to manually set the render mode & check the polymer box.If you want to have them pre-set, then you'll need to make specific cfg files to do that & ad the -cfg[filename.cfg] commandline to the shortcut

That's effectively what I'm doing now with my shortcuts:

"D:\Full Games\Duke Nukem 3D\eduke32_win64\eduke32.exe" -j "hrp" -h "duke3d_hrp_polymer.def" -nosetup -usecwd
"D:\Full Games\Duke Nukem 3D\eduke32_win64\eduke32.exe" -j "hrp" -h "duke3d_hrp_polymost.def" -nosetup -usecwd

I'm just trying to find a way to ensure the renderer is set appropriately when double clicking each shortcut. The autoexec.cfg file in subdirectories was looking beautiful, but failed during practice as EDuke32 just terminates after parsing the autoexec.cfg file.

My preference would be to always use Polymer as I don't have many performance issues with it and I think the FOV is better (Polymost seems to stretch heaps in the corners, half way between full 3D and Software's Y-shearing), but regressions like in R7736 onwards where I get a black screen when a relfective surface is shown necessitates some kind of fallback.

The only option I can think of now is using a batch script to parse eduke32.cfg and change the line "Polymer = 0/1" and change it appropriately upon launching. Doing that without mangling the file is difficult though.

[Forge]

are you trying to avoid the launcher/setup screen?

maybe post up a copy of your autoexec.cfg files

[Kyanos]

autoexec render switching at startup does not work with current builds, I just tested. It did work with older builds I tried.

I get the same trailing log file end as Mitch posted.

[Forge]

Photonic, on 16 July 2019 - 04:27 PM, said:

autoexec render switching at startup does not work with current builds, I just tested. It did work with older builds I tried.

okay.
mystery solved then

edit: I see they also took it out of the settings.cfg file

[mjr4077au]

Forge, on 16 July 2019 - 04:16 PM, said:

are you trying to avoid the launcher/setup screen?maybe post up a copy of your autoexec.cfg files

If I can, yes. I'm not at the moment so I have the choice. With some shortcuts I have for Nuclear Winter and Vacation, specifying "-addon 2" or "-addon 3" respectively bypasses the start screen. So for HRP shortcuts of those, I actively have to include "-setup" to get the setup screen (or not use "-addon 2/3" and specify the expansion group file with -g).

"D:\Full Games\Duke Nukem 3D\eduke32_win64\eduke32.exe" -addon 3 -j "hrp" -j "vaca_plus" -j "vaca_plus/vaca_plus" -x "VacaEDuke.con" -h "duke3d_hrp_polymost.def" -mh "vaca_plus.def" -mh "vacation_hrp.def" -usecwd -setup

Photonic, on 16 July 2019 - 04:27 PM, said:

autoexec render switching at startup does not work with current builds, I just tested. It did work with older builds I tried.I get the same trailing log file end as Mitch posted.

Thanks for checking this out. If it should work and it's a bug, thats great and can hopefully get resolved in due course. What's an older build you've tested that works? I was thinking of going back to an older build due to the Polymer issues I have that came about in R7736.

[Forge]

Mitch Richters, on 16 July 2019 - 04:35 PM, said:

What's an older build you've tested that works? I was thinking of going back to an older build due to the Polymer issues I have that came about in R7736.

my suggestion is to keep the set-up you have, with the rendermode in the cfg.
start dropping in snapshots until you find one that works.
I'd start around the 5000 series & go up or down from there.

[Kyanos]

Last working R6775
First broken R6777

changelog;

Quote

r6777 | pogokeen | 2018-03-21 13:41:32 -0700 (Wed, 21 Mar 2018) | 1 line

Polymost: center texel fetches for palette lookups and add various optimizations related to indexed texture changes
------------------------------------------------------------------------
r6776 | pogokeen | 2018-03-21 13:41:26 -0700 (Wed, 21 Mar 2018) | 1 line

Polymost palette-indexed texture rendering

[Forge]

Photonic, on 16 July 2019 - 04:58 PM, said:

Last working R6775
First broken R6777

newer than I thought it would be

[Kyanos]

Ya, which makes it maybe more likely to be fixed. I hate bisecting, you start to get close but the half steps get shorter and it feels like that race paradox where you never cross the line.

[Forge]

coincidentally, that's also where WGR2Siegebreaker had its skyboxes broken.
Works with 6775, broke after 6777

[mjr4077au]

Photonic, on 16 July 2019 - 04:58 PM, said:

Last working R6775 First broken R6777changelog;

I can confirm that in R6775, it loads properly however it thinks my GPU is gimped and reverts to Polymost!

Quote

Executing "settings.cfg"
Executing "autoexec.cfg"
Post-processing MD3 models for Polymer. This may take a while...
Initializing Polymer subsystem...
PR : Your video card driver/combo doesn't support the necessary features!
PR : Disabling Polymer...
Rendering method changed to polygonal OpenGL
Setting video mode 3840x2160 (32-bpp fullscreen)

Running eduke32.exe and selecting Polymer starts with the Polymer renderer as expected. Again, soo close to a result

Photonic, on 16 July 2019 - 05:15 PM, said:

Ya, which makes it maybe more likely to be fixed. I hate bisecting, you start to get close but the half steps get shorter and it feels like that race paradox where you never cross the line.

I feel the same way, I guess that's the problem with a rolling release cycle. Seems like changes here get commited into master instead of devs forking off from master, implementing their changes and submitting pull requests.

Forge, on 16 July 2019 - 05:18 PM, said:

coincidentally, that's also where WGR2Siegebreaker had its skyboxes broken. Works with 6775, broke after 6777

Maybe R6775 should have been where EDuke32 went from 1.9.9.9 > 2.0.0.0

[mjr4077au]

Phredreeke, on 16 July 2019 - 03:19 PM, said:

I think eduke32 requires you to set up a 32-bit video mode before it lets you set Polymost or Polymer in autoexec.cfg

You're absolutely right. Tested R6775 and couldn't get it to work as per my previous post, but with this as the lines in autoexec.cfg, it works great! It even works in R7800...

vidmode "3840" "2160" "32" "1"
setrendermode "4"

I guess this issue is resolved?

Photonic, on 16 July 2019 - 01:58 PM, said:

Thinking outside the box, try making two sub directories with an autoexec.cfg in them one for each polymer and polymost. Use the command line argument -j to add the right directory to the path for what renderer you want to use. This way your eduke32.cfg stays common.

Thank you very much for this suggestion, this is exactly what I'm doing and with the autoexec.cfg file specified right, it's working perfectly

[Kyanos]

You're welcome.

[inf78]

Sorry for necropost, but I couldn't figure this out when trying to set SW renderer on start without having to use the setup, so I will share my experience with the (as of now) latest EDuke32 - r10619

First, I don't even have Polymer support built-in for my linux build, I have really no use for it, I don't use texture packs. Heck, I don't even use skyboxes for Duke3D (I do for Shadow Warrior) as it also tends to
misbehave when a certain map/mod has a different opinion about the sky used.

I generally use to start the base game with the "-j" switch which points to a directory where DUKE3D.GRP, DUKE.RTS and autoexec.cfg files are (plus my small fixes in another grp).
Autoexec.cfg has everything already set-up, no need to fiddle with anything when running the game for the forst time, just as I like it.
Problem is, that some mods require a bit different settings here and there and some just require SW renderer to look and work as they are meant to. For the life of me I couldn't get that done properly.
In current rev (10619), "setrendermode" "3" in autoexec.cfg will just give a SIGSEGV on start..
BUT:

vidmode "2560" "1440" "32" "1"

will work as expected. Since I don't have Polymer built-in, it automatically selects Polymost with the "32" argument. And so if I have an autoexec.cfg in another
mod dir I can just have this line in it:

vidmode "2560" "1440" "8" "1"

and it works just as expected, meaning it automatically selects "Classic" aka SW renderer and all the other necessary changes I have in the autoexec file, while inheriting the rest from the general settings.cfg, which in turn gets populated with stuff present the general autoexec.cfg.

Still a bit "dicky" as OP used the word, but still fine. Raze's default way of including all directories in search and inability to use something similar to EDuke32's "-j" switch is much worse beast to cope with.