[fixed?] 2 problems with 1.0.13

Post by **Enjay** » Sat Jun 03, 2006 22:09

Items in your inventory do not get shown on screen in AltHUD mode with Ver 1.0.13. They worked with 1.0.11, so something broke/changed between these versions. Seems to apply to all games and both regular and custom inventory items.

Sometimes when I start Hexen, GZDoom crashes. Hasn't happened with other games, but has a few times with Hexen. Crash log attached. Launched via ZDL.

Post by **Graf Zahl** » Sat Jun 03, 2006 22:17

I hate this crash. It has been there for several versions now. The problem is, I can't track it down. It only happens to me when the game is started from a launcher and as soon as I add debug code it doesn't anymore.

Post by **Graf Zahl** » Sat Jun 03, 2006 22:18

Fixed the inventory problem though.

Post by **Enjay** » Sat Jun 03, 2006 22:51

Graf Zahl wrote:It only happens to me when the game is started from a launcher

Interesting. I tried pasting the command line from the crash dump ("F:\Doom\gzdoom\GZDoom.exe" -iwad "F:\Doom\gzdoom\HEXEN.WAD") into a cmd prompt session and started and re-started gzdoom loads of times (maybe 30 or more) without a single crash. However, use ZDL, or the start>run box or even a shortcut on my desktop using the same command line and GZdoom crashes about 50% of the time. So, my observations certainly back up yours - as long as you consider "launcher" in a wider sense.

chopkinsca · Post by **chopkinsca** » Sun Jun 04, 2006 2:14

Reminds me of the crashs I was getting. Even adding +logfile to command line was enough to cause the crash to not happen at all.

Post by **Graf Zahl** » Fri Jun 09, 2006 10:05

I hope it is gone now. I added a more thorough check to check for Doom patches before calling DevIL. Apparently the internal graphics format type checker in DevIL tried to access uninitialized data on occasion.

Post by **Enjay** » Fri Jun 09, 2006 11:57

Graf Zahl wrote:I hope it is gone now.

I hope so too. This crash has become pretty annoying so I'll be glad to see the back of it. Why would this problem be so sensitive to how the command line is presented to GZdoom?

Post by **Graf Zahl** » Fri Jun 09, 2006 12:04

I have absolutely no idea what was happening here. All I could do is track the crash down to some specific code and prevent its execution. I hope it helps but no guarantee.

chopkinsca · Post by **chopkinsca** » Sun Jun 11, 2006 2:54

I've had this crash again today. The only thing I was changing was decorate. It was working fine, I add a few things in decorate, then I get this error. I saved a copy of the .wad so I can test it with the next release to see if it fixes it.

TheDarkArchon · Post by **TheDarkArchon** » Sun Jun 11, 2006 20:47

I had this crash twice on my unnamed mod: Once with the Tome of Power (DevIL hated one of the sprites when it was between the SS_START/END namespace.) and once with pinky gibbing sprites which didn't crash GZDoom in another WAD. :/

EDIT: Fixes when launched from the command line as well. I'm taking a very, VERY rough guess and saying that something with another program has written into an area of memory that a Doom patch is attempted to write to and when DevIL sees this area, it has a fit.

I also doubt the file format is to blame, either: The tome crash which I sent earlier wasn't fussy on whever the sprite which appeared to trigger the crash was in patch or in a PNG

Post by **Graf Zahl** » Sun Jun 11, 2006 21:40

That's my guess as well. Somewhere in its graphics identification code DevIL massively screws up. My fix was to check every single lump for Doom patch format before calling DevIL which should reduce the chance of this happening considerably. The really annoying thing is that DevIL somehow manages to evade Windows's exception handling I put into the loading function so I can't catch the crash.

But if this continues I will have to consider switching to a different graphics library...