What's up for GZDoom after running the survey?

[_mental_]

Just pushed handling of compatibility flags via ZScript.

The thing is they are applied before loading of level. Commands are applied after loading though.
I have no idea how this can be done with one function. So, we have two now, pre- and post-load.
This doesn't look very promising to be honest.

[Graf Zahl]

The only thing that MUST be applied before level load are some of the hidden flags, like 'setslopeoverflow', because they affect how the level is loaded. On the other hand, we may just leave the flags in compatibility text and save the work porting it. The more important thing is that all the post-load stuff can be done via scripting because that's where it becomes inflexible with the static data.

[_mental_]

Having two compatibility layers is a bit weird. However, I agree that they serve different purposes. Flags affect engine behavior in general while commands fix specific bugs.

[_mental_]

Scriptified almost all compatibility commands except one entry.
Back to Saturn X E1 released on /idgames has a different checksum for MAP12.
I'm not sure that compatibility is still applicable to it.

[Graf Zahl]

No, it isn't. That entry was for an older version of that map.

The final one works properly.

[_mental_]

Just to be sure, is it OK to simply remove this entry?

[Gez]

What harm does it cause to leave it around? Some people may still be using it for whatever reason. (Didn't update, for example.)

[Graf Zahl]

Nothing at all.

[Orangestar]

So to clarify, the SW renderer isn't going away entirely, it just now requires an OpenGL surface to draw to?

That's fine by me. I still use the SW renderer in Vanilla-targeting megawads that include dark sectors that rely on the SW renderer's brightening of close objects. (I can't use the Doom lighting shader in OGL mode on my system.)
Hopefully it'll run faster on my system now.

[Graf Zahl]

Correct. In order to reduce the amount of backend code everything is run through the hardware renderer now, including the 3D-scene from the software renderer.

[Phredreeke]

Does that mean GZDoom will have the ability to switch renderers without requiring a restart like in QZDoom?

[Graf Zahl]

Yes. You can already check this out if you grab one of the latest devbuilds from http://devbuilds.drdteam.org

[remus]

Maybe you could support multiple versions of opengl just like in Yamagi Quake 2. You have it anyway. You offer opengl and software.

[Rachael]

What I'd really like to see is GZDoom externalize the renderers into .dll files (or .so for non-Windows platforms) like Quake 2 did. Then all that's required is maintaining the renderers separately, they can be cut from the main executable and anyone who wants to maintain legacy renderers may do so.

[Cacodemon345]

What I'd really like to see is GZDoom externalize the renderers into .dll files (or .so for non-Windows platforms) like Quake 2 did. Then all that's required is maintaining the renderers separately, they can be cut from the main executable and anyone who wants to maintain legacy renderers may do so.

I agree with you.