DRD Team

My project simply won't run with 1.0.19 or 1.0.19a.

When I copy over 1.0.18, it works again.

Check out logs.zip for my INI file and console log.

I managed to get it to run in 1.0.19a after removing so many things, and all I can conclude is this:

Whatever the new texture code is doing, it's really not good. For example...

1) My main menu is made up of several true colour PNGs with transparency. They aren't transparent anymore and have horrible outlines and other artifacts.

2) My status bar and GRNROCK replacement appears as random pixel mess.

If you need my resources, tell me so I can prepare a stripped down version just enough for you to see the problems.

You will have to. If there's a problem with the texture code I need material to test it with. The PNGs I tested it with worked fine.

Okay, I've PMed you a link to the file.

For your information:

I've stripped down the main textures.wad file so that the download will be smaller. The original textures.wad is 22 megs and has over 1500 textures. I've left only the first 100 textures in so that you have enough material to test with.

The package I've provided comes with GZDoom 1.0.18. Double-click the batch file to run the mod the way it is meant to be loaded. It'll work fine.

After that, try replacing the GZDoom files with 1.0.19(a) and the errors will appear.

Now for some reason, this stripped down version doesn't crash, BUT the texture errors are still there. You'll see the error messages similar to what I've posted in logs.zip (it appears you haven't even looked at it :/).

In the full version of this mod, GZDoom will crash at the TITLEMAP with the error report I posted above. In this stripped version, it'll start, but some textures will fail to load.

Also observe the messed up GRNROCK texture near the statusbar and the screwed up "Load/Save Game" main menu graphics.

The easy thing first: You are using BMPs as textures. Even though this worked with DevIL it was never officially supported and now that I am using my own code there is nothing to handle it.

Convert all the BMPs to PNG and send it to me again. There is no point in testing this one.

Oh, I see.

Well ever since the existence of wad tools that supported importing raw data, I've been rather careless in importing my graphics.

Okay I will convert ALL (I repeat; all - yes - all 1500 of them) textures, as well as the sprites, into PNGs and let you know what happens.

If they are Doom patches you don't need to. It's only the ones that get reported in the console that are a problem.

I've converted all wall/ceiling textures into PNGs, and they no longer show any errors in the console. Problem solved.

HOWEVER, this still does not fix the messed up menu graphics (which all have alpha information in them). They would either display some ugly artifacts like black/lred lines, or you can see a transparent box at the areas that are supposed to be 100% transparent.

Now let's talk about the crashing. No matter what I did, I could NEVER get it to run. After a lot of testing, I have concluded this:

There is a folder called "textures" in the same folder as my project. It has almost a gig's worth of data. That folder holds various PSD files, pictures, references, photographs, drawings, etc.

Deleting or renaming this folder sovles the crashing problem.

Is GZDoom attempting to autoload stuff from a directory named "textures"?

Indeed it does. It tries to load hires texture replacement from there. But only files with extensions '.jpg', '.pcx', '.png' and '.tga'.

If you can find the file that causes the crash and send it to me it'd be a great help.

It'll take a while for me to sift through the gigabytes of pictures in that folder to find the problem file.

I'll post the file in this thread ASAP.

I haven't found the offending file, but I can make some guesses:

A) It crashes due to non-standard filenames. Some of the textures in the folder have names containing characters like {, _ and stuff. And some of them have really long names.

B) Duplicate textures. The texture exists inside the PWAD, as well as in this folder.

C) Large pictures. Some are 2048 x 1536.

D) Presence of BMP files in the folder. This seems to be the only logical explanation. But apparently the engine does not autoload BMP files, correct? Hmmm...