Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Janizdreg

Comprehensive list of static vanilla Doom limits

Recommended Posts

I'm trying to gather a comprehensive list of all the known static vanilla Doom limitations. Here are the limits I'm familiar with already:

maximum amount of sprites in view at once: 128
maximum amount of unique floor and ceiling surfaces (visplanes) in view at once: 128
mus files size limit: 65536 bytes
savegame file size limit: ~180kb

Please post any additional limits that you are aware of here. In addition to the actual numerical value of the limit, state clearly what the limit concerns (preferably so that even totally Doom engine illiterate people can understand it, if possible).

Share this post


Link to post

You'll find a few more listed here (obviously, the "old" figures are the vanilla limits).

If you pick through this thread, you'll find a few more mentioned that haven't been extended in Doom2+ for one reason or another (e.g. breaking demo compatibility).

Also:
maxintercepts: 128
maxspechits: 8

Share this post


Link to post

mus files size limit: 65536 bytes

It's limitation of a format. Size of data is stored in a header in two bytes. So 2^16=65536 is a theoretical maximum

Share this post


Link to post

The DOOM Specs file says this about sounds:

Each sample is a single byte, since they are 8-bit samples. The maximum number of samples is 65535, so at 11 KHz, a little less than 6 seconds is the longest possible sound effect.

I'm not sure how accurate it is, or whether it applies to v1.9 (the specs were written for v1.666). Is it also file format related?

Share this post


Link to post

Technically, you can have sounds longer than 6 seconds in
the doom sound format, just take into account the lump size
rather than the 16bit value stored inside it.

I'm sure that original doom 1.9 uses the value, but I've
also seen wad's that have longer sounds.

Share this post


Link to post

RTC_Marine said:
Technically, you can have sounds longer than 6 seconds in the doom sound format,

Well, it does imply that, but according to what it says they'd have to be of a frequency inferior to 11025 Hz.

Share this post


Link to post
myk said:

Well, it does imply that, but according to what it says they'd have to be of a frequency inferior to 11025 Hz.

No he means ports could ignore the 16-bit size value and use the full lump size, @ whatever frequency you want.

Share this post


Link to post

Yeah I am sure I used DMAUD or Wintex or whatever to put WAVs longer than 6 seconds into whatever stupid WADs I was making in 1995.

Share this post


Link to post

Well, back then (in '95) sounds over 6 seconds could have worked if they were crappy sounds of less than 11025 Hz. If you insert one of the right RAW content but that exceeds the maximum number of samples, it won't play back in the game (it's ignored in the same way a large MIDI file is ignored for music).

Ajapted said:
No he means ports could ignore the 16-bit size value and use the full lump size, @ whatever frequency you want.

I see, although those sounds aren't really in the Doom sound format, since the format is a RAW 8 bit sound format with the number of samples defined in the header.

Share this post


Link to post
RTC_Marine said:

Technically, you can have sounds longer than 6 seconds in
the doom sound format, just take into account the lump size
rather than the 16bit value stored inside it.

I'm sure that original doom 1.9 uses the value, but I've
also seen wad's that have longer sounds.

The length field is actually 32-bit. Look at the death sound in marina.wad, which is longer than 6 seconds and plays in Vanilla Doom.

Share this post


Link to post
fraggle said:

The length field is actually 32-bit.

Wow!

BTW, in Chocolate Doom you have this:

// If the header specifies that the length of the sound is greater than
// the length of the lump itself, this is an invalid sound lump

if (length - 8 > lumplen)
{
    return false;
}
Shouldn't that be this: ?
if (length > lumplen-8)
...

Share this post


Link to post

fraggle said:
The length field is actually 32-bit.

Ah, would the 4th undescribed 0 value ("short unsigned integer") in the UDS hold the extra allowed length over the limit that was supposed by Matt Fell and company?

(1) 3           (means what?)
(2) 11025       (the sample rate, samples per second)
(3) N           (the number of samples)
(4) 0 
EDIT: Hmm, I was just testing and that portion of the header is never used. I also applied a 7+ second 8-bit mono 11025 Hz sound, converted to the Doom sound format, and it played through only partially. A longer (30 second) sound played for a very short period, and the DOOM II boss wakeup sound repeated (twice its length) didn't reach the end of the first copy (shorter than the original, an indeed the length in the header is shorter). These were saved in the Doom format (from WAVs) using XWE. Would this result be due to the limitations of the format (not just the RAW sound content)... or rather buggy behavior in XWE when applying the header info?

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
×