[UPDATED] ZDoom32 2.8.5 (ZDoom is undead)

Game Engines 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.

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

Postby _mental_ » Sun Aug 13, 2017 4:40 am

I cannot check at the moment, will to it later. Debug configuration was built by VS2015 from gzdoom32 branch.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby drfrag » Sun Aug 13, 2017 5:47 am

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

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

Postby _mental_ » Mon Aug 14, 2017 2:29 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby drfrag » Mon Aug 14, 2017 5:12 am

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

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

Postby _mental_ » Mon Aug 14, 2017 5:47 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby drfrag » Tue Aug 15, 2017 3:47 am

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

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

Postby dpJudas » Tue Aug 15, 2017 4:26 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

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

Postby drfrag » Tue Aug 15, 2017 5:38 am

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
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

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

Postby drfrag » Tue Aug 15, 2017 7:18 am

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 allExpand view
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[i]==this)". I'm using gcc 4.9.2.

Code: Select allExpand view
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
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

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

Postby drfrag » Wed Aug 16, 2017 4:24 am

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).
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

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

Postby _mental_ » Wed Aug 16, 2017 5:52 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby drfrag » Wed Aug 16, 2017 11:26 am

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 allExpand view
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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

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

Postby _mental_ » Thu Aug 17, 2017 1:13 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

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

Postby drfrag » Thu Aug 17, 2017 6:16 am

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 allExpand view
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 allExpand view
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
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

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

Postby drfrag » Fri Sep 08, 2017 3:29 am

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

PreviousNext

Return to Game Engines

Who is online

Users browsing this forum: No registered users and 0 guests