vid_pickrenderer option?

[Rachael]

Would there be any merit to adding this as a user cvar?

Basically what this would do is it would allow you to share your configs to ZDoom and any child port (notably right now, GZDoom and QZDoom), and upon start-up, it drops your user preferences for vid_renderer and for QZDoom, swtruecolor (I'm going to change that to a vid_variable somewhere down the line to make it consistent, or possibly just merge it with vid_renderer myself) - in order to force the source port to pick its default renderer every time it starts up.

[dpJudas]

Ideally, I'd say swtruecolor should be merged into vid_renderer as option 2.

I'm not entirely sure why vid_renderer requires a restart - maybe it could get away with just recreating the window like the swtruecolor setting is doing.

[Rachael]

vid_renderer requires a restart because re-initializing the window between OpenGL and Direct3D crashes the application, and that was discovered the hard way when ZDoom switched to Direct3D rendering.

I don't know if it actually can be done - but perhaps destroying the window completely and recreating it might work. Graf probably has a lot more experience and wisdom than I do about this. Personally I'd like to be able to switch back and forth on the fly, again.

[Graf Zahl]

Originally vid_renderer worked without a restart, but when ZDoom got the D3D backend this stopped working, it just wasn't possible anymore to switch between D3D and OpenGL without causing some serious issues. Since then I never revisited that code.

[Rachael]

Maybe what would be more ideal is having a universal .ini name for ZDoom's child ports (such as zdportable.ini) that all child ports read over %theirname%_portable.ini - and if GZDoom/QZDoom detects such a file is in use, it will not save vid_renderer to such a file. (Keeping in mind, that I am probably going to go ahead and merge swtruecolor into vid_renderer as "2" like dpJudas said)

Or - vid_renderer can go into a source-port-specific header, also (like [program.ZDoom], [program.GZDoom]) - that would require some changing to the CVar code but hopefully it wouldn't be too extensive.

[Graf Zahl]

It's really too bad that the D3D backend was written as a means to all ends - how nice would it be to have an OpenGL counterpart of it...

[Rachael]

I actually wish it had been written as OpenGL originally.

It might be possible to port it completely to OpenGL (2.1 or something) since all it's doing is using it as a canvas, and not actually drawing polys with it. Then change "vid_forceddraw" to "vid_swcanvas" to accept "directdraw/ddraw", "direct3d/d3d", or "opengl/ogl" - and if GZDoom detects that vid_swcanvas is "opengl" it can swap back to the software renderer on the fly with no issue.

On Linux and Mac you have no choice but to use OpenGL, anyway, for the SDL code, so porting it back should be even easier, considering that.

[dpJudas]

The ddraw part belongs in the dumpster. If I had to adjust any of the code in that region it would be the first to be removed. It really serves no purpose anymore and has been (re-)implemented as a basic wrapper around Direct3D since Windows Vista or maybe even XP. I seriously doubt ZDoom ever falls back to the ddraw part anymore.

I assume the 2D drawer in GZDoom is effectively an OpenGL implementation of what is in the D3D target. Probably would be easier to grab that than port over the D3D9 stuff.

[Graf Zahl]

There's one major difference between the two: GZDoom always creates 32 bit textures, it never does shader-paletting and it goes out of its way to ensure that everything gets translated correctly. I know cases where this fails in ZDoom.

Agreed about DDraw. Of course, we are talking a software rendered retro game here. Who knows what bottom-of-the-barrel system this gets played on...?

[Rachael]

I think it'll be easier to keep both targets, and just create a new OpenGL canvas system for the software renderer - mostly for allowing GZDoom to switch on the fly.

Also, ZDoom does use some shader code, but I don't think it's anything that can't be translated into GLSL.

As far as bottom-of-the-barrel systems, this can be cross-compiled from Linux for Windows (apparently, according to Blzut3's blog it is possible), and if I remember/interpreted correctly it will use SDL for this target - if that is true, then dropping ddraw entirely should be safe. This would still allow ZDoom to run on ye olde win98 systems.

The reason why I don't think dropping D3D9 is a good idea, though, is because early systems supported D3D9 beautifully, but not so much OpenGL. (ATI's and Intels are completely notorious examples of that) For people who are forced to use the software renderer, this will not only slow things down on said systems by a lot, but also possibly make ZDoom incompatible.

[dpJudas]

I'm not sure what the exact problem was earlier switching between OpenGL and Direct3D. If it was keeping the same window (hwnd), then the hack I did, where the swtruecolor cvar recreates the window, should work as it's a completely new window.

Note that I didn't suggest dropping D3D9 - just the DirectDraw fallback. But as Graf pointed out, there probably will be someone, somewhere, that somehow managed to use a system so utterly broken and useless that it can only run DirectDraw. The difference between the ZDoom project and me is that I don't CARE about such people.

[Rachael]

I'll implement on-the-fly switching in QZDoom, then, using the window recreation, and see if that works.

I need a break from true-color sprites, anyway. XD >_>

[Graf Zahl]

The difference between the ZDoom project and me is that I don't CARE about such people.

I'm with you here, but this is out of my hands. For GZDoom I was willing to bring back GL 2.x support, but no chance I'll try to make it work on GL 1.5 again. Too many compromises for that and the handful of people still using such a system can't be helped. Strange that some other ports consider these so important that it's holding back their GL implementation at 2.0 with GLSL loser edition at the very best.

[dpJudas]

I can understand people liking retro games, and I can understand people that like retro computers. What I find completely unreasonable is to expect new software (and (G)ZDoom 2016 IS new software, even if its based on an old codebase) to work on hardware and OSes that have been EOL'ed for a very very long time. If someone has an antique computer, then they should run antique stuff on it. That would be ZDoom 2005. If it doesn't run the latest mods, boohoo, buy a new computer. Or keep running the 2005 mods along with anything else from that age.

From my perspective, the only point a software renderer has left is to give retro people that like palette graphics to still get that. And then of course as a playground to do utterly pointless stuff just because we can, such as the true color renderer. For the former lot, it would probably be better to port the renderer to OpenCL or as a compute shader.

Those competitors to GZDoom that insist on old GL will eventually run out of modders and new blood. The users they worked so hard to support will eventually buy a new computer, and then they switch to GZDoom because it looks better, because it uses a modern OpenGL.

[Rachael]

As far as live switching: I haven't been able to get it to de-initialize the OpenGL renderer, and looking through code buried through the ages has made it very difficult. I don't even know when ZDoom had its first working D3D9 renderer, but I know it was sometime after 2006 - I just don't know how long after, I think it was before Grubber passed DRD Team to me.

Code that old may not even be that useful, although it may give some clue as to how it switched it on and off - though that information may be useless, as well, now.