Tue Apr 10, 2018 6:21 am
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.
Tue Apr 10, 2018 6:56 am
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.
Tue Apr 10, 2018 7:18 am
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.
Wed Apr 11, 2018 8:05 am
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.
Wed Apr 11, 2018 9:08 am
No, it isn't. That entry was for an older version of that map.
The final one works properly.
Wed Apr 11, 2018 9:25 am
Just to be sure, is it OK to simply remove this entry?
Wed Apr 11, 2018 10:57 am
What harm does it cause to leave it around? Some people may still be using it for whatever reason. (Didn't update, for example.)
Wed Apr 11, 2018 11:01 am
Nothing at all.
Fri Apr 13, 2018 12:32 pm
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.
Fri Apr 13, 2018 12:36 pm
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.
Mon Apr 16, 2018 9:07 am
Does that mean GZDoom will have the ability to switch renderers without requiring a restart like in QZDoom?
Mon Apr 16, 2018 1:22 pm
Yes. You can already check this out if you grab one of the latest devbuilds from http://devbuilds.drdteam.org
Sun May 06, 2018 10:13 am
Maybe you could support multiple versions of opengl just like in Yamagi Quake 2. You have it anyway. You offer opengl and software.
Sun May 06, 2018 10:39 am
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.
Sun May 06, 2018 11:22 am
Rachael wrote: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.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.