Vid_renderer value discrepancy between Zdoom and GZDoom

[chopkinsca]

Taken from another thread:
-In Zdoom, vid_renderer is 1 (software)
-In GZdoom, vid_renderer is 0 for software and 1 for Opengl

[MG_Man]

Actually, ZDoom doesn't even have the vid_renderer cvar, so it defaults to 1 otherwise.

[randi]

Actually, ZDoom treats it like any other unknown cvar: If it's in the config file, it loads it and sets the value but does nothing else with it.

Anyway, can't this be changed on the fly? Trying to make your map behave differently depending on the renderer sounds like bad joojoo to me. You're most definitely breaking it in multiplayer by doing that.

[chopkinsca]

Well, this map can't be played in multiplayer anyway. I was just using it to raise a wall if you were in software mode making you unable to start the OpenGL required mod.

It's alright, I found a workaround.

[Graf Zahl]

And just to avoid any further questions: It is fully intentional that GZDoom does not implement a feature to check for it because knowing some people here it will not be put to good effect by them.

[Enjay]

It's alright, I found a workaround.

I'm intrigued as to what you went for. My first thought was to make a wall with "This needs GZdoom" witten on it and hide it with a 3D floor. Or maybe make a deadly pit in front of the player start that instakills the player and hide it with a 3D floor.

[chopkinsca]

I made a large pit that you can't jump over with a message at the bottom telling you that you need GZDoom in openGL. I've covered it with a 3d floor.

[Siggi]

As stupid as that is , I'd rather fall down a pit and have a message appear than wonder what's wrong with the map when I try to finish it (and get stuck) with ZDoom.

[Cutmanmike]

I made a large pit that you can't jump over with a message at the bottom telling you that you need GZDoom in openGL. I've covered it with a 3d floor.

I WAS going to do something like that but doesn't ZDoom still make solid floors if SectorSet3dfloor is used?

Anyway, can't this be changed on the fly? Trying to make your map behave differently depending on the renderer sounds like bad joojoo to me. You're most definitely breaking it in multiplayer by doing that.

You'd be surprised how much that joojoo is required for many GZDoom only maps. What Chopkinsca has done is a rather nasty hack, and my usual method of checking the cvar and booting the player from the game using ACS is frowned upon too. We could do with a more "official" way of doing it because hardly anyone reads txt files anymore, and if they stumble across a area where there SHOULD be a 3d floor and there isn't, they're going to get confused and most likely complain.

Heck even a error message printed to the console at start up would suit me.

[Graf Zahl]

I'll be as blunt as I can:

Those idiots who don't read text files are not reason enough to do this. I absolutely hate it when I can't do some tests with certain WADs that contain some supposedly idiot-proof checks for certain features.

[Cutmanmike]

But isn't it (usually) a matter of using either ZDoom or GZDoom? Although it seems according to this bug report my checks were in vain

[Gez]

Include the following texture in your mod. In the first map played, place a GZDoom-style skybox (aka Unreal or Quake II skybox), with the sky visible right at the start. The software renderer cannot render these skyboxes and will thus use -NOFLAT- instead, which will make a sky full of this message. This doesn't hamper gameplay in any way.

[Cutmanmike]

That's one crazy ass way to do it, but at least it gets the message across

[Enjay]

I absolutely hate it when I can't do some tests with certain WADs that contain some supposedly idiot-proof checks for certain features.

I'd never really thought about that. It seems a good enough reason for it not to be included to me.

[HotWax]

But surely providing a simple, maintainable method to display an error on the screen when the user begins the game with the wrong port cannot be that harmful? In fact, since map authors would then use it instead of implementing nasty hacks, wouldn't this make things much better?

For example, a MAPINFO (or whatever) flag could be added, and if present the game would do a simple check, see that the game doesn't match, and display an error (nothing more!) to the screen informing the user of such. If they want to go ahead and ignore it, they should then not be surprised when they reach an area where things aren't working properly. And since there are no pits-of-death, error messages in the sky, etc. present to hamper testing, this should make things easier for Graf as well.

I almost see this feature as a prerequisite to getting the UDMF format on its feet...