GZDoom 2.0.02 Third beta release

News about GZDoom.

Moderator: Graf Zahl

Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

Edward-san, that compile error looks weird, since it's apparently being caused by a warning setting [-Wc++11-narrowing]. What compiler are you using?
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

I was able to make the flickering door reproduce on my system under both windows and linux.

Turning off fog solves the flickering.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

The burn wipe works for me. But I made some changes to the shader source recently. Can it be that you somehow still load the old shader with the new executable? That would explain this effect.
Edward-san
Developer
Developer
Posts: 197
Joined: Sun Nov 29, 2009 16:36

Re: GZDoom 2.0.02 Third beta release

Post by Edward-san »

Ralgor wrote:Edward-san, that compile error looks weird, since it's apparently being caused by a warning setting [-Wc++11-narrowing]. What compiler are you using?
Clang 3.5. Actually, I passed '-std=c++11' as an additive compiler flag, because there's this code in gl_vertexbuffer.h:

Code: Select all

	const unsigned int BUFFER_SIZE = 2000000;
	const unsigned int BUFFER_SIZE_TO_USE = 1999500;
Which is a C++11 extension, as these two variables are not static, so this declaration would not work on C++98. A fix for C++98 would be to add 'static' to both the declarations.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

I thought I recognized the Clang warning style. I wasn't sure though.

The thing is that Graf is using VS 2013, which supports SOME C++11 features, including this one. But anyone developing on a modern C++ compiler will have to be careful not to use something outside of what VS 2013 supports. Here is a table showing what c++11 features various versions of Visual Studio support. It looks like this particular feature was only added with VS2013, so more than likely GZDoom 2.0 doesn't compile with any of the older Microsoft compilers either.

I think at this point, -std=c++11 should be used for gcc and clang compiles going forward. I just hope VS 14 actually supports the rest of the C++11 standard.

On a related topic, I tried to compile GZDoom using Clang for Windows inside of VS2013. Some things compiled, but I ran into some issues and didn't pursue it further.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

That's a common problem: You inadvertantly use some newer language features, and since you are on a compiler supporting them there is no warning. And then users of older compilers complain.

Still, I wonder whether it makes much sense to restrict oneself with using new language features. After all, the VC2013 Express download is free of charge, just like previous versions, and I'd really like to be less conscious about such things. Even though I'm not too thrilled about how many programmers are starting to use C++, there's still lots of good stuff in there.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

Edward-san wrote:Also, I noticed a strange flickering effect with a door in ZDoomEditDemo_v1_2.pk3 in map02. See the screenshot with the coordinates:

[spoiler]Image[/spoiler]

Can you give me a link to that map?

I fixed the rest of your issues, but I can't find that demo map by searching for the file name.
Edward-san
Developer
Developer
Posts: 197
Joined: Sun Nov 29, 2009 16:36

Re: GZDoom 2.0.02 Third beta release

Post by Edward-san »

Here: http://www.mediafire.com/?dxmoxb3fex64jmf

Anyways, your changes to the signedness of 'size*' in gl_lightbuffer.cpp made two checks completely pointless:

Code: Select all

int diff = totalsize - mBlockSize;

size2 -= diff;
if (size2 < 0)
{
	size1 += size2;
	size2 = 0;
}
if (size1 < 0)
{
	size0 += size1;
	size1 = 0;
}
totalsize = size0 + size1 + size2 + 1;
size2 and size1 will never be negative.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

Grrr...


See, that's what you get for having the compiler spill pointless warnings.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

That wad can be found through this link: http://zdoom.org/wiki/ZDoom_Editing_Demo

The links have apparently been broken a few times. If none of them work, I can upload it somewhere.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

I already got it, but the error does not appear. It looks fine.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

I decided to go back and test 1.8.6. I get the error in that version as well.

That particular door is a polyobject. The other doors (and the rest of the room) are fine.

The fog and the door are Z fighting, from the looks of it.
Ralgor
Posts: 22
Joined: Mon Sep 01, 2014 21:59

Re: GZDoom 2.0.02 Third beta release

Post by Ralgor »

So this may absolutely be the wrong fix for the fog issue, but...

I changed GLWall:RenderFogBoundary to use glPolygonOffset (like the decal renderer does) and it seemed to fix the issue, without causing any obvious problems:

[spoiler]

Code: Select all

void GLWall::RenderFogBoundary()
{
	if (gl_fogmode && gl_fixedcolormap == 0)
	{
		int rel = rellight + getExtraLight();
		gl_SetFog(lightlevel, rel, &Colormap, false);
		gl_RenderState.SetEffect(EFF_FOGBOUNDARY);
		gl_RenderState.AlphaFunc(GL_GEQUAL, 0.f);
		glEnable(GL_POLYGON_OFFSET_FILL);
		glPolygonOffset(-1.0f, -128.0f);
		glDepthMask(false);
		RenderWall(RWF_BLANK);
		glDepthMask(true);
		glPolygonOffset(0.0f, 0.0f);
		glDisable(GL_POLYGON_OFFSET_FILL);
		gl_RenderState.SetEffect(EFF_NONE);
	}
}
[/spoiler]

I don't know if this is the correct way to fix it or not. I just took a stab in the dark.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: GZDoom 2.0.02 Third beta release

Post by Graf Zahl »

The z-fighting with the polyobject is basically unavoidable without some tinkering with the depth value. Use glPolygonOffset should be fine, it's also being used for other stuff that may cause similar overlaps with almost-matching depth values.
Edward-san
Developer
Developer
Posts: 197
Joined: Sun Nov 29, 2009 16:36

Re: GZDoom 2.0.02 Third beta release

Post by Edward-san »

Now the door renders fine for me. I noticed that if I open the door, I get these strange effects on the corner of the door: here a list of screenshots.
Locked

Return to “News”