DRD Team

Alright. Will remove the fallback completely then. If we get a problem with the texture formats it should be easy enough to add that it falls back to RGBA8 and separate depth+stencil buffers.

On a related note, I got bloom up and running: http://imgur.com/9H0vS56

I wouldn't remove it entirely. On those crappy old Intels that one additional framebuffer copy may pose a problem, especially if a shader is being used. There must be a completely shader-less option for low end hardware. Not everything that supports GL 2.x has good shader performance.

Good point. I'll convert it into a CVAR then. For low end hardware the scene texture does have one advantage though. You can now select a lower resolution and maximize the window - that makes GZDoom render at a lower resolution and then it gets upscaled at the end. Theoretically such a feature could be extended to work for fullscreen mode as well.

dpJudas wrote:the code also relies on the GL_RGBA16F texture format and GL_DEPTH24_STENCIL8 - both of which I'm not exactly sure when they were introduced.

GL_RGBA16F is from EXT_packed_float and GL_DEPTH24_STENCIL8 is from EXT_packed_depth_stencil.
Availability in Apple's awesome OpenGL implementation can checked here.
As you can see it's present on all hardware with exception of ancient Intel graphics. I think it is safe to assume that availability on other platforms is better.
So it's definitely worth making this feature compatible with OpenGL 2.x.

dpJudas wrote: Why does GZDoom only use OpenGL 2.1 on Mac? My MacBook Pro (Mid 2014) reports supporting version 4.1. My old Mac Mini (5+ years old by now) also supported some version of 3.x I'm pretty sure.

If you can make pure OpenGL 3.2 Core Profile renderer as fast as existing immediate mode one, that will be really awesome. It will be great even if it will use OpenGL 4.1 Core Profile. Also, any mod that uses own shaders should be checked but it's probably a minor problem.

_mental_ wrote:If you can make pure OpenGL 3.2 Core Profile renderer as fast as existing immediate mode one, that will be really awesome. It will be great even if it will use OpenGL 4.1 Core Profile. Also, any mod that uses own shaders should be checked but it's probably a minor problem.

To go more into detail, the problem here is getting the vertex data into the buffer. The only methods that are present in GL 3.x are mapping/unmapping the buffer and using glBuffer(Sub)Data.
Both have a huge issue with the kind of Data Doom produces: A large amount of very small vertex batches that on top of it also require some uniforms to be set.

And those limited buffer setting methods perform extremely poorly with such a setup because they generate some insane overhead, worse, that overhead can vary extremely between drivers. The spec here was an utter mess, unfortunately it took far too long to remedy it, and Apple for some reason does not update their GL implementation anymore.

Making this work would require buffering a lot of render state on the CPU side and there's just no way that throwing this much code at the problem is ever going to be faster than using immediate mode. All that maintenance will add up.

Do you think it would be possible to do it in two passes? First pass collects all the vertices and then uploads it to a buffer. Second pass runs as today, except it doesn't write the vertices - it just uses the index it would have used with persistent buffers. The tricky part is to make sure the two passes remain identical so that the indices doesn't get out of sync.

Not sure how difficult it would be to do (not familiar with this part of gzdoom yet), but maybe it would be worth it to get rid of OpenGL 2.x.

dpJudas wrote:Do you think it would be possible to do it in two passes? First pass collects all the vertices and then uploads it to a buffer. Second pass runs as today, except it doesn't write the vertices - it just uses the index it would have used with persistent buffers. The tricky part is to make sure the two passes remain identical so that the indices doesn't get out of sync.

Doable: definitely. I already do something similar for dynamic lights. But this is still significantly slower than doing it all at once because you need to run two passes over all the collected render data. For lights I had no option because the only alternative would be to use textures, and that's even more costly, but for GL 3.x hardware on Windows the current setup is faster (3.x compatibility profile), it'd only help on Macs where those do not exist.

dpJudas wrote:Not sure how difficult it would be to do (not familiar with this part of gzdoom yet), but maybe it would be worth it to get rid of OpenGL 2.x.

No, it would not get rid of GL 2.x support. Believe it or not, retro gamers often have pretty shitty computers. Some notebooks from only 4 years ago have no GL 3 support at all due to the crappy integrated graphics they come with. There's also an added problem that some first generation ATI GL 3 drivers are too buggy to actually use GL 3.

Damn - had hoped to be able to avoid the OpenGL dark ages. Oh well - will need to make the FShaderProgram class support the patching that FShader is doing.

I already tried that with GZDoom 2.0. The end result was that I had to maintain two branches - not what was planned...

Just wondering, is there some kind of decorate flag to make it not bloom?

No. Bloom is a postprocessing effect that cannot be controlled per surface. Think of it as a property of the camera that films the action, not of the items that are being filmed.

If you want it to "not bloom" simply make it darker. You'll have to hope that someone is still using tonemaps to make it white, though, otherwise they will be stuck with a gray object with no bloom effects.

That being said, I am guessing when all the dust settles and the kinks are ironed out, Bloom and Tonemaps are going to be a MAPINFO property eventually, if not already?

No. Bloom and tonemaps will strictly remain user preferences.