[ToiletDuck64]

In that case...maybe what we really need is some kind of slider where one end is "everything is exactly where it should theoretically be" and the other end is "all the sprites are offset far enough out to get rid of all the depth fighting that could possibly happen".

[TerminX]

http://dukeworld.duk.../20151020-5395/

[PsychoGoatee]

Very cool, that switch is looking great now for example. Thanks for the excellent work.


Just for the record, this thingy does still show up in some other instances of wall sprites in Polymost. For example, the stairwell in Duke Hard levels. Though that was intended for classic renderer I think, where it looks normal. Not a big thing, but I wonder if it'd be possible to fix. Other than just moving your sprites further from the wall I guess.

Still, great that it got fixed for some things, like that switch. I wonder if there are any other instances of this little visual glitch in the original Duke levels now.

Attached thumbnail(s)

• 

[Helixhorned]

r5391 said:

New attempt at fixing the depth fighting with wall and floor-aligned sprites.

Glad to see the unjustified (because user-tweakable) "r_wspr_" parameters gone.

The main change to me seems that the eye <-> sprite distance is now factored into the depth offset (the FindDistance2D() instead of tspr->owner). A quick test with a map I used for this purpose shows that it seems to work decently.

r5394 said:

Sort tsprites by owner as a replacement for the sort by statnum removed by Helixhorned a while back. Seems sensible enough...

It's not reasonable as it reintroduces this bug also described in r4876. Look at the two last sorting loops now: the second one overrides the former (instead of only sorting values that compare equal in the previous run, which would be OK), making one of them redundant. The bug can be observed in

Spoiler

AMC TC from SVN,
CHINA.map, search for a sprite with picnum 8520.
For example sprite #2043 as of time of writing, with r2177.

[LeoD]

ToiletDuck64, on 19 October 2015 - 04:25 PM, said:

...maybe what we really need is

IMO, what we really need is some proper and up-to-date documentation for this plethora of r_*, r_pr_* and whatnot parameters and their defaults. EDuke32 is going nowhere for end users with all of its features and possibilities if you can't use them properly without permanently following the forums and the source commit logs.

[Hendricks266]

LeoD, on 20 October 2015 - 09:11 AM, said:

IMO, what we really need is some proper and up-to-date documentation for this plethora of r_*, r_pr_* and whatnot parameters and their defaults. EDuke32 is going nowhere for end users with all of its features and possibilities if you can't use them properly without permanently following the forums and the source commit logs.

Ask, and ye shall receive.

[Mark]

Now we need the smart people to fill in a lot of the notes sections with useful info and add in what the default values are for a lot of the settings. ( for instance some of the commands concerning lighting and shadows for Polymer )

[TerminX]

Helixhorned, on 20 October 2015 - 05:04 AM, said:

Glad to see the unjustified (because user-tweakable) "r_wspr_" parameters gone.

Those actually had a purpose. I have a few different Android devices that all seemed to require different offsets into the depth buffer for anything to render correctly. I haven't tested the new code on them yet, hope it works.

Quote

Look at the two last sorting loops now: the second one overrides the former (instead of only sorting values that compare equal in the previous run, which would be OK), making one of them redundant. The bug can be observed in

Oops, thanks! Will fix.

[Hendricks266]

Mark., on 20 October 2015 - 01:06 PM, said:

Now we need the smart people to fill in a lot of the notes sections with useful info and add in what the default values are for a lot of the settings. ( for instance some of the commands concerning lighting and shadows for Polymer )

Ooh, I agree that the default values should be listed. Unfortunately, the approach I took to generate the page from the source code (regular expressions) won't be sufficient to generate those automatically. I have some ideas for how to approach this.

I'm not so sure about adding "useful info" to the notes. I intended that column to contain only circumstantial information about the commands, such as the cases when they are disabled or compiled out. A table like this doesn't have much room for blabbing. Every console command has a short description in the program that displays when you run "help <command>", and these should serve to entirely self-document the console. If you have suggestions for anything, feel free to let us know (and/or edit the wiki page and I will either propagate the changes to the source or revert your edit).

I also plan on adding hover-tooltips to the labels like MAXPALOOKUPS-1 and PR_MAXLIGHTS that display their numerical values.

[TerminX]

Committed another revision to the depth fighting mitigation code. Hopefully it succeeds in most cases now!

[Hendricks266]

Hendricks266, on 21 October 2015 - 11:40 AM, said:

I have some ideas for how to approach this.

Okay, I used a fresh install of EDuke32 and Mapster32 compiled after having disabled the check to only save to .cfg the cvars that have been modified. I'll need to verify that this is in fact everything, and if so integrate it into the wiki text.

[Mblackwell]

Also the cursor gets its color from crosshaircolor which isn't saved in the cfg and also can't be written by autoexec.cfg

Of course now we're off topic.

[Hendricks266]

http://svn.eduke32.c...duke32&rev=5387

[Mblackwell]

Well sweet teriyaki chicken!

[Hendricks266]

We still need a way to disable the colorization entirely. When It's Done!

[Danukem]

TerminX, on 21 October 2015 - 12:10 PM, said:

Committed another revision to the depth fighting mitigation code. Hopefully it succeeds in most cases now!

I guess it does, but I'm still seeing some problem cases. This screen is from Dogville:

Attached thumbnail(s)

• 

[TerminX]

Trooper Dan, on 26 October 2015 - 10:51 AM, said:

I guess it does, but I'm still seeing some problem cases. This screen is from Dogville:

Could you do DNDEBUG in front of that and send me the resulting debug.map to check out in the editor? Thanks!

[Player Lin]

I also encountered such problems like DT's one with r5409...but not on other sprites but alphabets...

Played on some levels with big alphabet sprites on walls and one or some of them will disappeared fully or partly...sometimes I can get them back to fine(without glitches) after save and restart the game, but sometimes I can't, like this one.

In EDFSB.MAP



The "A" just not clear to see.

 eduke32.log (100.68K)
Number of downloads: 212
 debug.zip (79.29K)
Number of downloads: 287

My DNDEBUG Log and the debug map for this problem.

--

I'm not sure if the engine acting weird or something, when I play DT's WoA mod(1.7b with latest con code fixes, of course, use eduke32 r5409)'s HSC episode, after played and completed some levels, this kind of sprite problems will appeared again randomly, like some alphabet sprites just z-fighting with the wall caused them partly or fully disappears, until I save and restart the game again and they all back to normal...just feel weird...

Like in the same map(EDFSB.MAP)...

In this position, you see "1", "2", "3" of sprites on pillars as normal circumstances, but if the glitch happens, they'll all fully disappeared. Until next time I restart the game and load the save on there.

(Also the above one, "ACCESS" will all randomly disappeared, not just only "A", save and quit then restart again, load the save and it's back to the only "A" acting funny. I also found this problem in Kaiser Land 1&2, on the welcome message in beginning of level, some of alphabets just invisible partly or fully, again... save, quit and restart then load the game and they all back to fine again.
Sorry I just forgot take screenshot when the random glitch happens. )

[Mark]

Polymer wall sprite flickering continues to be a problem. When Mapster places a sprite on a wall and you look at it in 2D mode it actually places the sprite a tiny, tiny bit away from the wall. However in Polymer, it is still not far enough away from the wall to avoid flickering and so for every wall sprite I add I have to turn off grid locking and drag the sprite a little farther away then turn grid locking back on until the next time I have to repeat the process. I have been working around the bug for a long, long time but its getting to the point that I would like to see it fixed. Earlier in this thread it was addressed for Polymost but not Polymer it seems.

[neoacix]

Can confirm the issues Player Lin mentioned before.

Sprites are not drawn, sprites in background got drawn like they're in foreground:


If you get near, everything is drawn correctly:


Also, some sprites have a wrong size, which causes gaps between them. This is getting worse if you go far away and is getting better the closer you get:

In mapster the gaps are not visible at all:


I tried to build a small map to recreate this bugs, but in my small map, everything looks fine.

Polymer renders everything correctly.
Polymost does not.

Tested with build 5628 64 bit on Windows 7 Pro 64 bit, GTX 970.

[Player Lin]

neoacix, on 14 February 2016 - 04:23 PM, said:

stuffs

https://youtu.be/JTShurhZMxI

Yeah... I recorded those bugs in action, with r5628...map is RED2 (2014 remake) again.

Missing alphabet sprites(the WC "sign" just disappeared so I forgot that's a goddamn WC room when I play the new version of map), and gaps on the both sides of security camera "box"......

Classic renderer just fine...
https://youtu.be/vBqm0NvjdBw

I'll try to fire a ticket on the bug tracker... :\

--
EDIT:
Was forgot to recorded, the sign outside of bar in the same map also have this problem, can't see it from far away but it suddenly show out when I come closely.
And gaps on its both side......do a record of this one too...

https://youtu.be/dxxKMjo6BNE

--

[deuxsonic]

What if an option was added to use double precision for the z-buffer if one chose to? Additional precision seems like it would solve a lot of the misalignments and z-fighting and I don't think the performance impact would be that noticable on most hardware being used to play the game (hence it being a user option.)

[neoacix]

Player Lin, on 15 February 2016 - 12:49 AM, said:

I'll try to fire a ticket on the bug tracker... :\

Good thing, hope TerminX will fix this soon.

deuxsonic, on 15 February 2016 - 11:07 AM, said:

What if an option was added to use double precision for the z-buffer if one chose to? Additional precision seems like it would solve a lot of the misalignments and z-fighting and I don't think the performance impact would be that noticable on most hardware being used to play the game (hence it being a user option.)

I hope TerminX will find some compromise.
The fps boost of single precision is realy appreciable, especially on a big open world map like I'm working on right now.
For me it seems like coordinates and sizes got messed up only in some stages.
Maybe he can put in a trigger to switch to double if single won't do the job right, so we can keep the overall fps boost.

Otherwise if this isn't possible, I would prefere an option too.

[deuxsonic]

neoacix, on 15 February 2016 - 02:31 PM, said:

Good thing, hope TerminX will fix this soon.



I hope TerminX will find some compromise.
The fps boost of single precision is realy appreciable, especially on a big open world map like I'm working on right now.
For me it seems like coordinates and sizes got messed up only in some stages.
Maybe he can put in a trigger to switch to double if single won't do the job right, so we can keep the overall fps boost.

Otherwise if this isn't possible, I would prefere an option too.

Automatically switching seems like it would be a lot more work to implement. I guess you could use magic numbers to know when to switch or base it on framerate (I would imagine you'd have to reinitialize the renderer for the change to take effect though), but I'd rather just have it as something like "r_depth_double = "1"" as like many other settings what bothers one person is not an issue for another. I have the game maxed out as it is so for me it would be worth having.