vid_renderer

[gwHero]

Hi,

I noticed that with the latest devbuilds vid_renderer is gone. I use this cvar to display a warning on the hud if the user starts my TC with the software renderer (vid_renderer !=1), because the software renderer does not support several features I use like 3d slopes and flatsprites. What will be the way to check this in the future releases of GZDOOM ?

[_mental_]

Now it's vid_rendermode CVAR, 4 means hardware renderer.

[gwHero]

Now it's vid_rendermode CVAR, 4 means hardware renderer.

Thank you!

[Graf Zahl]

How many times did people tell you not to rely on CVARs for that? With the latest code, the user can switch between renderers at run time, meaning that most renderer related kill switches will break anyway. (That is, execpt for the one in Lilith which wasn't a renderer kill switch but something far nastier - rendering the mod totally inoperable on anything beyond ZDoom 2.8.1.)

In short: Don't do that! By now most assumptions of such a check no longer apply.

[gwHero]

How many times did people tell you not to rely on CVARs for that?

Nobody ever. I did not know that.

In short: Don't do that! By now most assumptions of such a check no longer apply.

So how do I solve this if this method is not the correct way? (btw I can check if a cvar is null, so I can check which cvar is applicable if the user is using 3.3 or older or 3.4 or newer)

[Rachael]

So how do I solve this if this method is not the correct way? (btw I can check if a cvar is null, so I can check which cvar is applicable if the user is using 3.3 or older or 3.4 or newer)

You don't solve that. Leave vid_renderer and vid_rendermode alone. Don't use them at all - ever. Please.

[Chris]

The best way to handle it is to simply tell people that, as of the current version, it needs the OpenGL render to display correctly. But don't assume that OpenGL (or non-software) will be the only option to ever handle the effects you use. For example, at one point 3D floors were only possible with the hardware renderer, but now they're usable with software. Same with dynamic lights or truecolor visuals. There's nothing to say what each of the renderers will be capable of handling in the future (there's currently three, BTW -- the original software Carmack renderer, a software polygonal renderer, and the OpenGL renderer -- with a potential fourth one coming in the future using Vulkan).

[gwHero]

You don't solve that. Leave vid_renderer and vid_rendermode alone.

Yes, I understood that from Graf's post. Up till now I did not know that it was discouraged to check the values of certain read only cvars like vid_renderer. But I am still looking for a way to check if the user has chosen a renderer that does not support certain features like 3d slopes of flat sprites, simply because my mod would look malformed if the user would choose the wrong renderer.

If there is no such way for modders available yet - I can understand that you want to keep the status of vid_rendermode internal to the engine - I could raise a feature request to add a flag for modders like this, certainly after reading the comments of Chris:

Code: Select all

enum RendererFeatureSupport
{
	RFSUPPORT_3DSLOPES = 1,
	RFSUPPORT_FLATSPRITES = 2,
	RFSUPPORT_WALLSPRITES = 4,
// etc whatever more differences exist between the support for certain features in a chosen renderer
};

I think this could be an easy way to set this flags in the engine so that mods that depend on these kind of settings could issue a warning to the user without depending on the internal cvars.

[Rachael]

Don't display a warning at all. Just don't. That's the best way to handle this.

That code you posted does exist already, but nobody bothers using it. It makes certain objects hidden or exclusive when a rendering feature is missing.

[Xaser]

Both sides of this coin suck. The problem from a modder/user perspective is that when a lay user (i.e. not a ZDoom veteran) has the wrong renderer selected, it's not obvious what the problem is -- they'll just see weird visual glitches and quite possibly assume something's wrong with the map. Since expecting folks to RTFM is a total crapshoot, I'd much appreciate the ability to deliver just-in-time feedback to the user. It minimizes frustrations all 'round.

But on the flipside, checking the renderer is indeed the incorrect thing to do, since it makes big assumptions about what's supported (software truecolor being a recent defiance). So that won't do.

What we could really use here is a new feature: a set of MAPINFO flags that declare "I require feature 'x'", e.g. sloped 3D Floors or Truecolor, and have the engine output a warning if a user starts up the map with a renderer that doesn't support one of the declared features. This doesn't expose anything to ZScript, and since it's detecting the feature, not the renderer, it's future-proof -- e.g. if the Carmack renderer magically gets sloped 3D floors, it's marked as supported internally and the warning goes away for maps that declare it.

[Rachael]

I would actually agree to this. It might pick up more adoption than the renderhide/show feature did, and most of the groundwork for it is already laid thanks to it.

[gwHero]

Both sides of this coin suck. The problem from a modder/user perspective is that when a lay user (i.e. not a ZDoom veteran) has the wrong renderer selected, it's not obvious what the problem is -- they'll just see weird visual glitches and quite possibly assume something's wrong with the map. Since expecting folks to RTFM is a total crapshoot, I'd much appreciate the ability to deliver just-in-time feedback to the user. It minimizes frustrations all 'round.

But on the flipside, checking the renderer is indeed the incorrect thing to do, since it makes big assumptions about what's supported (software truecolor being a recent defiance). So that won't do.

What we could really use here is a new feature: a set of MAPINFO flags that declare "I require feature 'x'", e.g. sloped 3D Floors or Truecolor, and have the engine output a warning if a user starts up the map with a renderer that doesn't support one of the declared features. This doesn't expose anything to ZScript, and since it's detecting the feature, not the renderer, it's future-proof -- e.g. if the Carmack renderer magically gets sloped 3D floors, it's marked as supported internally and the warning goes away for maps that declare it.

I totally agree with what Xaser states here; would be a great solution.

[ketmar]

actually, as it is now possible to switch renderers on the fly, the engine should ask the user if he wants to temporarily switch to the working engine for a given map(set), i think.

[Rachael]

actually, as it is now possible to switch renderers on the fly, the engine should ask the user if he wants to temporarily switch to the working engine for a given map(set), i think.

If you want to code that, pull requests are accepted - but under no circumstance will it be accepted if the user simply specifies a renderer type and nothing more. There needs to be a check for a missing feature for this to happen - in case the software renderer catches up to OpenGL in terms of features.

[ketmar]

of course, i meant "the engine is capable to choose a renderer based on features from MAPINFO", as Xaser proposed. that is, simply displaying a warning won't do anything good: the user who needs such warning usually don't know (and don't want to know) what "renderer" is, and even less he wants to dig into gzdoom options menu (it is scary even for me, and i maintain a fork, and semi-maintain private doom source port!).

what i meant is that: "after Xaser's proposal will be implemented, don't stop at simply displaying a warning, but offer some sensible action, so user can press 'ok, i agree' button and Just Play."