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

PrBoom-Plus Everything Else

Recommended Posts

PrBoom-Plus version 2.4.3.1 was released late last month, bringing it in line with PrBoom 2.4.3. It's also now available for the Mac, Linux, and other POSIX operating systems. There are also several other changes.

It also looks like PrBoom was updated to version 2.4.4, doubling the sidedef and vertex limit as well as making other changes and bug fixes.

Share this post


Link to post
XDelusion said:

I'd still like to see an update to the BeOS/Zeta sources.

An Amiga port would be grand too.


Not to be terribly rude about this but: Do it yourself. Such things take quite a bit of work and not many people have machines running those platforms. If you want something that out of the way done it might be quicker/more reasonable to just do it yourself.

BTW an Amiga port of Doom itself exists. Try looking around a bit harder.

Share this post


Link to post

Oh ya, not to be rude, but I don't code, so I can't, and don't feel like going to school to learn, I'm busy with my other more personal skills.

leave the coding to the coders.

And I am aware of Amiga's 5 or 6 Vanilla DOOM ports, but Vanilla DOOM sux to me now, I want some beef with my engine, limit removal, that kind of jazz.

Share this post


Link to post
XDelusion said:

Oh ya, not to be rude, but I don't code, so I can't, and don't feel like going to school to learn, I'm busy with my other more personal skills.

leave the coding to the coders.


I CANT BE BOTHERED PLZ DO IT FOR ME WAH!

And I am aware of Amiga's 5 or 6 Vanilla DOOM ports, but Vanilla DOOM sux to me now, I want some beef with my engine, limit removal, that kind of jazz.


I am still stuck on how vanilla doom could suck, so formulating a complete response is out of the question. EDIT: Beefy engines and the Amiga don't go together. Because its old, not as common, and that kind of jazz.

Share this post


Link to post

Sooo... 65534 sidedefs eh?

...and there was much rejoicing.

Share this post


Link to post
ukiro said:

Sooo... 65534 sidedefs eh?

...and there was much rejoicing.



Only in theory. The seg limit will be hit much earlier. You'd be lucky to get a map with 50000 sidedefs to work, most likely even much less. With the largest map I have tested so far the segs:sidedefs ratio was approx. 1.5:1 for normal nodes.

I have no idea though whether PrBoom can handle GL nodes with >65535 segs.

Share this post


Link to post

DV Map05 is 53,204 segs and 41,467 sidedefs, and a good example of what the expansion can support. Still, loading a very huge level will eat a lot of system resources. The DV maps loaded seprately are fine on my computer, but Map05 is slower.

Share this post


Link to post

It was so shockingly easy to extend the fields used to hold map entity indices that I don't understand why Lee Killough or Jim Flynn didn't make that a top priority in BOOM (in fact, I based my extension code on Lee's blockmap extension, which did more or less the exact same thing).

Share this post


Link to post
Quasar said:

It was so shockingly easy to extend the fields used to hold map entity indices that I don't understand why Lee Killough or Jim Flynn didn't make that a top priority in BOOM (in fact, I based my extension code on Lee's blockmap extension, which did more or less the exact same thing).


Probably for the same reason why it was once said that "640k ought to be enough for everybody". :)

Share this post


Link to post

why does everyone double the limit as opposed to making it infinite, or something absurd like 512k? I understand that there might be a limit in some table in the file structure or whatever, but I'd like to have it explained to me. And I'm not much of a programmer (albeit not dumb either) so go easy on the code lingo.

Share this post


Link to post
ukiro said:

why does everyone double the limit as opposed to making it infinite, or something absurd like 512k?


Simple words: Its not possible with the map format.

Share this post


Link to post

Quasar said:
It was so shockingly easy to extend the fields used to hold map entity indices that I don't understand why Lee Killough or Jim Flynn didn't make that a top priority in BOOM (in fact, I based my extension code on Lee's blockmap extension, which did more or less the exact same thing).

Not sure, but I think it was sufficient for the times, for the most part, because the bigger maps that are being made now would have drowned the systems in use back then and even a few years after that. Remember GothicDM '99? Now, though, the extensions certainly make sense; systems have evolved and even Doom itself has been extended to almost Boom's map size or detailing capabilities (so naturally source based engines should be at least a step ahead).

Share this post


Link to post
ukiro said:

why does everyone double the limit as opposed to making it infinite, or something absurd like 512k? I understand that there might be a limit in some table in the file structure or whatever, but I'd like to have it explained to me. And I'm not much of a programmer (albeit not dumb either) so go easy on the code lingo.

Yes, exactly, there is some limit in a table in the file structure. Sidedef numbers are stored in the linedefs lump in your wad file as signed 2-byte numbers, that means you can have sidedefs numbered -32768 to 32767, with -1 meaning "no sidedef"

It is easy to double the largest sidedef number by interpreting the signed quantity as an unsigned quantity, therefore you get sidedefs numbered 0 to 65535. To handle the "no sidedef" case, you check for 65535, which is what -1 looks like if you interpret it as an unsigned number.

To increase the limit further, you would have to change the wad format to be able to store a number larger than 65535. That is to say, a larger number of bytes would be needed to store the number. ZDoom already does this, I believe, by using the Hexen map format.

Share this post


Link to post
RjY said:

Yes, exactly, there is some limit in a table in the file structure. Sidedef numbers are stored in the linedefs lump in your wad file as signed 2-byte numbers, that means you can have sidedefs numbered -32768 to 32767, with -1 meaning "no sidedef"

It is easy to double the largest sidedef number by interpreting the signed quantity as an unsigned quantity, therefore you get sidedefs numbered 0 to 65535. To handle the "no sidedef" case, you check for 65535, which is what -1 looks like if you interpret it as an unsigned number.

To increase the limit further, you would have to change the wad format to be able to store a number larger than 65535. That is to say, a larger number of bytes would be needed to store the number. ZDoom already does this, I believe, by using the Hexen map format.


Very nice explanation, this is exactly what I was after. However, I wonder what would prevent anyone from allowing a 4-bit value, for example. Is it that the bit/byte position if this value in the file header is pre-determined, and expanding it to 4-bit would offset the following data in a way that an engine can't distinguish from a non-expanded linedef lump? But if that is the case, wouldn't it be possible to count "backwards", from the end of the header? Or would an expanded (4-bit) linedef lump demand other parts (blockmap or whatever) to be expanded too, hence making this undoable somehow?

Or am I just talking out of my ass here? =)

Share this post


Link to post

The only things stopping us from using a 32-bit map format are these two facts:

1. Nobody can agree what that format should look like.

2. No editor authors are willing to add support for it.

Share this post


Link to post
Quasar said:

The only things stopping us from using a 32-bit map format are these two facts:

1. Nobody can agree what that format should look like.

2. No editor authors are willing to add support for it.



Right now I'd agree to anything, as long as it is open enough to handle custom extensions without the need of version numbers, source port markers or specific implementations. I think the only way to achieve something is just to define something that initially works for more than one port. In such a case the rest will be much easier.

Share this post


Link to post

Graf Zahl said:
without the need of version numbers, source port markers or specific implementations.

Except the XWAD header, I presume. That'd allow most unexpanded engines to close on detecting such wads, instead of reading incompatible data.

Share this post


Link to post

I'm prepared to start discussing a new map format again.

How about this for an entrée:

1) call it the "XWAD" spec. The four-letter identifier in the wad header is "XWAD", to prevent existing programs from choking on the new format. Actual directory format remains the same.

2) map names are the same as before (MAP01, E2M3, TITLEMAP), but must exist between XM_START and XM_END markers so programs can find them easily and unambiguously.

3) all the data for the level (including nodes, reject, scripts) are contained in that single lump (MAP01 etc). The format is binary and consists of chunks (like in the PNG or RIFF formats). The data inside a chunk could, of course, be textual.

Share this post


Link to post

Something like that. And the 'XM_' namespace would map nicely to ZDoom's 'maps/' directory in Zips.

I am not sure about the 'XWAD' header. Personally I'd prefer ZIPs anyway so in the end it shouldn't matter much. And the single lump approach is certainly a must for anything new.

Share this post


Link to post

After looking at zdoom's zip code, which is certainly neat, I'm not sure what the great advantage is, since the 8-letter resource name limitation remains in place (nor do I think that truncating longer names to 8 characters is a particularly smart thing to do, either...)

I realized pretty quickly that it'll be a nightmare to remove that limit since static buffers of size 9 are used all over the place.

If the XWAD format *was* pursued, there should be at least ONE change to the directory entries. Lump size and offset fields should be specified as *unsigned* ints, not signed ints. While I DO seriously doubt anybody is bothered by the 2 GB limit on wad file and lump size, there's really no use in allowing negative lump sizes either ;)

And actually this stuff is off-topic when it comes to *map* formats, since the wad format is totally separate from that :)

Share this post


Link to post
Quasar said:

After looking at zdoom's zip code, which is certainly neat, I'm not sure what the great advantage is, since the 8-letter resource name limitation remains in place (nor do I think that truncating longer names to 8 characters is a particularly smart thing to do, either...)

The great advantage is that you no longer depend on tools like XWE. Zips can be opened with any archive manager out there and that alone is a big advantage.

I realized pretty quickly that it'll be a nightmare to remove that limit since static buffers of size 9 are used all over the place.

What can you do? The things that require 8 character names are not easily changed, especially texture names, because the resources that use them can't handle anything longer so right now it's pointless to handle anything texture related with more than 8 characters.

But in places where this was easy to change the full names can already be used. Most importantly these are sounds and music.

If the XWAD format *was* pursued, there should be at least ONE change to the directory entries. Lump size and offset fields should be specified as *unsigned* ints, not signed ints. While I DO seriously doubt anybody is bothered by the 2 GB limit on wad file and lump size, there's really no use in allowing negative lump sizes either ;)

Does it matter? An invalid size is an invalid size so internal handling is completely irrelevant here.

And actually this stuff is off-topic when it comes to *map* formats, since the wad format is totally separate from that :)

Indeed it is. But I think the marker was meant to keep WAD tools from opening XWADs - which IMO is more counterproductive than anything else. The WAD format is a dead end and doesn't need to be extended further.

Share this post


Link to post
Graf Zahl said:

The great advantage is that you no longer depend on tools like XWE. Zips can be opened with any archive manager out there and that alone is a big advantage.

Agreed.

As for long resource names, what's the point? I don't think the 8-character limit has ever caused me any trouble. In fact, it makes life easier by enforcing concise naming schemes.

Share this post


Link to post
Fredrik said:

Agreed.

As for long resource names, what's the point?

My initial motivation for Zip support was to get long file names for proper model support in GZDoom. ZDoom itself makes some use of them as well for internal purposes. Just look at the subfolder 'actors' in zdoom.pk3.

Share this post


Link to post

I've done some work on a possible spec, not yet finished but contains the meat. You can read it here:

XMAP Spec

One innovation is the "property lists", each thing/linedef/sector can have arbitrary key=value pairs associated with it. All these lists are stored in the first chunk called [PROP].

Another useful thing is a new "domain" field, to specify what the type number means (e.g. DOOM/Heretic/Hexen or a port-specific value).

BTW, I don't think any new map format will fly if zip files are the requirement -- too much new code needed.

Share this post


Link to post

So far so good. However, I really don't see the need for the XM_ markers. Either a port or tool can handle the format and doesn't need them or it doesn't support it - which leaves 2 possibilities: Either the program checks the name of the following (THINGS) lump, in which case it would properly abort or it doesn't - and in that case nothing at all could help.

Other things:

- In a chunk based format order of chunks shouldn't matter at all. Any proper tool should scan for the chunk it wants to load, not just load them sequentially.
- Args in things and lines should be 32 bit, not 8. Although 8 is the limit for the current map format, ZDoom can use 32 bit internally and for many of Hexen's line specials such an extension would be extremely useful.
- Since Strife is not a source port an additional standard chunk [CONV] for Strife's conversation scripts might be a good idea.
- For Hexen style linedefs the trigger mask should be taken out of the flags and put into its own property. This has become one of the most problematic limitations because we'd like to add a few more trigger types to ZDoom but can't because everything has been used.
It should be at least 16 bits with two bits specifying from which side the trigger should be activatable.

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×