Page 1 of 1
[r296] Fatal crash after GZDoom startup.
Posted: Wed Jan 28, 2009 15:08
by playerlin
My GZDoom crashed after GZDoom startup.
(When the main menu appears then it crashed after about 2 seconds.)
And when I close the "Fatal crash window" , the console window(GZDoom's) still no respones, I must force to close it.
I backup and killed my old ini file and it works fine again.
I changed to use r295 and it totally fine with my ini.
Now I still use r295. I'm lazy to reset my whole old setting...
Posted: Fri Feb 13, 2009 9:17
by playerlin
Update : I try use command-line argument "-nosound" and it totally works fine.
Oh ****, not again...
Damnit...looks like it's fmod's problem again.
Posted: Fri Feb 13, 2009 12:49
by Enjay
If you are using the builds from the DRD SVN downloads, can you check the versions of FMODEX.DLL that come with the different downloads? I don't think I updated FMODEX between r295 and r296 but I can't be certain and I have no way to check.
Posted: Sat Feb 14, 2009 13:19
by playerlin
Yeah, I use DRD SVN Build.
r297-r300 still use FMOXEX.DLL v4.20.6. And still crashed like r296.
Posted: Sat Feb 14, 2009 20:16
by Enjay
OK, I just updated to FMODEx 4.22.04 and rebuilt r300. You can get it off the DRD SVN server if you fancy giving it a go.
Posted: Sun Feb 15, 2009 10:06
by playerlin
Enjay wrote:OK, I just updated to FMODEx 4.22.04 and rebuilt r300. You can get it off the DRD SVN server if you fancy giving it a go.
*Sigh*
It still crashed...
EDIT : I found the problem source...
in my old ini :
Code: Select all
[GlobalSettings]
.
.
.
opl_onechip=true
.
.
.
.
I change that to "opl_onechip=false" and my GZDoom is no longer crash.
It doesn't happens on Zdoom r1418 and r1424M.
(I only do "opl_onechip=true", maybe that isn't matter...)
Damn, I should do ini cvars check early... *doh*
Posted: Sun Feb 15, 2009 15:04
by Rachael
hmmm... Setting opl_onechip=true on my computer doesn't crash anything, it may be your hardware or drivers causing the problem. There's a lot of really crappy drivers out there.
Posted: Mon Feb 16, 2009 6:40
by playerlin
SoulPriestess wrote:hmmm... Setting opl_onechip=true on my computer doesn't crash anything, it may be your hardware or drivers causing the problem. There's a lot of really crappy drivers out there.
I'll try update the onboard sound driver and check if it still crash.
EDIT : *Sigh* It still crash even I update to Realtek's latest driver...
I don't get it...or it's OS related problem...
I just curious what changes in r296... because it crashed after r296 builds.
And why ZDoom doesn't crash even I set "opl_onechip=true"...
(Like I said on my previous post, ZDoom r1418 and the latest build r1424M are works fine. It's so weird...
)
Posted: Mon Feb 16, 2009 11:56
by Enjay
Changes in r296
Code: Select all
Update to ZDoom r1369:
- fixed some issues with P_FindFloorCeiling's coordinate processing.
- added a new compatmode CVAR which allows setting some generic compatibility
flag combinations:
Doom: sets the options needed to make most Doom.exe compatible map play without
errors.
Doom (strict): Same as above but sets a few more options. Please note that this
does not mean full Doom.exe behavior emulation.
Boom: Sets all options that consider differences between ZDoom and Boom.
ZDoom 2.0.63: Sets only the COMPATF_SOUNDTARGET option which is needed for
many older ZDoom maps.
- added new COMPAT_CROSSDROPOFF option to block monsters from being pushed over
dropoffs by damage kickback.
- fixed: AFastProjectile::Tick must call Effect only 8 times per tic, regardless
of the amount of steps taken.
- fixed: momentum checks in AFastProjectile did not use absolute values.
- Restored the rhythm section to fmopl.cpp and made some slight updates from
version 0.72 of MAME's fmopl.c. Also refactored CalcVoice so that the
original MAME structure is more visible.
- Removed the SoundChans bitfield from AActor, since it seems there are race
conditions I don't fully understand where it simply doesn't work.
- Removed BaseTime initialization from sdl/i_system.cpp as per Chris's
recommendation.
Looks like all those changes come from the update to a newer revision of Zdoom, but there is certainly some sound related stuff in there. Have you tried Zdoom recently?
Posted: Mon Feb 16, 2009 14:33
by playerlin
Enjay wrote:
Looks like all those changes come from the update to a newer revision of Zdoom, but there is certainly some sound related stuff in there. Have you tried Zdoom recently?
Weird, if I just use my GZDoom's ini in ZDoom, and ZDoom will crashed like GZDoom whatever r1388 or r1424M or any builds on drdteam svn server...
If I just killed my (GZDoom) ini let ZDoom re-creat new ini, then change the line "opl_onechip=" to true, and it works fine.
What the hell...?
Maybe my ini screwed up...or something else...
Posted: Sun Feb 22, 2009 10:02
by playerlin
Ok... after some test with my old and GZDoom's default ini setting.
I make a copy of my old ini and clear all entries in [GlobalSettings] then let GZDoom recreate those CVARs, then I do one-by-one testing.
Now I found the real crash source.
GZDoom (r302)'s default setting is -1 and I change it to -1 in my old ini then my GZDoom REALLY doesn't crash anymore.
Now this report can close now!
What the CVAR(snd_mididevice) mean? and why it crash with that value?
EDIT : Ok, I know what that is.
snd_mididevice = -1 -> using FMOD
snd_mididevice = -3 -> using OPL Emulate
Now it looks like if I use OPL Emulate and set "opl_onechip" to true will cause ZDoom/GZDoom crashed. Is it normal?
Posted: Sun Feb 22, 2009 10:32
by Graf Zahl
Fixed.
When opl_onechip was set the second chip was never initialized, not even to NULL so it crashed with an invalid pointer access.
There's just one thing about this report that made me think whether it would make sense to close this bug forum and make it a subforum of ZDoom's. This was clearly a ZDoom bug but since it only was reported here Randy never saw it and couldn't act on it.
Posted: Sun Feb 22, 2009 12:19
by playerlin
Graf Zahl wrote:
There's just one thing about this report that made me think whether it would make sense to close this bug forum and make it a subforum of ZDoom's. This was clearly a ZDoom bug but since it only was reported here Randy never saw it and couldn't act on it.
I feel shame now because I even can't find this bug is cause by ZDoom.
I think since GZDoom is based on ZDoom, why not just made two programs both using one "Bug Report forum"(maybe Feature Suggestions forum too)...but maybe it just not
that easy...
Posted: Sun Feb 22, 2009 18:15
by Rachael
It would all be up to randy. If that happens, though, I'm leaving these forums here for archival purposes, at least until the board is transferred to phpBB3.
It wouldn't hurt for our good friend to come by every once in a while, though.
