[Skulldog]

TX, on Mar 9 2011, 12:17 AM, said:

Putting files in their own separate mod dirs and loading them using the included drop-down selector in the startup window.

Then you would have to put Hrp packs in each mod dierectory or the main dierectory with no way to turn if off without removing the hrp files.
That would make the eduke directory 50 gigs or so. It would be better to remove checkbox and use a combobox with option of None, or any folder in
the main directory. Add a command for users and mod devs -hrp_dir None or -hrp_dir [dir name] Autoload is good thing to have.

[Danukem]

I want to call attention to this serious crash bug which affects the vanilla game now. The thread is badly named and may have gone unnoticed:

http://forums.duke4....?showtopic=3591

[Hendricks266]

Skulldog, on Mar 9 2011, 09:37 AM, said:

Then you would have to put Hrp packs in each mod dierectory or the main dierectory with no way to turn if off without removing the hrp files.
That would make the eduke directory 50 gigs or so. It would be better to remove checkbox and use a combobox with option of None, or any folder in
the main directory.

No, you put it in the root.

Skulldog, on Mar 9 2011, 09:37 AM, said:

Add a command for users and mod devs -hrp_dir None or -hrp_dir [dir name] Autoload is good thing to have.

-j

Look at the new batch file code I wrote for my add-on HRPs, before I even knew autoload was on the chopping block:

:arguments
set args=
if exist polymer_hrp\ set args=%args% -jpolymer_hrp
if exist duke3d_voxel.zip set args=%args% -gduke3d_voxel.zip
if exist duke3d_hrp.zip set args=%args% -gduke3d_hrp.zip
if exist hrp_update.zip set args=%args% -ghrp_update.zip
if exist maphacks.zip set args=%args% -gmaphacks.zip
if exist eduke32_mus.zip set args=%args% -geduke32_mus.zip
if exist "%addondir%" set args=%args% -j"%addondir:\=/%"
if exist "%addonhrpdir%" set args=%args% -j"%addonhrpdir:\=/%"
set args=%args% -gnwinter.grp -hnwinter.def
if "%editor%"=="1" set args=%args% -namesfile NWNames.h
if not "%editor%"=="1" set args=%args% -xNWEDuke.con
if "%dp%"=="1" (
set args=%args% -hnw_dp.def
if not "%editor%"=="1" set args=%args% -xNWDP.con
)
if "%xxx%"=="1" (
if exist xxx_lite.zip set args=%args% -gxxx_lite.zip
if exist xxx_pack.zip set args=%args% -gxxx_pack.zip
set args=%args% -hnw_xxx.def
if "%dp%"=="1" (
set args=%args% -hnw_dp_xxx.def
if not "%editor%"=="1" set args=%args% -xNWDPXXX.con
) )
set args=%args% %*
if "%dp%"=="1" set args=%args% -jDukePlus

set exe=%exename%
if "%debug%"=="1" set exe=%exename%.debug

if exist %exe%.bat (
call %exe%.bat %args%
) else (
start %exe%.exe %args%
)

[Skulldog]

So all the hrp packs and Polymer_hrp packs are used in Nwinter Plus with no problems?

[fgsfds]

Can you add option to enable\disable dynamic lighting with polymer? It's annoying to add or remove r_pr_lighting from settings.cfg each time.

[The Commander]

Have you tried making the settings.cfg read only?

[fgsfds]

That's not the point. I often have to enable or disable lighting, and for that I need to add this in config or type it in console. It's not too hard of course, but this option may be useful.

[Danukem]

empyrock, on Mar 16 2011, 10:34 AM, said:

That's not the point. I often have to enable or disable lighting, and for that I need to add this in config or type it in console. It's not too hard of course, but this option may be useful.

If it was in the menu it would be buried in the renderer options submenu, so using the console might actually be quicker anyway (unless you type slowly).

[TerminX]

Bind some keys to enable/disable it.

[Gambini]

I can´t tell exactly when this happened (surely when the new polymer hud was introduced): The shrinker and the expander now blink constantly when actually, the only thing that should blink is that red/green stone they have inside.

Also, i´m pretty sure i said this before but can´t remember in which post: the default r_shadescale that approachs the most to the all-life-duke-nukem is 1.14. The one in use currently has to be 0.99 or 1.00 which are both a lot better than what it used to be a few months ago,* but still 1.12-1.18 range makes a lot more justice to good shaded maps, because it has better contrast without those strange pitchblack textures (well, just as it used to be).

I also have been experimenting and noticed that one tad of contrast in polymost/polymer (0.05) makes it look a lot better. Too bad it doesn´t make difference in the screenshots since these settings overrule the screen. or i would show how better it looks.

So the thing is: Can contrast be changed in the core of the 32 bits rendereres to be 0.05 instead of 0.0? It´s worth a try, textures look a lot less washed and the feeling is a lot more 8bit-ish.

Another thing: Can the clipping plane of decal sprites be adjusted in polymer? See the images below, 1st is software renderer, 2nd is Polymost and 3rd is Polymer. The background white thing is made of sprites and they´re positioned slightly behind the letter sprites. Also notice that sort of spiderweb between T and the eye, the only case where it is misaligned is Polymer too.

*that was a mistake, the current shadescale is still 1.3 which is awfull.

Attached thumbnail(s)

• 
• 
• 

[Danukem]

Gambini is right about all of the above. The only tweak I would be concerned about is changing the default contrast, because in my experience while .05 does look better, some things become a little too dark unless you also increase brightness by a notch or two.

[Plagman]

I'm not sure I follow the shrinker thing; someone else was talking about a shrinker problem at some point in the past, so maybe it's related. Either way sounds like a game problem.

For changing the default shadescale, I think TerminX said changing it would make some other stuff look wrong. I don't have an opinion since I haven't closely tried; the current method of trying to match old Duke3D brightness kind of sucks, I'd rather write something that's exactly right for ART and stick with Polymer for lighting for high-resolution content.

Fixing the clipping problem you mentioned is way more involved than just tweaking a parameter, but it's planned.

[The Commander]

Plagman, on Mar 17 2011, 05:22 PM, said:

I'm not sure I follow the shrinker thing; someone else was talking about a shrinker problem at some point in the past, so maybe it's related. Either way sounds like a game problem.

I posted last month at some point that the expander goes completely black when not using the HRP which looks totally wrong.

[0815Jack]

is there a way to disable the light definitions in the maphack files, but leave the hardcoded ones active?

i tried r_pr_lighting "0" but this disables all.....

[Gambini]

Quote

For changing the default shadescale, I think TerminX said changing it would make some other stuff look wrong. I don't have an opinion since I haven't closely tried; the current method of trying to match old Duke3D brightness kind of sucks, I'd rather write something that's exactly right for ART and stick with Polymer for lighting for high-resolution content.

It would be wise to put that stuff that TerminX said would look wrong Vs what looks wrong now in a balance. At least before that solution for 8bits art is implemented. As it is right now, the original art is neglected in favor of third party packs.

Quote

I'm not sure I follow the shrinker thing; someone else was talking about a shrinker problem at some point in the past, so maybe it's related. Either way sounds like a game problem.

The shrinker´s hud 8bits art and its alt weapon, the expander. go black and go bright again just like the stone inside should do. I dare to say it´s something related to the hardcoded light that it casts in Polymer.

Quote

Fixing the clipping problem you mentioned is way more involved than just tweaking a parameter, but it's planned.

I know shit about coding but would not be enough to just shift the offset of these sprites toward the angle they aim? I remember i once had a very similar problem with the old Won version of Half Life, when using opengl. There was a commandline that could be added to the .ini file which would move the decal farther from the wall.

[Mike Norvak]

Ho ho ho ho...... finally I've got a new GTS 250 grafic card. Let's try Polymer!!!! <---- Hope it be as good as they say it is. BTW in addition to Duke Nukem Eternity and Of Pigs and Men, which maps do u recommend me?

[The Commander]

If you are using the SVN version of the HRP most of the original maps all have light map hacks.

[Micky C]

My second map, libraryl is a decent looking polymer map (especially considering it was my second ever map), just go into the maps section of MSDN and control-f for it. You can also search for my first map (Action Time on 7) which is also an ok looking polymer map, but is very noobish in all the other departments.

[Mike Norvak]

Okay, i tried a few maps with some dynamic lighting improvements (but not designed specially for polymer and i'm not convinced at all. Isn't so bad but everything looks too fancy and crude imo. And as various veteran mappers say, it messes things up about how a DukeNukem map should look. I'll try Of pigs and Men and those maps u tell me Micky.

[High Treason]

I think you tried it ages ago, but hey, it's likely been updated since and I feel like running some shameless self-promotion, so you could always give my first map a shot, it is Polymer only, http://forums.duke4....?showtopic=3093

[fgsfds]

It happened after 1848 revision.

[High Treason]

There's too much light on my screen for me to see what's wrong right now, but I immagine it's a texture problem?

Delete the files "textures.cache" and "textures" from the EDuke32 folder, this usually makes such issues go away.

I've been thinking for a while of making a simple .exe that removes the cache files as well as doing some other general 'house-keeping'

[fgsfds]

No, it's not texture problem. It works even without hrp. Maybe here it visible better. It's transparent texture (looks like 2456.jpg) in main menu. And I repeat that the problem has appeared in 1848 and later revisions.

[TerminX]

It's helixhorned's fault.

[Helixhorned]

Ah yes, I half-expected my half-baked 'r_shadescale_unbounded' implementation to break stuff. OTOH, you could say that it isn't a bug at all, try "r_shadescale 0" in the menu for example.

Anyway, I changed r_shadescale_unbounded so that it will allow to display tiles as totally black whenever the original renderer would have too.

[MusicallyInspired]

Just wanted to say that the recent updates to EDuke32 and the Polymer HRP are phenomenal! Now that I can play it at decent framerates (flawless, actually) I can truly appreciate everything even more than I did before. Fine work Plagman, TX, Helixhorned, the Polymer artists/modelers, Nightfright for putting the HRP all together for easy access, and anybody else who's had a hand in this. It looks GOOD. Fantastic. You guys all rock for doing this just for us to play with at no charge.

[Tetsuo]

The performance of the OS X version has also gotten very good. The long standing bug of sectors outside the one your in ceasing to draw after a while still happens however.

[RPD Guy]

there is a new bug in mapster! (revision 20110325-1856 and 20110324-1855)
in the tile selection screen, the tiles keep flashing, disappearing and appearing suddenly!
but the performance in game keeps good.
the only thing I don't know is that:
recently, my video card (geforce 9800gtx+) has spoiled, and i'm using my onboard video card.
AND this card is one ATI 4200 (this sux)
there isn't way I can see any shadows, and when "r_pr_shadows 1" the light spot disappear, and all I see is a darkened sector.
QUESTION: the problem is the ATI card? or the revision bug?

[Forge]

Dk2, on 02 April 2011 - 02:40 PM, said:

there is a new bug in mapster! (revision 20110325-1856 and 20110324-1855)
in the tile selection screen, the tiles keep flashing, disappearing and appearing suddenly!
but the performance in game keeps good.
the only thing I don't know is that:
recently, my video card (geforce 9800gtx+) has spoiled, and i'm using my onboard video card.
AND this card is one ATI 4200 (this sux)
there isn't way I can see any shadows, and when "r_pr_shadows 1" the light spot disappear, and all I see is a darkened sector.
QUESTION: the problem is the ATI card? or the revision bug?

I reported the exact same issue (see mapster32 bug reports thread). I'm using a geforce 9800 GTX+ . The problem doesn't happen with r1849. Haven't tried r1850,53,or 54 to see where it started exactly.

[Danukem]

Dk2, on 02 April 2011 - 02:40 PM, said:

there is a new bug in mapster! (revision 20110325-1856 and 20110324-1855)
in the tile selection screen, the tiles keep flashing, disappearing and appearing suddenly!
...
QUESTION: the problem is the ATI card? or the revision bug?

It's a bug in the revision. I fired up mapster after reading your post (it's been a while since I used it) and I'm having the same problem using my Geforce GTS 450.