problem importing flats

So I've tried importing flats into my wad using both XWE & DeePsea.

They're all 64x64 & in .bmp format.

With XWE first I imported them as patches & then one by one I went to image & 'save as doom flat' & then made sure they were all between FF_START & FF_END. That gave me W_CacheLumpNum errors when testing the relevant maps. Next I tried DeePsea & the part of the help file on flats that starts "Using the F7/Import tool..." & maybe not coincidentally got the same thing that I did manually with XWE, individually saving as Doom flat, etc & making sure all the flats I added were between FF_Start & FF_End. Same errors again. So I checked in DeePsea a little more closely & found that for example

** Checking 576 PNAMES to the all WADS loaded **

Pname=HEXF0 Graphic format error, x=1235784, offset=2447344

with the flats I added. I didn't find any help file or thread here that told me how to make sure that all the PNAMES are used, whatever that means. There's also a big red rectangle & error msg saying "bad lump: format" when I highlight the problem flats in the PNAMES column (DeePsea, F7, TEXTUREx name edit, etc) How do I use DeePsea or XWE to fix this because I thought I did everything right, including searching for similar problems other people may have had.

Flats shouldn't be added to PNAMES or used in TEXTUREx lumps. PNAMES is for PATCH names, and patches are in Doom's picture format. Flats are completely different, a raw pixel dump without any information about it, only identifiable by their size.

Also, try using SLADE 3.

See that "flats" button at the bottom? Just double click it and import that way. :P

I've had an older version of slade & I just recently got Slade 3 but it crashes a lot, usually when I click on a patch, so I usually stick to Doom Builder, XWE. I just tried DeePsea just to see if it was any more helpful; I guess it gave me more information than XWE but I still don't know what to do to fix this. It's weird I've loaded other floors in XWE by double-clicking the floors button at the bottom & had no problem but with these ones it doesn't work. So I've got 3 lump editors & I'm no closer to fixing this. When I hit verify patch in Deepsea (F7 etc) I get this

== Checking 576 PNAMES patch names used in Textures ==

PNAMES index=562 Patchname= HEXF0 not used

an update: I changed FF_End to F_End & that seems to have fixed it. I don't know how it got changed to FF_End in the first place. Why wouldn't they use FF for both? *sigh* what a world.... I still get the same issues in DeePsea but it works fine in DosBox with Doom2.exe, which is what really matters.

FF_START and FF_END are meaningless in vanilla. F_START and F_END, however, mean something.

The deal with doubled-letter markers (FF_ for flats, SS_ for sprites, etc.) is that they're a source port extension.

Now, why the FF_START/F_END combo? Doom loads wad files sequentially. Suppose you run doom2 -file example.wad. It'll load doom2.wad as the IWAD, and example.wad as a PWAD. After loading, though, it'll be basically the same thing as if you had opened doom2.wad and example.wad in a lump editor, copied every lump from example.wad, pasted them right after the last lump in doom2.wad, and saved and ran doom2.exe directly. The lumps from example.wad are after those from doom2.wad.

When Doom looks for a lump in particular, it starts from the end -- the very last lump of the very last loaded file -- and works back to the start (the first lump of the IWAD). For some of them, it looks in a given namespace. This is notably true for sprites and flats. When Doom starts, it looks for the F_START, F_END, S_START, and S_END markers, and remembers their position. It seeks them as it always does, from the last to the first. Okay so far? When it looks for a flat, it starts from the position of F_END and then keep looking until it finds what it seeks or it reaches F_START.

There is an F_START and an F_END in doom2.wad. If you have an F_END in your PWAD, but no F_START (FF_START is not F_START), the flat namespace will stretch from F_START in doom2.wad to F_END in your PWAD. This has the side-effect of potentially putting in a lot of non-flat junk in your flat namespace, depending how your PWAD is built.

Now the same thing is true for sprites. So you could put S_END in your PWAD to add new sprites... But unfortunately, Doom wants to verify that lumps in the sprite namespace do fit within the sprite naming pattern, and there are a ton of lumps between the IWAD's S_END and the last lump in the IWAD that do not fit that pattern, including the S_END marker itself. So if you try to use that trick for sprites, it won't work. Using it for flats works well though.


And stop trying to use verify patch on a flat. It's a flat. Not a patch. It's never going to work as a patch because it's not a patch. If you've added the flat to PNAMES it's not going to work, so remove it from it.


As for the crashes with SLADE, please provide detailed reports and they may be fixed. Contrarily to XWE and DeePsea, it's still actively developed and maintained.

Thx for the info. Does that mean that it's actually not a problem that DeePsea finds errors then? What if I use F_Start & F_End in a pwad?

When I click on certain things like patches or maps Slade tells me

Stack Trace:
0: ()
1: DrvPresentBuffers()

kermode said:

Thx for the info. Does that mean that it's actually not a problem that DeePsea finds errors then?

Well you should still remove HEXF0 from PNAMES since it's not a patch, but as long as you don't try to use it in a texture, the problem can be ignored safely.

kermode said:

What if I use F_Start & F_End in a pwad?

Then you can only use flats placed in your PWAD. Attempting to use an IWAD flat will fail because the F_START from your PWAD will be reached before the IWAD flats and Doom will stop looking.

kermode said:

When I click on certain things like patches or maps Slade tells me

Stack Trace:
0: ()
1: DrvPresentBuffers()

DrvPresentBuffers() is an OpenGL function, so there seems to be a problem with OpenGL on your computer. I don't suppose you can run OpenGL ports like GZDoom or GLBoom+?

The issue might go away if you update your video card's drivers.

I've got an older version of GLBoom & I've never had any trouble running it. I don't know if GLBoom+ would be any different though. I've also got a program that checks to see if my drivers are up to date & they are. I wouldn't have thought just clicking on a patch would cause any problems.

I jut tried gzdoom & it works ok too. I don't know if that helps or not.

Well I have no idea then, sorry.

I checked the company website for my video card for the latest drivers & it says they're up to date, but my computer is so old maybe it's the video card. When got it years ago I wasn't really looking for a hardcore gaming computer at the time. Maybe it's just my computer showing its age. :\

kermode said:

an update: I changed FF_End to F_End & that seems to have fixed it. I don't know how it got changed to FF_End in the first place. Why wouldn't they use FF for both? *sigh* what a world.... I still get the same issues in DeePsea but it works fine in DosBox with Doom2.exe, which is what really matters.

If your wad's intended to be vanilla compatible, then you've discovered the hard way that flats in PWADs aren't acceptable. The traditional way to add flats is by using a utility like DeuSF to temporarily merge them into the IWAD, using an F_END marker in the PWAD to achieve the same goal seems to be a fairly recent discovery. For testing, I'd suggest using Chocolate Doom's -merge command line option to load the wad.

kermode said:

I checked the company website for my video card for the latest drivers & it says they're up to date, but my computer is so old maybe it's the video card. When got it years ago I wasn't really looking for a hardcore gaming computer at the time. Maybe it's just my computer showing its age. :\

What video card do you have?

ATI Radeon Xpress, which might not be made anymore. The company goes by a different name now & it seems the most recent software for it was out in 2007.