Doom95 Texture Crash

I recently added some new textures and flats to my vanilla map, but as soon as one comes into the player's vision the game crashes with Doom95, do I have to replace existing Doom textures for the textures to work? Can it not handle textures lump and new flats?

Yes it can, make sure they're behind the proper markers in the wad file, they are using the correct img format (bmp), and the correct size. 64x64 for Flats, 128 max height for textures.

Well, all the flats are inside FF_START/FF_END markers, and I imported the textures as patches, then right clicked and pressed 'Add to texture' using XWE, I really don't understand what's screwing up because they work fine in other ports such as Skulltag and GZDoom

Use3D said:

they are using the correct img format (bmp)

O_o

Captain Toenail said:

they work fine in other ports such as Skulltag and GZDoom

Modern ports (and possibly especially the Zdoom based ports) are far more tolerant of additional graphics than the original vanilla (etc) executables. Patches should be reasonably straight forward, but flats (and sprites) are more complicated.

Lol yeah, they arn't bmps!

Anyway, I reimported the flats and now Doom95 crashes as soon as I hit start now! What's going on now?!

Edit: Enjay, please elaborate on how flats can be more annoying? It's more complicated than simply importing them as flats using XWE?

Captain Toenail said:

Lol yeah, they arn't bmps!

Anyway, I reimported the flats and now Doom95 crashes as soon as I hit start now! What's going on now?!

Edit: Enjay, please elaborate on how flats can be more annoying? It's more complicated than simply importing them as flats using XWE?

Are you saving them as a flat? Doom uses a special format just for flats. In XWE, select your image and then in the menu select Image -> Save as Doom flat

Flats need to be between FF_START and F_END.

Also does ZDoom display any warning in the console that might help us figure out what's wrong?

I can't remember the details, it's so long since I last did it, but for the vanilla engines sprites and flats couldn't just be added in the way that you could with patches. True, they needed to be between markers, as stated but, originally at least, you used to have to run a program to copy all the original sprites/flats to your WAD between the markers too (or was it to the IWAD?) because Doom couldn't handle partial sets or something. Then a trick was discovered (perhaps the names that EarthQuake mentioned ie one FF and one F ?) and that allowed it...

I think.

And just to clarify my other point - Doom graphics are not BMPs. XWE and other programs may load BMPs but they get converted to the Doom format when they are inserted into a WAD. Flats are different to patches and sprites, but are still not BMPs. Many of the early editing tools didn't use BMPs at all because the BMP format hadn't become popular enough back then. DMGRAPH.EXE, for example, mainly tended to be used with GIF files but also supported PPMs

http://doom.wikia.com/wiki/Picture_format

EarthQuake said:

Also does ZDoom display any warning in the console that might help us figure out what's wrong?

My guess is that it won't. As far as I can tell, the graphics have been inserted correctly for Zdoom (so it won't complain) but not in a way that is acceptable to an older engine like Doom95.

Yeah, FF_START and F_END must be used (a double F on the second marker will cause an error). It's not really a trick, just that it was not documented anywhere (Matt Fell didn't catch this fact for the DOOM specs) so most people didn't know, including the developers of the early resource tools. Here is a document explaining improved flat and sprite insertion in early '96.

Only replacement sprites normally need merging, into the PWAD.

Guess what the problem was? XWE gave me an FF_END marker! I changed it and it works perfectly now, great! Thanks guys.

Another question that has been bothering me, is there a limit to the amount of flats or textures I can import for vanilla?

(also that popup with the snake is really beginning to annoy me!)

Captain Toenail said:

Another question that has been bothering me, is there a limit to the amount of flats or textures I can import for vanilla?

Not that I know of. If there is, it's virtually impossible to reach: for KDiKDiZD, we've got every texture and flat from KDiZD.pk3, lots of added matching texture/flats, flat alignments/rotations, pre-arranged flat/texture mixes, and custom textures/flats for fake colored lighting and other effects....oh, right, and then there are the several 128-frame warping flat and texture animations.

So, no, I doubt there's any limit other than the amount of memory in your computer :P

BTW, Chocolate Doom is significantly better than Doom95 for testing vanilla compatibility. Doom 95 actually increases some of Doom's limits slightly, which can make all the difference if something is right on the edge.

The FF_START marker shouldn't really be required AFAIK. It's just for the convenience of wad editing tools to help them keep track of where the flats are meant to start. Here's what happens when you load a PWAD with flats under vanilla Doom:

1. IWAD is loaded into the wad directory

[F_START]
... flats in iwad ...
[F_END]

2. PWAD is loaded into wad directory

[F_START] (from IWAD)
... flats in iwad ...
[F_END] (* overridden by F_END below)
...
[FF_START] (from PWAD)
... flats in PWAD ...
[F_END]

The F_END in the PWAD overrides the F_END in the IWAD. Since DOOM enumerates flats by counting from the F_START entry to the newest F_END entry in the directory, it is actually going to enumerate all IWAD resources from F_START on and all PWAD resources from the start of the PWAD to the F_END as flats. FF_START, meaning nothing to DOOM itself, is simply ignored in this case.

In BOOM this was changed so that these separate blocks are properly merged into one cohesive block of lumps, and each one is called a "namespace" - so flats between the F_START and F_END lump in the unified wad directory are said to be in the flats namespace. This simultaneously fixes some problems, and creates new ones for old wads that abused DOOM's weird behavior with these lookup mechanisms. Some of the other engine code has to contain hacks to keep some of those wads working with the new wad directory behavior.

Quasar said:

The FF_START marker shouldn't really be required AFAIK. It's just for the convenience of wad editing tools to help them keep track of where the flats are meant to start.

In BOOM this was changed so that these separate blocks are properly merged into one cohesive block of lumps, and each one is called a "namespace" - so flats between the F_START and F_END lump in the unified wad directory are said to be in the flats namespace. This simultaneously fixes some problems, and creates new ones for old wads that abused DOOM's weird behavior with these lookup mechanisms. Some of the other engine code has to contain hacks to keep some of those wads working with the new wad directory behavior.

Skulltag suffers from the same thing. I had to modify an old PWAD I wanted to play online due to every texture being wrong.

Quasar said:
Since DOOM enumerates flats by counting from the F_START entry to the newest F_END entry in the directory, it is actually going to enumerate all IWAD resources from F_START on and all PWAD resources from the start of the PWAD to the F_END as flats.

Interesting. Does that have any effect one the system? Does it waste memory reading the stuff that is not flats, taking a bit longer to load the game? I guess that if that is the case and Doom reads the data in order, placing flats at the beginning would help, becuase it would end with the IWAD's flats and start reading the PWAD's flats immediately, without reading junk in the middle.

I'm pretty sure someone recently had an issue where a lump was named like a texture (I think) and this would make Doom hang. Maybe the issue goes away if the flats are placed first as I noted above?

Enjay said:

And just to clarify my other point - Doom graphics are not BMPs....

Zdoom supports PNG images does it not? Are those not converted once inserted into the wad? I was just making sure he wasn't using some foreign image format for a vanilla wad that may work fine in an engine such as zdoom.

Use3D said:

Zdoom supports PNG images does it not? Are those not converted once inserted into the wad? I was just making sure he wasn't using some foreign image format for a vanilla wad that may work fine in an engine such as zdoom.

That's all true, but the point being made was that Doom's graphic format isn't BMP. It uses its own format for patches and sprites, which graphics have to be converted into in order for Doom itself and most ports to be able to read them.

esselfortium said:

That's all true, but the point being made was that Doom's graphic format isn't BMP...

Uh Okay..I'm clear on that, but when working with a vanilla wad, it's safe to say that if you make your graphics as BMP, and put them into the wad file using XWE or Wintex, which then converts them, everything will be fine. I use BMP for everything including my vanilla wads and Doom95 doesn't complain.

Would XWE convert say a PNG image into the 'Doom graphic format', or would a PNG image loaded into a wad file crash vanilla doom? That's what I was saying when I mentioned the use of BMP for a vanilla wad.

It's still wrong to say that Doom graphics are BMPs. That has led to a lot of confusion over the years (almost as much as the myth that cyan=transparent).

It would be better to say something like "If you make sure you use BMP graphics for your source files when using XWE, they will be converted and inserted into your WAD in the Doom format".


BTW, some useful information in this thread as to how the F_END marker works. Thanks.

esselfortium said:

Not that I know of. If there is, it's virtually impossible to reach: for KDiKDiZD, we've got every texture and flat from KDiZD.pk3, lots of added matching texture/flats, flat alignments/rotations, pre-arranged flat/texture mixes, and custom textures/flats for fake colored lighting and other effects....oh, right, and then there are the several 128-frame warping flat and texture animations.

So, no, I doubt there's any limit other than the amount of memory in your computer :P

BTW, Chocolate Doom is significantly better than Doom95 for testing vanilla compatibility. Doom 95 actually increases some of Doom's limits slightly, which can make all the difference if something is right on the edge.

I have FF_START and FF_END markers and flats in these work correctly in Chocolate Doom, but not in Doom95. Also, i don't care about Doom95 anymore, this port is crap.

TomoAlien said:

I have FF_START and FF_END markers and flats in these work correctly in Chocolate Doom, but not in Doom95. Also, i don't care about Doom95 anymore, this port is crap.

There are several ways to load WAD files in Chocolate Doom. For testing vanilla compatibility (without Deusf stuff and such), you should only use -file

TomoAlien said:

I have FF_START and FF_END markers and flats in these work correctly in Chocolate Doom, but not in Doom95. Also, i don't care about Doom95 anymore, this port is crap.

Did you bother reading the above posts? Your wad won't work in vanilla either...

For Vanilla compatibility you should be doing FF_START .. F_END (not a typo).

LogicDeLuxe said:

There are several ways to load WAD files in Chocolate Doom. For testing vanilla compatibility (without Deusf stuff and such), you should only use -file

Now i know.