Testing a new rendering backend (New tests needed)

[XLightningStormL]

Oh, I didn't know you had a graphics card from 2000!

Yeah, have a nice day indeed!

No, actually, I have a GTX 1060 TI and a Pentium G4560, and can run a massive mapset at 35 FPS all times with about 20 ACS scripts running concurrently with Vulkan.



But just because I can run the game well with my setup doesn't mean others can, especially in Brazil.

But I do vaguely recall some pre-dpJudas builds being very poorly optimized with Vulkan. Really makes me think...Le No Chicken.

[Gez]

This topic is turning sour, and it'd be a shame to have to lock it up. Behave.

[Graf Zahl]

But just because I can run the game well with my setup doesn't mean others can, especially in Brazil.

The main question is - what do users in Brazil really have? Do they really use GL 2 hardware or are they already on GL 3 hardware that in more developed countries has also become obsolete some 5-8 years ago? Since we have no good metrics for GZDoom, let's just have a look what we do have:

https://gs.statcounter.com/windows-vers ... top/brazil

That list shows 79% Windows 10 market share - for comparison: Germany has 87%, meaning the number of older system is twice as high as in more developed countries. But it clearly shows that the majority of computers does not run ancient OSs which are a prerequisite for such old graphics hardware - because here's the important thing: None of the existing GL 2 hardware has working Windows 10 drivers! So in general one rather safe assumption is that if people got Windows 10 they either can run OpenGL 3.3 or are forced to use standard drivers with no GL support at all!

[Rachael]

This topic is turning sour, and it'd be a shame to have to lock it up. Behave.

This, 100%.

Already issued one warning.

[drfrag]

I'm surprised it even starts on GL 2.1 hardware (Beloko presumed it wouldn't even load).
With the MESA driver (Mesa3D for windows) on 64 bit it runs and plays, sorta.
The standard GZDoom aborts as expected. But there's a problem with Beloko's renderer and the MESA3D driver (same thing happened with old GZDoom versions but it was hit and miss), you only get a small window taking 1/8 th part of the screen.
https://fdossena.com/?p=mesa/index.frag
If you want to try get the 64 bit version, copy opengl32.dll and my mesa.cmd (to force GL 2.1) files and run the cmd.

[Rachael]

I do not know how reliable this is - if the Mesa3D driver even has a OpenGL 3.3 implementation I can't 100% trust it to load OpenGL 2.1 code properly the way a genuine OpenGL 2.1 system would.

And unfortunately I do not have much access to such systems. I have an old laptop laying around that I might be able to try with this, so I will try that, I have no idea what GPU it has or what OpenGL version it supports, I just know that it is very very old.

The oldest working card that I have right now outside of that is an ATI Radeon HD2400 which supports OpenGL 3.3. Or an Intel GMA 900 series but that's waaaaay too old.

[drfrag]

My old laptop is still not dead and has a GMA 4500M with only GL 2.1, i'll try soon.

[dpJudas]

But I do vaguely recall some pre-dpJudas builds being very poorly optimized with Vulkan. Really makes me think...Le No Chicken.

Since I wrote the vulkan backend if there were any performance problems there it surely wasn't Graf's fault. Now stop the trolling.

[Talon1024]

On the other hand, WebGL is based on OpenGL ES, so I wonder if this new rendering backend could be a step towards compiling GZDoom with Emscripten and running it in a web browser?

[Rachael]

That is a neat prospect but I can't say whether the absence of this was really the showstopper for that.

There seems to be a lot of other issues with GZDoom and emscripten that make it incompatible that would need to be addressed, first.

[drfrag]

On real hardware it crashes before showing the title screen for me, it's not surprising. With MESA i only changed the GL strings.
Beloko said it still uses the original OpenGL context creation from GZDoom, he presumed it wouldn't even load.

[Graf Zahl]

Yeah, not surprising, it uses GL 3.x context creation functions on Windows. This surely won't work on original GL 2 hardware.

[drfrag]

I was expecting to get the "At least OpenGL 3.3 is required to run GZDoom" message.

[Rachael]

And this is why I kept insisting we needed genuine GL2 hardware to test on.

Needless to say though this tells me exactly what I needed to know. And the very fact that finding someone with GL2 hardware was a bit of a pull, also says a lot about the state of its popularity in general. I still think the branch is useful for early GL 3.3 hardware, and I did notice some speed improvements, but it was nothing earth shattering.

I'll see about porting LZDoom's context creation code over if I can, if it's simple enough - but for that, I probably should change it to GL ES anyway.

[Graf Zahl]

And this is why I kept insisting we needed genuine GL2 hardware to test on.

Needless to say though this tells me exactly what I needed to know. And the very fact that finding someone with GL2 hardware was a bit of a pull, also says a lot about the state of its popularity in general. I still think the branch is useful for early GL 3.3 hardware, and I did notice some speed improvements, but it was nothing earth shattering.

I don't really think that this is in any way optimal for early GL 3 hardware - it fragments the shader far too much for that. The optimal solution here would be to reduce some of the shader complexity but not amputate half the engine. Remember: GL 3.3 can run full GZDoom, so most of what's being done here is not necessary.

The really important thing on that hardware is to disable a few effects, e.g. software lighting is too much for a Geforce 8xxx or 9xxx in many cases