DRD Team

If GZDoom is using the software renderer, executing either reset2defaults or reset2saved crashes to the handler. If either of these are executed at startup via command line, it crashes before the the titlescreen appears. This crash happens regardless of what the value of vid_renderer is in the .ini (and so also happens if +vid_renderer 0 is executed at startup).

GameFreakDude wrote:If GZDoom is using the software renderer,...

GZDoom does not use the software renderer, this linked to thread explains it all

https://www.doomworld.com/vb/source-por ... re-toggle/

Ah, I see that you did not read the linked thread in it's entirety.

First of all, the thread is 3 years old. Graf Zahl already mentioned then that he is not
interested in bringing back the option to run GZDoom in the software renderer. If you
want to use the software renderer, then simply run ZDoom,

Secondly, the option to disable the OpenGL system was removed somewhere around
GZDOOM 1.4.8 (r762) Mar.29, 2010, six generations of GZDoom ago.

@NeoHippo:

Please refrain from posting if you do not first verify the facts. While it is true that some options have been removed, the software renderer can still be selected from the command line by passing '+vid_renderer 0'.

I can actually confirm the reported crash by performing the described actions with my latest build.

fixed

Thanks, Graf!

@ GameFreakDude
Sorry about that
Obviously I lost something in the translation.

Reading originally and rereading now the linked thread, my understanding was/is that the command vid_renderer 0 was unreliable. From what GZ had typed then I took it that he did not want to correct the vid_renderer 0 command. Good to know that he fixed it now and this command is reliable again.

While at it, I wonder if GZ would be interested in a working restart command instead of going through quitting and rerunning the game.

I'd like to have that - but it's simply not possible to switch from D3D to OpenGL and vice versa without an application restart. D3D seems to hook itself somewhere into the window and never releases that hook when it gets shut down. As a result OpenGL will crash.

I've never been able to resolve this problem. I don't even know if it's just a problem with ZDoom's (rather messy) startup code or with the rendering APIs.

What if ZDoom got an OpenGL backdrop as a replacement or alternative to D3D? The same way software rendered ports like Chocolate Doom or Eternity use OpenGL now.

That would be an option - if I could make some sense out of the messed-up D3D code, which looks far - far too convoluted for its purpose.

An OpenGL backend would also be usable for ZDoom on non-Windows, but it's a task I'm not going to start alone