Culling the glitches away

Truecolor ZDoom with extra features and some unofficial/beta GZDoom features.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Libs (Win)] [Repo] [Bugs&Suggestions]

Moderators: Rachael, dpJudas

User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

You're feeling square, I'm feeling the blues...
Screenshot_Doom_20161120_170726.png
Screenshot_Doom_20161120_170726.png (333.72 KiB) Viewed 6785 times
I committed what I've done so far. NYI means that I am not confident yet that the feature is complete, but the definitions are there.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Looks good so far. The boxes are my fault - I failed to realize that the 'stencil' part was applied as part of 'spans' in the old renderer. I'll fix that soon. :)
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

Also it should be noted the old renderer has a bug. I correctly implemented it in this new one - but the subtract blend mode subtracts (pinky - terrain) in Carmack-truecolor, whereas ZDoom, GZDoom, and softpoly do (terrain - pinky).

I'd fix it if I knew what needed to be changed. XD
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Does the TC renderer (new renderer off) do it the GZDoom way too?
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

No - check Pinkys.pk3 - G/ZDoom are correct - Triangle drawer is correct - Original QZDoom is not.

If it helps bind a key to "toggle swtruecolor" because the 8-bit column drawer does it correct, too.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Maybe you just need to swap the sub and revsub in the old render. In R_SetBlendFunc, change "case STYLEOP_Sub:" to "case STYLEOP_RevSub:" and visa versa.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

Walls are done now. The shaded blend modes are still not done, though, and I am really not sure what to do with those, to be honest...
dpJudas wrote:Maybe you just need to swap the sub and revsub in the old render. In R_SetBlendFunc, change "case STYLEOP_Sub:" to "case STYLEOP_RevSub:" and visa versa.
If I change that, won't I reverse the palette renderer too? I'm not trying to break that to fix the truecolor one...?
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Oh, sorry, thought both the palette renderer and the TC one was doing it. Yeah, that would reverse the palette renderer as well. :)
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Committed flipping rev and subrev in the old renderer.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

Cool :) Is there anything else you'd like me to do?
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Just committed an improvement to the shaded blend mode so that it uses srcalpha and destalpha. That made blue pinky and radioactive blue pinky work. For the radioactive version I had to multiply the srcalpha by two for some reason. Otherwise it would not match what the TC renderer was doing. Some of the right-most pinkies still differ, but I'm not sure if that's because one of them is being rendered by the decal code instead?

I saw you already updated the wall code to support more blend modes. We probably need to do the same for decals and possibly particles. It is probably also a good idea to test if texture flipping and scaling is applied correctly. Of course, if this gets too boring we can always address those issues as we notice them on actual maps.

On the topic of "culling the glitches away", I've debugged the culling as far as determining that it is PolyCull::CheckBBox's second check that causes the worst blinking artifact. I believe the reason is that the segment range cannot be calculated the way that function is doing when it collides with the near clipping plane. The individual four lines of the bounding box will have to be clipped against it and then the left-most 'sx1' value and right-most 'sx2' value needs to be used for the IsSegmentCulled test.

Of other things that could be improved is drawing the walls of the 3D floors. Or making the 3D floors it already draws support blend modes.

Those are the main things on my radar right now. Of course, any rendering anomaly when compared against ZDoom or GZDoom is worth fixing. It doesn't have to be stuff I've listed here. :)
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Fixed the BSP culling bug. Also added a stencil blend mode, because apparently the difference between 'stencil' and 'shaded' is whether it uses the alpha channel (aka. mask in 8 bit) or an index (the red channel in 32 bit?). Anyhow, seems insomnia is useful for something..
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

Well - the "shaded" modes, apparently, are supposed to be a direct 8-bit index into how dark they are, which is why the pinkys that use them were a bit weird. (Yes, decal code, I believe)

3D floors - not sure how much help I can be here. :( I still can't use your system well, although I could try to implement the blend modes.

It's good you managed to fix the polyculling problem. :)

Going to try it out as is but probably might wait a day or two before doing much else extensively. (I am a lazy programmer.. :( lol)

Also - are you sure you were supposed to double the alphas? This doesn't look right when I change radioactive pinky to green...
Screenshot_Doom_20161121_012544.png
Screenshot_Doom_20161121_012544.png (346.85 KiB) Viewed 6744 times
Screenshot_Doom_20161121_012546.png
Screenshot_Doom_20161121_012546.png (341.19 KiB) Viewed 6744 times
Curious though are you going to implement the skycap fading? (sorry... maybe I am a little TOO excited XD)

Also - it seems whenever I look straight up that things behind me still get culled needlessly.

Lastly, though still incomplete, it seems like the renderer is solid enough at this point to start beta testing. Should we set CVAR_ARCHIVE on r_newrenderer and add it to the menu, you think? :D (Of course you know this is going to come with an announcement, too :P)
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Eruanna wrote:Well - the "shaded" modes, apparently, are supposed to be a direct 8-bit index into how dark they are, which is why the pinkys that use them were a bit weird. (Yes, decal code, I believe)
That is what it is doing now, but there are some oddities that I cannot explain. The bullet and rocket holes on walls are much darker in the TC and poly renders compared to zdoom. But just like with radioactive pinkie, if I rescale the transparency something else starts to look wrong instead - in this case the blood stains on the wall. There is some extra element to that blend mode that I am missing, unless ZDoom is the one with the errenous rendering. I probably should check how GZDoom renders it.
Curious though are you going to implement the skycap fading? (sorry... maybe I am a little TOO excited XD)
At some point that was the plan. The skies aren't remotely correct right now - I just roughly made sure the texture coordinates are close enough to correct for me to stop noticing how wrong they are. Also need to support double skies. Probably will take a while before I get to this as especially the texture coordinate part is about as fun as watching paint dry. :(
Also - it seems whenever I look straight up that things behind me still get culled needlessly.
I know why this is happening, but I don't know a good solution to it just yet. When you look up and down you can see a little bit of the scene behind the viewpoint. I need to add some kind of fast test that checks if a wall or sector is in this sweetspot and have it ignore the solid segment culling if it is. Anyhow, the current behavior is "working as expected" and not a bug. Kind of how the sprites get clipped in some situations still.
Lastly, though still incomplete, it seems like the renderer is solid enough at this point to start beta testing. Should we set CVAR_ARCHIVE on r_newrenderer and add it to the menu, you think? :D (Of course you know this is going to come with an announcement, too :P)
Feel free to add the setting to the menus. I would probably rename the setting first, and add some kind of "(experimental)" thing as part of the menu description. Also been wondering if GL BSP nodes shouldn't just always be enabled. The poly renderer needs it, the automap texturing needs it, and GZDoom got it on always anyway.

I don't mind an announcement, but note that the poly renderer in pal mode crashes right now (probably some args.uniform.color index out of bounds). Just make sure the bugs forum doesn't get flooded with bug reports for the poly renderer, as I am not really looking for a list of things not rendering correctly at this point.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

I'll hold off on the announcement for now, then. The people who should see it already have at some point. :)

For GL BSP, feel free to load them on startup if you prefer. In fact, I don't really see any harm in forcing all of the GZDoom structs/data code to load itself when starting a map - because there's a chance that might actually help us, in the long run, track down what's causing it to crash on rendering change.
Locked

Return to “QZDoom”