DRD Team

What precisely is the problem feature? If you want it fixed, tell us what needs to be done.

It's about textureOffset() functions put in the shader by FBlurShader::FragmentShaderCode() function.
According to the spec it's available in GLSL 1.30 and above. Attempts to turn on blur effect on OpenGL 2.1 lead to fatal error because of that.

Looking at how this is being used, it should be possible to work around with a bit of tinkering. Since we know the texture size the texel offset could just be added to the actual coordinate for GLSL 1.2.

Yep, it could be done as Graf says. The only catch is that textureOffset is a lot faster as it uses some specialized hardware to do it. But I guess slower is better than not working at all.

Pull request for the multisample support thing: https://github.com/coelckers/gzdoom/pull/66

I didn't use the existing gl_vid_multisample as I'm not sure if we want to keep this part of the code at all. I.e. what to do about the message it writes out to the console. Personally I vote that gl_vid_multisample is removed entirely and multisampling is only available if render buffers are. The feature relies on glRenderbufferStorageMultisample and glBlitFramebuffer, which I'm not sure when were introduced exactly (both are part of 3.0 at least).

This all appears to be part of GL_ARB_framebuffer_object, which Apple supports on compatibility profile, but there are a few very old Intel chipsets that support only GL_EXT_framebuffer_object.
Since I consider these mostly irrelevant I wouldn't bother with them any further than just disabling the feature if GL is 2.x and GL_ARB_framebuffer_object is not present.

I think adding a fallback here is reasonable, but if these start to cause more problems I wouldn't mind removing support entirely and require GL_ARB_framebuffer_object.

A bug report about your code just came in:

http://forum.drdteam.org/viewtopic.php? ... 402#p59402

I don't really know what to make of it.

_mental_ wrote:There are 4 commits in the given PR, the last one is updating your own changes. The remaining three combine bunch of features in a quite obscure way.
As an example, I pushed compatibility commits to this branch. And this is even without extension check flags which were not used yet.

On this note, there is more of a pattern in those commits than you may think. The first commit adds bloom, the second adds tonemap. The third is more of less three commits in one - but even if you split them apart you'd see them do more than strictly what the commit message advertise. I use a development style where I do a lot of small incremental refactoring as I go along to avoid second guessing what I may or may not need in the future.

As an example, the FGLRenderBuffers class now consists of a bunch of functions that aid me in supporting the primary purpose of the class (to create and manage render buffers). If I had sat down and thought about it real hard, maybe I could have realized I needed those functions from the beginning. But instead if you study the history of that class it started out with a single Setup function and some raw OpenGL calls. In the future if the class keeps growing I may reach the conclusion I need some helper classes for it not to spin out of control. On the other hand, if the class ends up not needing more buffers than it has now that extra layer of abstraction would do more harm than good (the you ain't gonna need it rule). So because I don't work with a master plan you'll always see refactoring as part of my commits - it is the middle of adding a feature I decide the old structure will no longer scale.

One example of such a future situation is the way I use the mVBO class: Every single time I draw a screen quad I have the same 6 lines repeating over. I've started to notice the pattern, but haven't fix it yet. What will happen is that the next time I need to draw a screen quad I'll finally add a DrawScreenQuad function to the VBO class and update all the old places to use it.

Anyway just wanted to mention that as that is just a way I do work.

Graf Zahl wrote:A bug report about your code just came in:

http://forum.drdteam.org/viewtopic.php? ... 402#p59402

I don't really know what to make of it.

Okay, I'll take a look at it. What is most likely going on is that a wrong frame buffer is active as it draws stuff, and that then makes the scene texture black.

Graf Zahl wrote:This all appears to be part of GL_ARB_framebuffer_object, which Apple supports on compatibility profile, but there are a few very old Intel chipsets that support only GL_EXT_framebuffer_object.
Since I consider these mostly irrelevant I wouldn't bother with them any further than just disabling the feature if GL is 2.x and GL_ARB_framebuffer_object is not present.

I think adding a fallback here is reasonable, but if these start to cause more problems I wouldn't mind removing support entirely and require GL_ARB_framebuffer_object.

Okay, I'll make it so that if the extension is not present then it will just fall back to ignoring the multisample option. That should allow us to remove the platform specific multisample code entirely.

AMAZING stuff as usual, dpJudas! Code is checked out and compiling right now, can't wait to try this out. :D

I know things are still a little shaky and you're busy fixing any bugs, but I hope you don't mind me asking just out of curiosity...

[correct me if I'm wrong] since it looks like you've implemented some post processing system into GZDoom already, do you think it would be possible to add an alternate form of mirror & sector reflection rendering that uses shaders like in modern games (screen space reflections I think is it called?) instead of however GZDoom is currently doing it? That would allow mappers to make 3D-floor deep waters that have reflective surfaces (currently this combination of setup is impossible). And of course this should be switchable for the user.

And I was just wondering if you will continue with the other effects you mentioned in the other thread (AO in particular really interests me)? And how hard would it be for modders to make new shader effects? I'd really love to implement god rays and lens flares, and that distortion effect underneath water surfaces (I think it's called refraction?) in my mod but I don't know how much interest is there in adding those as stock GZDoom effects...

Sorry for the enthusiasm, and these aren't requests, just curiosities. I'm going to have a hell of a lot of fun playing with the bloom stuff for now... ;)

Thanks again for your hard work! A lot of modders and players have longed for "fancier" graphics in GZDoom and this appears to be the start of it...

These are indeed nice additions - one little critique, however - last time I played with it, screen resizing does not work. When you shrink the screen, odd things start happening, and you cannot play GZDoom at all in any but a fully maximized viewport. (I really like my Doom status bar... *sniff*)

EDIT: Wow, okay, I just saw the bug report and the PR fix. Nicely done. Sorry. XD >_>

That should already be fixed with the latest commits.

But I also have one question: Is everything done or are there still some things/issues that need to be added/resolved?

Nash wrote:And I was just wondering if you will continue with the other effects you mentioned in the other thread (AO in particular really interests me)?

My plan was to add a few more effects (first things that doesn't require scene pass changes, then maybe later some that does). But given the regressions we had with what is in master right now, I think it is probably better to make sure the stability returns before adding anything new. I don't really have a great plan on which shaders to add, except grab some of the simpler stuff first. Something like an underwater shader maybe. That's theoretically just distorting the scene texture a little bit.

Graf wrote:But I also have one question: Is everything done or are there still some things/issues that need to be added/resolved?

The only one I'm aware of right now is the driver crash/black screen issue for ibm8851. I'm not really able to reproduce it on my Nvidia 980. Think I'll try pull it out and try see what happens if I run gzdoom with the Intel GPU on my CPU. If that doesn't crash it the only other option left is to try create some branch with a lot of extra debugging stuff layered in.

On a related note, where does the gl_load.cpp/h file come from? It looks auto-generated. I'd like to update it to include the KHR_DEBUG extension so that I can mark what our GPU objects are for Renderdoc and where the various passes begin and end. Maybe with some luck that will allow imb8851 to see the pipeline and determine when in the rendering things go wrong.

It's made by this thing:

https://bitbucket.org/alfonse/glloadgen/wiki/Home

which is the best GL extension loader I have found yet.