[0.6.0-452-gfc466849ce] Lighting isn't diminishing properly

[mjr4077au]

So this has become a resolution specific issue now? Wtf. I wonder how it happened.

But it still bugs me that this is happening on a laptop. Does it run on the dedicated GPU or the integrated one? If it's the integrated one I wouldn't be surprised if it's a driver issue or something.

It's the integrated, but the GPU isn't the issue. Using 0.6.0 as a comparison, the lighting diminishes as I'd expect (and how the current master does at 1440p).

The entire projection math in Polymost is all fucked up and apparently cannot produce consistent distance results.

Yeah, it does seem to be the case... Is anything on the agenda for that math in due course? What would be best course of action be at the moment? I'm unsure whether I should have my changes reverted or just leave them.

[Graf Zahl]

I have no idea. I think the problem started when I replaced some distance math with something that looked more sensible. But apparently Polymost has all the properties of something insane: You can't judge it by sensible means.

[mjr4077au]

Yeah that's when it started. I'm going to have a play around next week and see if I can it right without it going back to the shit-storm that it was. I think because the original calculations were using xdimen and xyaspect as part of the multiplications and aren't anymore, that's probably where the reason lays.

Snippet of old code from 0bd460d9e3bbaf239f4a33f9ce589dff58660bea:

Code: Select all

    i = mulscale16(xdimenscale,viewingrangerecip);
    globalpisibility = mulscale16(parallaxvisibility,i);
    globalvisibility = g_visibility * xdimen;
    globalvisibility2 = mulscale16(g_visibility, i);

    globalhisibility = mulscale16(globalvisibility,xyaspect);
    globalcisibility = mulscale8(globalhisibility,320);

#ifdef USE_OPENGL
    globalhisibility2 = mulscale16(globalvisibility2,xyaspect);
    globalcisibility2 = mulscale8(globalhisibility2,320);
#endif

EDIT: I've submitted PR #78 for review and discussion on this issue. Preliminary testing shows that this yields a correct result on my laptop at 1080p but I need to validate this against my home computer at 1440p.

Further to the discussion, I'm wondering whether any other changes in 0bd460d9e3bbaf239f4a33f9ce589dff58660bea have created a potential overall net-negative. Take the below block of code for instance changed from:

Code: Select all

        globvis2 = (sector[sectnum].visibility != 0) ?
                  mulscale4(globalcisibility2, (uint8_t)(sector[sectnum].visibility + 16)) :
                  globalcisibility2;
        PrintVis(sector[sectnum].visibility, 'c');
        GLInterface.SetVisibility(globvis2, fviewingrange);

to:

Code: Select all

GLInterface.SetVisibility(sectorVisibility(sectnum))

As per the first code block, globalcisibility2 was calculated off globalhisibility2, which was calculated off globalvisibility2, with globalvisibility2 being based on values from xdimenscale and viewingrangerecip, and globalhisibility2 based on xyaspect.

In addition to the above resolution variables not being factored anymore, GLInterface.SetVisibility() isn't factoring in fviewingrange anymore. I'd have to do some Printf() lines to get the resulting numbers before and after the changes, but it feels like this code has been simplified at the cost of some accuracy.

[Graf Zahl]

Ugh... That math is truly fucked up and serves as a perfect reason why Polymost is a lost cause.

What am I supposed to say? It's stuff that doesn't work because it makes sense, it only works because there's something fundamentally wrong with the code it depends on.

[mjr4077au]

Yeah it wasn't easy going back through that commit and working out what was what, what's there now is definitely a lot cleaner.

The commentary wasn't meant to put you on the spot or anything like that, so apologies if you felt that way. What would be the best thing to do here? Leave the code cleaner at the expense of visibility issues depending on your resolution, or should I test out that PR on a few devices and ensure it's ready for review?

The main reason I'm so into this isn't so much to do with the change as such, it's more just getting to the bottom of things to improve my understanding of the game and programming.

[Graf Zahl]

Test out that PR would be the way to go. If the math doesn't match up it will also mean that later, once I have time to rework the renderer, it may cause mistakes when cleaning up house. At least now it is a lot more comprehensible than the global?isbility mess that was there before. I still haven't figured out what those mangled names were supposed to *mean*!

Just one request: Please write out the calculations that lead to 0.00000000023283064365386962890625. This is just a magic constant, if we later want to know how we got it something more explicit is preferred.

[mjr4077au]

No worries, I'll test it out and change that constant back to '(1.f / (65536.f * 65536.f))' as requested. This is the old formula used in GLInterface.SetVisibility().

[sinisterseed]

So basically, the old technique was messier than what is now in place with GlInterface, but when it was sanitized and simplified the scale factors got removed along with it.

What I still find dubious about this whole thing is how it became resolution dependent in the whole process, since I think there could be more to it than that. You said you have a 1080p laptop screen, but I also have a 1080p monitor and for me it was always fine before and after the changes, so there's an inconsistency. Same resolution, different hardware, and also different results.

How much of this can actually be improved in the future, once the renderer rework commences? The way Polymost works seems to not be flexible at all when it comes to sector light handling.

[Graf Zahl]

Polymer doesn't have this projection crap. What essentially happens here is that screen distance depends on the screen's dimension because Polymost made the fatal decision not to pass the unaltered coordinates to the hardware but ones transformed into camera space - but not doing this projection independently of the viewport.

It all boils doen to poor design when this renderer was written.

[sinisterseed]

Polymer doesn't have this projection crap.

This is interesting. How did Polymer handle the sector lighting?

[Graf Zahl]

Polymer doesn't mangle the geometry before passing it to the hardware - it uses the 3D hardware as it was intended to be used - so it passes coordinates to the hardware that represent proper world positions, not some weird values that depend on the screen size and bear no relation to where in the map an object is placed. With that fog calculations are trivial - we are now on the same page as GZDoom.

[mjr4077au]

With that said, I'm surprised Polymer wasn't more viable in the end. Do you think with some perseverance it could have been used as your basis or it was really that hard to separate out the GL code?

[Graf Zahl]

Polymers problem lies elsewhere. It's the classic case of developing a renderer and doing the fancy stuff before the basics are working. So it got all the lighting stuff added before it was made performant. And once you are there, the game is normally over when the fancy stuff depends on the inefficiencies.

It's a bit like both incarnations of ZDoomGL. They had quite a few interesting effects but one was buggy as hell and the other didn't even get the most essential basics to work. In both cases the creators were more interested in the effect code than having a stable foundation to work on. And both died painfully.

And this is precisely where GZDoom differs. I never was that interested in the fancy effects but I was interested in having a stable renderer that is fast and can handle the most common render hacks. SO when the effects got added, these optimization gotchas had long been moved out of the way..

Another issue with Polymer is its internal structure - or to be more precise - the lack of it. The entire renderer is one huge file where stuff had been mashed together as it appeared - there is no dedicated texture manager, no shader manager, no render list manager etc. But since these components are not isolated it is a lot harder to test the code for inefficiencies and address them.

[mjr4077au]

That all makes a lot of sense and sounds about right. What's the plan with Polymost now that it's running on the new backend? Re-write things piece by piece until it's all new or write something new to supplant it completely?

[Graf Zahl]

It has to be replaced at once. Getting a basic render setup working isn't that hard, for a first version it won't have to render all effects and even texture placement properly. Once that skeleton works it's piece by piece addition of needed features.