Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
netnomad312

Vanilla compatibility

Recommended Posts

For 15 months now (off and on) I've been working on this megawad of mine, being sure to keep it vanilla compatible. Before about level 11, I didn't even have any ports, I was using Doom95. Around that time I got ZDoom and I've been using it for all my tests. I don't know when this happened, but somewhere along the line I screwed it up. I'm currently working on levels 25 and 26, and today I thought I'd test it in Doom95 just to see if it still works. Well, it doesn't... I tried loading level 26, and it said something to the effect of "(big number) >= numlumps".

I figured maybe it was Doom95, so I tried running doom2.exe from the command line instead. I tried loading level 25, and it said something about "bad texture column" or something. Then I started it again, and went to level 23... I ran ahead for about five seconds, turned a corner and it crashed again with the "numlumps" message.

So, it seems that I have a lot of errors, or something. What I was really doing was testing to see if any of the tricks I recently used (working laser bars, fake deep water, 3d bridges, etc.) had any problems under vanilla doom (they were screwed in Legacy, at least its GL mode, but I know Legacy's really buggy anyway).

Do I have any hope of fixing these errors without doing something really major (the fact that it said something about lumps suggests to me that either (a) I have too many (?) or (b) some major Wintex work is needed)? If not, I guess this wad will only be for ZDoom after all..... crap.....

Share this post


Link to post

This happens in certain cases if some lumps (most likely flats or sprites) are not found. You should run your WAD through an error checker to see whether you used an invalid flat or used something as a flat that really isn't. Vanilla really doesn't like these situations. Of course it might as well be that you just didn't merge your flats with the IWAD.

Share this post


Link to post

Even in Doom2.exe alot of those special effects can make the engine unstable, especially if you are messing around with sector references and broken sectors.

The errors you are getting seem to be connected with your lump information and not the actual levels.

Are you using and custom flats or sprites?

For some reason, I was never able to get flats (or sprites) to work with the original exe's, even using the f_start and f_end markers.

EDIT: Oops, same time postage.

Share this post


Link to post
netnomad312 said:

If not, I guess this wad will only be for ZDoom after all..... crap.....


Not at all, any decent port with removed limits should handle flats and sprites with the f_ and s_ markers.

Share this post


Link to post

D'oh. I forgot that doom2.exe doesn't like custom sprites. But that's true of flats as well? Wow... I wonder why it will allow custom textures, but not flats without merging them. Ah, well, at least it's compatible in theory. *Digs up deusf*

Share this post


Link to post

Using F_START is guaranteed to screw up the original .exe :). It should be:

FF_START
new flats
FF_END
F_END

Also, custom sprites work fine with the original .exe work fine, just so long as they don't replace any of the existing sprites, e.g. including a sprite called NEWBA0 wouldn't cause any problems but COL1A0 would. Of course you'd then have to create a .deh patch which replaces a valid sprite name to the new one, e.g. change COL1A0 to NEWBA0.

Share this post


Link to post

I have new sprites, but they only replace current ones; I want the deh, too, to be optional (what it does now is change story text, level names, and tweaks the SS Soldier a bit so that he's faster and harder to kill, because I have new sprites for him).

As for flats... Wintex created FF_START and F_END by default, but a while back I asked why they weren't showing up in WadAuthor... turned out I had to rename F_END to FF_END. So I have no F_END...

Share this post


Link to post

DOOM really was probably meant to support flats and sprites in PWADs, but the wad directory code that was used in the original engine didn't reorganize the main wad directory properly so that it would work right (which probably means id never tested using sprites or flats from a PWAD in the first place). See, the code in the renderer that uses sprites and flats expects the resource entries to be in one continuous block in the wad directory, because it makes lookup simpler.

BOOM fixed this by adding a function called "W_CoalesceMarkedResources", which looks in ALL the loaded wads and then rearranges the in-memory copy of the master wad directory so that new sprites and flats end up in a linear block with the original ones.

Share this post


Link to post
netnomad312 said:

I As for flats... Wintex created FF_START and F_END by default, but a while back I asked why they weren't showing up in WadAuthor... turned out I had to rename F_END to FF_END. So I have no F_END...

That may be the cause of some of your problems. There should be both.

Share this post


Link to post
netnomad312 said:

I have new sprites, but they only replace current ones; I want the deh, too, to be optional (what it does now is change story text, level names, and tweaks the SS Soldier a bit so that he's faster and harder to kill, because I have new sprites for him).


Even if the sprites only replace current ones, DeuSF is still needed to merge it with the IWAD to make it work.

netnomad312 said:

D'oh. I forgot that doom2.exe doesn't like custom sprites. But that's true of flats as well? Wow... I wonder why it will allow custom textures, but not flats without merging them. Ah, well, at least it's compatible in theory. *Digs up deusf*


Flats are fine without needing DeuSF, see below.

netnomad312 said:

As for flats... Wintex created FF_START and F_END by default, but a while back I asked why they weren't showing up in WadAuthor... turned out I had to rename F_END to FF_END. So I have no F_END...

NiGHTMARE said:

FF_START
new flats
FF_END
F_END


Using FF_END crashes vanilla (as I found when building Plutonia II maps), it's F_END that you need. So a no-win situation with WA. Best thing is to leave it as FF_END, build the map, test with a port, rename to F_END and test with vanilla. Or have two copies of the resource wad, one with FF_END and one with F_END (like I have with Plutonia II's).

Share this post


Link to post

The Ultimate DooMer said:
Using FF_END crashes vanilla (as I found when building Plutonia II maps), it's F_END that you need.[/B]

Only if it replaces one or more of the original flats; using entirely new flat names is fine. Go check Memento Mori 2, FF_END is there and obviously that wad runs fine with the original .exe.

EDIT: actually, MM2 does replace two of the original flats (RROCK13 and RROCK19) yet the FF_END in the wad causes no problems. I therefore have no idea the original .exe was crashing for you. Perhaps replacing Doom 2-only flats (RROCKxx, SLIMExx, etc) is fine, but replacing flats from Doom 1 isn't.

EDIT2: Looking at GothicDM 2, the FF_START in that appears after the new flats (right at the very end of the .wad in fact), so either it doesn't matter where in the .wad FF_START appears, or you don't need it at all.

Share this post


Link to post

I think it was probably the sprites that were crashing it. I still have all the custom sprites I had in the demo wad (green key, computers/office equipment), plus live trees and the new enemy that replaces the SS. So I have a lot of new sprites. :-P

Share this post


Link to post
NiGHTMARE said:

EDIT: actually, MM2 does replace two of the original flats (RROCK13 and RROCK19) yet the FF_END in the wad causes no problems. I therefore have no idea the original .exe was crashing for you. Perhaps replacing Doom 2-only flats (RROCKxx, SLIMExx, etc) is fine, but replacing flats from Doom 1 isn't.


It could be adding new flats that's crashing it (P2 has many of those), as I can't see DooM 2-only flats being any different technically than those appearing in DooM 1 as well.

Edit: it must be that, as I just fired up Fragport (who's new flats replace existing ones only - and they're not DooM 2-only flats being replaced) in vanilla with FF_END and it worked fine, even on the maps with those flats in.

Share this post


Link to post
LogicDeLuxe said:

Is there no FAQ yet dedicated to this stuff?
At least, I can't remember reading such a thing.



Of course there are some FAQs out there. The problem is that almost all source ports take care of these issues so most Doomers no longer have to think about them. As a result few know where to find them.

Share this post


Link to post

From my exerience all Doom2.exe needs for flats is FF_START and F_END. As stated before to get extra/replacement sprites working you have to include all the originals as well. From an online FAQ:


"Once you've made replacement sprites (they don't have to be the same size as the original ones), just load them all into your WAD, selecting 'sprites' if you're using WinTex...

Once again, for your WAD to work properly it will need to include ALL the Doom sprites as well as your own modified sprites. You can put a batch file and a copy of DeuSF into your ZIP file, like with 'flats'. This time you will need to use the command line DEUSF -as YOURWAD.WAD, or DEUSF -append YOURWAD.WAD if you are replacing both flats and sprites"

Share this post


Link to post

Far simpler to include non-replacing sprites and a .deh which changes the relevant sprite names (press F7 in DeHackEd & scroll down. With doom2.exe, the first one - TROO - should be at text offset 22044). Then you won't have to mess around with DeuSF or whatever at all :).

Of course it's simpler still to make your wad require a general, "limit removing port" rather than the original .exe, which 95% of people can't/won't run anyway :D.

Share this post


Link to post

Alright, so I changed F_END to FF_END in my WAD, and I got: W_CacheLumpNum: 2558090 >= numlumps

What exactly does that mean?

Share this post


Link to post

I think they meant change it to F_END...

Eh, I've got a brainfreeze. I tried Deusf earlier to merge my wad with doom2.wad, but it merged with doom.wad instead. What command do I specify so that it merges (and later restores) doom2.wad?

Share this post


Link to post

None. It looks for DOOM's wad first, and if it doesn't find it, DOOM II's. Temporarily rename Doom to something harmless (doom.wa_ or whatever) and then name it back after you're done.

This issue happens when you have both IWADs in the same directory, and it was overlooked because originally you'd always put the games in different directories.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×