[469b] SHADER_ARB as default. Why?

Discussions about UT99
User avatar
TankBeef
Adept
Posts: 441
Joined: Tue Apr 13, 2021 12:56 am

[469b] SHADER_ARB as default. Why?

Post by TankBeef » Sat Jan 22, 2022 8:14 pm

Ok...for some reason the 469b OpenGL has a shader enabled by default, SHADER_ARB. What this means is that I constantly get complaints from players that apply the patch, and then they don't understand why under OpenGL they try everything to adjust brightness, and it stays dark. :facepalm: I know cause it happened to me at first. And after so much fiddling, it turns out you have to go to preferences and change shader type from SHADER_ARB to SHADER_Disabled. But why is this setting by default? I think it confuses people, especially new players, and most play with high brightness. :wth:

User avatar
Feralidragon
Godlike
Posts: 5432
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: [469b] SHADER_ARB as default. Why?

Post by Feralidragon » Sat Jan 22, 2022 8:47 pm

That's something you can ask at the 469 HQ, aka OldUnreal Discord:
https://discord.gg/DaCwwNng

Having that said, there were some experimental features included in the renderers, and some are disabled by default, and others enabled.
A lot of these new "features" actually aim to make the rendering faster: for example, the way the new renderers render meshes is different in 469, it's a lot lot faster than in 436, although this is only noticeable in mods that either use high poly meshes, or lots of meshes in views.

But, as you noted, in some systems there may be some issues, either due to the way OpenGL was firstly built in the first place (not in the best way), or due to drivers, or Windows versions, and also bugs introduced by the patch devs as well (it happens often too).

Either way, this is stuff that ought to be asked about and reported either at their Discord (link above), or submitted an issue about in Github (link below):
https://github.com/OldUnreal/UnrealTour ... hes/issues

Just please remember that the 469 patch was being developed by just 2 people, and one of them stopped contributing last week, at least for now (for an indefinite amount of time), so things will be slow, but the progress is real, and everyone there is attentive to all reported issues (especially Anthrax, the patch lead).

This problem in particular may actually be already fixed in 469c (not sure, but highly likely), along other countless issues fixed as well, which is near a public beta release.

User avatar
TankBeef
Adept
Posts: 441
Joined: Tue Apr 13, 2021 12:56 am

Re: [469b] SHADER_ARB as default. Why?

Post by TankBeef » Sat Jan 22, 2022 9:04 pm

Feralidragon wrote:
Sat Jan 22, 2022 8:47 pm
Just please remember that the 469 patch was being developed by just 2 people, and one of them stopped contributing last week, at least for now (for an indefinite amount of time), so things will be slow, but the progress is real, and everyone there is attentive to all reported issues (especially Anthrax, the patch lead).
Wow, so now Anth is left alone working on the patch? :? Man, that sure is a lot of pressure, for anyone. What a hero.
Sure, I will ask him, with consideration to the circumstances of course. I did not start a thread a github, cause it is not really an issue, just some concern.
EDIT: Ok, I wrote Anth. He says the ARB should stay enabled. So I will try it again tonight. :tu:
EDIT2: Wow!!! I will never disable that thing again. Ferali, that was the cause of the DM-LastCrusader][. :facepalm: This one: https://github.com/OldUnreal/UnrealTour ... issues/519
I am going to close that issue then.

sn260591
Average
Posts: 67
Joined: Sat Jun 01, 2013 10:38 am
Location: Russia

Re: [469b] SHADER_ARB as default. Why?

Post by sn260591 » Sun Jan 23, 2022 8:54 am

TankBeef, you can try d3d9. This render is quite fast, stable and without any dubious experiments.

User avatar
TankBeef
Adept
Posts: 441
Joined: Tue Apr 13, 2021 12:56 am

Re: [469b] SHADER_ARB as default. Why?

Post by TankBeef » Sun Jan 23, 2022 3:48 pm

sn260591 wrote:
Sun Jan 23, 2022 8:54 am
TankBeef, you can try d3d9. This render is quite fast, stable and without any dubious experiments.
It's ok, I know lots of people prefer it, but I guess it depends on each system. In my case, I get a lot less fps than with the OpenGL, and for some reason it crashes with the HD Skins mutator. I won't bother to find out why. But the game does look a lot better with the ARB enabled. Just have to tweak the gamma offset a bit, and it is all good.

Automatically merged

I even started a thread about this, here: viewtopic.php?f=12&t=14812
But I don't know if I should bump it just to clarify that the ARB disabled was the cause. Moderators, please let me know.

Higor
Godlike
Posts: 1835
Joined: Sun Mar 04, 2012 6:47 pm

Re: [469b] SHADER_ARB as default. Why?

Post by Higor » Mon Jan 24, 2022 2:41 pm

v469c notes regarding GL:

That option will be gone and will instead be default behaviour (no more shaderless rendering)
The underlying cause of the problem was fixed anyways.

As for how brightness is applied that's left to a new option named ColorCorrectionMode, you may use:
- InShader: apply it on every surface, not precise where there's transparency.
- UseFramebuffer: render everything offscreen, apply it on the final framebuffer pass.
- UseGammaRamp: old way using changing the operating system's gamma ramp.
* Notes for linux systems:
** UseGammaRamp does nothing.
** UseFrameBuffer is required for Anti-Aliasing support.

The render device will have a hidden, experimental OpenGL 3.3 mode in it, while it's incomplete (and crashes the texture browser in editor) it can be a fallback for systems where the default OpenGL Compatibility/2.1 modes don't work well.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
TankBeef
Adept
Posts: 441
Joined: Tue Apr 13, 2021 12:56 am

Re: [469b] SHADER_ARB as default. Why?

Post by TankBeef » Mon Jan 24, 2022 3:24 pm

Higor wrote:
Mon Jan 24, 2022 2:41 pm
v469c notes regarding GL:

That option will be gone and will instead be default behaviour (no more shaderless rendering)
The underlying cause of the problem was fixed anyways.

As for how brightness is applied that's left to a new option named ColorCorrectionMode, you may use:
- InShader: apply it on every surface, not precise where there's transparency.
- UseFramebuffer: render everything offscreen, apply it on the final framebuffer pass.
- UseGammaRamp: old way using changing the operating system's gamma ramp.
* Notes for linux systems:
** UseGammaRamp does nothing.
** UseFrameBuffer is required for Anti-Aliasing support.

The render device will have a hidden, experimental OpenGL 3.3 mode in it, while it's incomplete (and crashes the texture browser in editor) it can be a fallback for systems where the default OpenGL Compatibility/2.1 modes don't work well.
Thanks Higor. Very good information here. :tu: