[UPDATED] ZDoom32 2.8.6a (ZDoom is undead)

Game Engines like EDGE, LZDoom, QZDoom, ECWolf, and others, go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by _mental_ »

I cannot check at the moment, will to it later. Debug configuration was built by VS2015 from gzdoom32 branch.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

Thanks very much! Take your time. Yesterday i applied a commit By Graf to fix some crashes. I've provided a MinGW test build just in case.
Steps to reproduce: switch to the GL renderer, start a new game and change video resolution at least twice (even the current resolution will do).
Some font chars will disappear or change to other graphics with subsequent mode changes.

This old engine still has its cool factor. Any clues from other devs would also be welcome, the link will be alive for a few days.

http://www.fileconvoy.com/dfl.php?id=g8 ... 4dec002a77

Edit: don't forget that the software renderer is the default. Brightmaps and lights are autoloaded.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by _mental_ »

I managed to reproduce the issue. But I cannot say what's wrong with video resolution switching.
From apitrace's capture it seems that wrong OpenGL texture IDs are bound to particular engine textures. Have no idea where it breaks though.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

Thanks for looking into it. If you have no idea i cannot even dream of having an idea. It only happens after switching resolution twice and only after starting a new game. Could you please confirm that the problem wasn't already there in the g1.x branch? Since i would need to apply all those MinGW patches and they need to be tailored for each specific engine version.
Of course Graf Zahl could bring some light but i know he's pretty busy. I don't even know which module i should check.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by _mental_ »

The latest commit to g1.x branch tagged as g1.10pre-1359-g6a8e60c works fine.

EDIT: By the way it somehow related to dynamic lights. If this feature was not enabled since GZDoom start video mode switching will work fine.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

I've been reviewing changes to the dynamic light code but i've found nothing. Only that i forgot to remove a comment in a_dynlight.cpp. I don't think it's a problem with the lights themselves.
It's been 8 months of ZDoom development after the g1.x branch. It could also be related to the addition of the truecolor renderer (now doesn't look like), but i've tried some things without luck.
We could introduce a hack but i can't think of anything, disabling lights before the mode change won't help since they need to be disabled before starting a game.

Hope Rachael and dpJudas can have a look at it sometime.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by dpJudas »

I'm sorry, I don't know anything about the old GL renderer from back then. Fixed-function OpenGL is probably as far away from my interests as you can get to be honest.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

Sorry, i meant in case the problem is related to the addition of the truecolor renderer (and of course if we cannot fix it ourselves which i'm afraid is very unlikely ATM). This looks like a serious challenge.

I didn't know the old renderer was that different (i think the old lighting method is still there in the legacy render path). But somehow seems like the problem is in the video mode change code.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

It's fixed but now it crashes on exit again. It's in the Fmaterial destructor.
I introduced the bug with the "Fixed crash on exit with GCC" commit but this didn't cause any problem with GZDoom 2.2. :oops:
Now i don't know how to fix the crash on exit. The commented line gives a warning:
gl_material.cpp|738|warning: passing NULL to non-pointer argument 1 of 'TArray<T, TT>::TArray(int) [with T = FMaterial*; TT = FMaterial*]' [-Wconversion-null]

Code: Select all

FMaterial::~FMaterial()
{
	for(unsigned i=0;i<mMaterials.Size();i++)
	{
		if (mMaterials[i]==this)
		{
			mMaterials.Delete(i);
			//mMaterials = NULL;
			break;
		}
	}
}
Edit: attached gdb log. Line 735 is "if (mMaterials==this)". I'm using gcc 4.9.2.

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x005787d7 in FMaterial::~FMaterial (this=0xcb9ef68, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\gl\textures\gl_material.cpp:735
C:\DEV\qzdoom\src\gl\textures\gl_material.cpp:735:21843:beg:0x5787d7
>>>>>>cb_gdb:#0  0x005787d7 in FMaterial::~FMaterial (this=0xcb9ef68, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\gl\textures\gl_material.cpp:735
#1  0x00576824 in FTexture::MiscGLInfo::~MiscGLInfo (this=0x8467518, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\gl\textures\gl_texture.cpp:249
#2  0x007bb6e3 in FTexture::~FTexture (this=0x84674c0, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\textures\texture.cpp:172
#3  0x007ba896 in FPNGTexture::~FPNGTexture (this=this@entry=0x84674c0, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\textures\pngtexture.cpp:353
#4  0x007ba8bb in FPNGTexture::~FPNGTexture (this=0x84674c0, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\textures\pngtexture.cpp:366
#5  0x007bdac0 in FTextureManager::DeleteAll (this=this@entry=0x2087700 <TexMan>) at C:\DEV\qzdoom\src\textures\texturemanager.cpp:102
#6  0x007bdca2 in FTextureManager::~FTextureManager (this=0x2087700 <TexMan>, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\textures\texturemanager.cpp:89
Edit 2: Replacing "mMaterials = NULL" with "mMaterials.Clear()" the problem of missing fonts appears again.
Seems like some data is still being used after calling the destructor, isn't the destructor supposed to destroy everything?
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

I've added a hack to prevent the crash using another boolean global variable (one more won't hurt right?).
Previously i tried modifying the destructor to clean everything and adding another Delete method to FMaterial to do what the destructor did calling it from the destructor of MiscGLInfo but still crashed (not in the debugger).
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by _mental_ »

I doubt that mMaterials = NULL; line is correct, it's a call to TArray(int max) constructor with max equal to zero.
The first destructed material will also discard all others, they will just leak.

Does build without this line crash in Debug configuration? And post whole callstack please.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

True, it was not right since behavior of malloc depends on the implementation. I've fixed it this time for real.
This is a RelWithDebInfo build, Blzut3's gcc build also crashed on exit. 1.8.4 doesn't crash with gcc but that problem has been there in GZDoom for a long time.

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x005787d7 in FMaterial::~FMaterial (this=0xcb9ef68, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\gl\textures\gl_material.cpp:735
C:\DEV\qzdoom\src\gl\textures\gl_material.cpp:735:21843:beg:0x5787d7
>>>>>>cb_gdb:#0  0x005787d7 in FMaterial::~FMaterial (this=0xcb9ef68, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\gl\textures\gl_material.cpp:735
#1  0x00576824 in FTexture::MiscGLInfo::~MiscGLInfo (this=0x8467518, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\gl\textures\gl_texture.cpp:249
#2  0x007bb6e3 in FTexture::~FTexture (this=0x84674c0, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\textures\texture.cpp:172
#3  0x007ba896 in FPNGTexture::~FPNGTexture (this=this@entry=0x84674c0, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\textures\pngtexture.cpp:353
#4  0x007ba8bb in FPNGTexture::~FPNGTexture (this=0x84674c0, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\textures\pngtexture.cpp:366
#5  0x007bdac0 in FTextureManager::DeleteAll (this=this@entry=0x2087700 <TexMan>) at C:\DEV\qzdoom\src\textures\texturemanager.cpp:102
#6  0x007bdca2 in FTextureManager::~FTextureManager (this=0x2087700 <TexMan>, __in_chrg=<optimized out>) at C:\DEV\qzdoom\src\textures\texturemanager.cpp:89
#7  0x76afc3e9 in msvcrt!isspace () from C:\Windows\system32\msvcrt.dll
#8  0x76b036bb in msvcrt!exit () from C:\Windows\system32\msvcrt.dll
#9  0x00427392 in ST_Endoom () at C:\DEV\qzdoom\src\win32\st_start.cpp:1132
#10 0x004b1a65 in DQuitMenu::HandleResult (this=<optimized out>, res=true) at C:\DEV\qzdoom\src\menu\messagebox.cpp:414
#11 0x004b1a29 in DMessageBoxMenu::MenuEvent (this=0xcb9f520, mkey=6, fromcontroller=false) at C:\DEV\qzdoom\src\menu\messagebox.cpp:286
#12 0x004a7bdd in M_Responder (ev=ev@entry=0x1c261a0 <events+224>) at C:\DEV\qzdoom\src\menu\menu.cpp:621
#13 0x005e8488 in D_ProcessEvents () at C:\DEV\qzdoom\src\d_main.cpp:281
#14 0x005f0fed in NetUpdate () at C:\DEV\qzdoom\src\d_net.cpp:978
#15 0x005f1c86 in TryRunTics () at C:\DEV\qzdoom\src\d_net.cpp:1833
#16 0x005ea0c0 in D_DoomLoop () at C:\DEV\qzdoom\src\d_main.cpp:1013
#17 0x005ed3ab in D_DoomMain () at C:\DEV\qzdoom\src\d_main.cpp:2658
#18 0x0042091b in DoMain (hInstance=hInstance@entry=0x400000) at C:\DEV\qzdoom\src\win32\i_main.cpp:1034
#19 0x00420fb6 in WinMain@16 (hInstance=0x400000, nothing=0x0, cmdline=0x6a32414 "", nCmdShow=10) at C:\DEV\qzdoom\src\win32\i_main.cpp:1332
#20 0x009e270b in main ()
>>>>>>cb_gdb:Continuing.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by _mental_ »

drfrag wrote:True, it was not right since behavior of malloc depends on the implementation. I've fixed it this time for real.
It's not related to malloc() at all. I'm talking about pure logic error when particular syntax obscures actual semantics of the code.
The problem is in TArray(int max) constructor that declared without explicit keyword allowing such things like assigning a pointer to a container.

At the moment I have no time to check further but it seems the crash related to unspecified order of static/global object destruction: FMaterial::mMaterials and TexMan.
If the first object is destroyed before the second you will get this problem because the latter accesses static materials array in its destructor.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

I thought that DoDelete actually freed the memory. It doesn't matter here but that would be a problem with the glzdoom32 branch or GZDoom itself. The problem with malloc is that ZDoom could crash in M_Malloc if malloc returns a null pointer (works with gcc).
I added the following code to the destructor (it's in the repo):

Code: Select all

FMaterial::~FMaterial()
{
	for(unsigned i=0;i<mMaterials.Size();i++)
	{
		if (mMaterials[i]==this)
		{
			mMaterials.Delete(i);
			break;
		}
	}

	if (exiting) // hack hack
	{
		mMaterials.Clear();
		TArray<FMaterial *> null;
		mMaterials = null;
	}
}
Edit: fixed the memory leak.

Code: Select all

FMaterial::~FMaterial()
{
	for(unsigned i=0;i<mMaterials.Size();i++)
	{
		if (mMaterials[i]==this)
		{
			mMaterials.Delete(i);
			break;
		}
	}

	if (exiting) // hack hack
	{
		mMaterials.Clear();
		mMaterials.ShrinkToFit();
	}
}
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3141
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain
Contact:

Re: [RELEASED] ZDoom32 2.8.2 (ZDoom is undead)

Post by drfrag »

What's in my gzdoom repo (https://github.com/drfrag666/gzdoom, copied from README.md):

Some ZDoom based legacy ports with lower system requirements for Windows 9x or later and older hardware.
Some branches are discontinued from now on (SEP 04 2017).

- gzdoom32 branch:
ZDoom32 is a fork of truecolor ZDoom by dpJudas and Rachael and a later ZDoom (https://github.com/rheit/zdoom).
It's a merge of dpJudas old truecolor branch (SEP 08 2016) and ZDoom master as of DEC 03 2016.
Now merged with the GZDoom g1.x branch (APR 24 2016).

- glzdoom32 branch:
A merge of ZDoom32 with a later GZDoom master (roughly 2.2) from NOV 17 2016 with later fixes. Discontinued.

- zdoom32 branch:
Old ZDoom32 2.8.2 branch without the GL renderer. Discontinued.

- gzdoomle branch:
ZDoom LE (Legacy Edition) is a fork of the ZDoom 2.8.1 maintenance branch (https://github.com/rheit/zdoom/tree/maint)
for Windows 98 and old machines. Now merged with GZDoom as of august 2013 (1.8.4a).

- zdoomle branch:
Old ZDoom LE 2.8.1a branch with OpenAL for win95 (released from the ZDOOM-LE repo). Discontinued.

- zdoomcl branch
ZDoom CLASSIC 2.1.4a is a fork of ZDoom 2.1.4 for Windows 9x and pentium machines.
Now merged with GZDoom 1.0.17 with later fixes and additions.
Last edited by drfrag on Fri Sep 08, 2017 3:32 am, edited 1 time in total.
Post Reply

Return to “Game Engines”