DRD Team

I've been trying all sorts of amateurish options to see if I can find something to narrow down the problem and all I have come across is the KDiZD texture thing I mentioned. Is there anything else I could try? Is there a way of making GZdoom step slowly through the stuff it is doing at that stage to maybe help pinpoint things?

After I fixed the '.pk3' file problem and compiled GZDoom it worked fine. Graf, you could try compiling again then reuploading.

The pk3 is current. That can not be the case. I made sure it was the most recent version before uploading.

But I'll try with a new compile later this evening. I already addressed the immediate crash so that hopefully won't happen anymore - but I'd still like to know why it fails.

Interesting, when I compile a release build as opposed to a debug build, it crashes. It works when I use the debugger though. for some reason.

I agree with:

Deleting fontdefs.txt from gzdoom.pk3 allows gzdoom to start. Using the same gzdoom.pk3 (ie the one without a fontdefs) and loading fontdefs.txt from the command line still allows gzdoom to start.

Starting with a normal gzdoom.pk3 and loading the fontdefs on top of it does not allow gzdoom to start.


I don't know about but I've been trying all sorts of things all day to try and narrow this down. Everytime I get to a point where what is happening seems logical, something utterly illogical happens to send me right back to square one. So, it's definitely a anyway.

Uninitialized memory. I hate that. It can't be anything else.

The fontdefs thing doesn't surprise me though. The lump is cumulative so the internal one always gets parsed.

I think I got it. The lump names used when creating the font's characters were not properly 0-terminated. Apparently this depended to some degree on the order of lumps in the WAD/PK3.

I just uploaded a new version. Could you please check if this one works better?

1-0-32 works fine for me

Phew! 1.0.32 does not have a start up crash with any of my IWADS.
Thank you.

I noticed that it reports itself as r708. Presumably the fix for 709 (Status bar pointer not nulled) is not included. Is that something that will cause problems with sbarinfo?

Also, you can still get a crash when switching from shader warp, to non shader warp and then back again.

No, the R709 fix is in there because it was absolutely fatal. However, I added that fix in GZDoom first before copying it to ZDoom so the revision number didn't get updated. Actually 1.0.32 is based on a modified R709.

And the shaders still crash? Shit, I thought I got that one. Well, it's not critical enough for an immediate re-release.

OK, thanks for the info.

Just in case my situation with the shaders is different to yours (as has seemed to be the case with a few things recently)

Starting GZdoom with shaders on - no problem.
Starting GZdoom with shaders off - no problem

Starting GZdoom with shaders on, then switching off, then switching on again whilst looking at a warping flat - crash

Starting GZdoom with shaders off then switching them on whilst looking at a warping flat - crash

Doing either of the above 2 whilst not looking at a warping flat does not result in an immediate crash but the game will crash as soon as you see one.

Short version:

Switching from "shaders no" to "shaders yes" will give a crash as soon as you see a warping flat.

All tested in KDiZD and the flats (or are they TX?) concerned were on deep water sectors.



Oh, and I noticed the downloads page still links to the 31 source.


Oh2 I'm sure this won't surprise you because I'm pretty sure you haven't been in that area of the code but the camera texture flicker thing is still there with symptoms exactly as reported for 1.0.30

Graf Zahl wrote:I just uploaded a new version. Could you please check if this one works better?

Can you also upload the source of 1.0.32? The newest available source seems to be that of 1.0.31.

x.x I was just about to ask that, I kind of need it to make a few changes for Dimension 72 to work.

Here you go. This is the only file that changed for 1.0.32