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

Technical question regarding LineDefs

Recommended Posts

The original Doom WAD files seem to have a 14 byte 'record' length in "LINEDEFS" entries (7 words). The newer ZDoom formatted(?) WAD files have 16 bytes per record (8 words).

We seem to have the same issue with "THINGS" entries (10 bytes vs. 20 bytes).

Does anyone know how software should detect the difference?

Share this post


Link to post

Frankly, there is no bulletproof way to tell merely from the linedefs lump, though there are various algorithms one might employ to make a good guess. I can't speak for the other programmers in the DOOM editing community, but I can tell you what WadAuthor does. WadAuthor looks for a "BEHAVIOR" lump associated with the given map. If it finds one, then it assumes a Hexen-style map with the larger linedef/thing structures. For what it's worth, the following declarations are taken from WadAuthor's own code, though sadly the indentation is not preserved in this message board.

//@struct SPECIALSTRUCT | This structure contains information required to
// cause actions to happen within the map. The type may indicate a feature
// built into the game, or it may indicate a script within the BEHAVIOR
// resource.
typedef struct tagSpecial
{
byte Type; //@field type of action
byte Args[NUM_SPECIAL_ARGS]; //@field arguments for the action
} SPECIALSTRUCT; // 6 bytes

//@struct LINEDEFSTRUCT | This structure contains information for a single
// linedef within a wadfile. A linedef defines a connection between two
// vertices and has one or two associated sides.
typedef struct tagLineDef
{
short FromVertex; //@field identifies vertex for linedef origin
short ToVertex; //@field identifies vertex for linedef tip
short Bitset; //@field linedef attribute bits
short Type; //@field linedef type identifier
short TagNumber; //@field defines which sectors are affected (if any)
short Sidedef1; //@field identifies front sidedef
short Sidedef2; //@field identifies back sidedef (if any)
} LINEDEFSTRUCT; // 14 bytes (4681/seg.)

//@struct LINEDEFSTRUCTEX | This structure contains information for a single
// linedef within a wadfile. A linedef defines a connection between two
// vertices and has one or two associated sides.
typedef struct tagLineDefEx
{
short FromVertex; //@field identifies vertex for linedef origin
short ToVertex; //@field identifies vertex for linedef tip
short Bitset; //@field linedef attribute bits
SPECIALSTRUCT Special; //@field Special data
short Sidedef1; //@field identifies front sidedef
short Sidedef2; //@field identifies back sidedef (if any)
} LINEDEFSTRUCTEX; // 16 bytes (4096/seg.)

//@struct THINGSTRUCT | This structure contains information for a single
// thing within a wadfile. A thing is any object with which the player
// can interact.
typedef struct tagThing
{
short X; //@field x co-ordinate of thing location
short Y; //@field y co-ordinate of thing location
short Angle; //@field angle towards which the thing is oriented
short Type; //@field thing type identifier
short Bitset; //@field thing attributes bits
} THINGSTRUCT; // 10 bytes (6553/seg.)

//@struct THINGSTRUCTEX | This structure is an updated version of the
// original THINGSTRUCT. Hexen adds a tag number and script data to
// the original.
typedef struct tagThingEx
{
short TagNumber; //@field tag number for activation
short X; //@field x co-ordinate
short Y; //@field y co-ordinate
short Height; //@field height of object
short Angle; //@field angle the thing is facing
short Type; //@field identifies what thing it is
short Bitset; //@field thing attribute bits
SPECIALSTRUCT Special; //@field Special data
} THINGSTRUCTEX;

Share this post


Link to post

Thanks for the idea.

By the way, a while back in one of your posts (Progress Update #2) you were wondering about doing an operation first, or queueing them. In my software, I do them immediately, but wastefully. That is, if the user modifies an entry, the size of the original and new one is compared. If the new one is smaller or equal, the new entry goes straight into the file, and the WAD directory is not modified (only size, actually). Otherwise, the new entry is written to the end of the file, and the corresponding entry in the WAD directory is updated (new position and size).

Advantages: Simple (to code), safe, very fast. Disadvantages: Wastes space, almost always (except when the entries are the same). But... you can keep editing your WAD file, when it's done just click File | CleanUp. This rewrites the entire WAD file, directory first, then entries in order. Tight. Keeps a backup.

I'm doing this since your editor edits maps so well, but I wanted to deal with all the rest. Link: http://wadedit.50megs.com If you want the source, it's yours.

Share this post


Link to post

>In my software, I do them immediately, but wastefully. That
>is, if the user modifies an entry, the size of the original
>and new one is compared. If the new one is smaller or
>equal, the new entry goes straight into the file, and the
>WAD directory is not modified (only size, actually).
>Otherwise, the new entry is written to the end of the file,
>and the corresponding entry in the WAD directory is
>updated (new position and size).

Yeah, I thought about that option. I dismissed it, however, when I asked myself a simple question: during the course of developing a wadfile, how often does one save a file with *less* data than before? From my own experience, I had to answer "not much". Nevertheless, if that works well with your editor, then that's great! I just don't think it would be a good solution for WadAuthor.

Thanks, by the way, for the generous offer. I'll have to remember to take a look at your utility and see what it does.

Share this post


Link to post

Maybe I what I said wasn't clear enough, or maybe I'm missing something. Even if the new or newly modified entries are always longer, my point is the same.

Example: We have a WAD file, with 500 entries in the directory. If Entry #250 needs to be replaced with a longer entry, we can deal with it two ways:

1) Create a new file. Copy the first 249 entries, then the new one, then the remainder of the file. All entries after the modified one will have a new position. The resulting file is 'perfect'.

2) Copy the new entry to the end of the existing file, and update it's directory entry. The space within the file, that is still occupied by the old entry, is now 'wasted', since nothing is pointing to it. Therefore this file is not 'perfect'.

When I try to see the pros and cons of these two options, it seems to me that the first option can be slower. So I choose speed over space. After all, once I'm done with a file, I can 'clean it up'.

So, considering all this, are you saying that WadAuthor will always 'insert' the new entry? Maybe you are right, I never actually tested how fast or slow that would be.

Share this post


Link to post

Re: speed.

Speed is not a problem when writing a "perfect" file. It's a litte bit -maybe- for > 2mb files. Even then, it's not a big deal on todays hardware that xfers at +12MB/sec. Usually it's instantaneous. Even on a 486 it didn't take long at 500KB/sec.

So it's better to not have "holes", since wasted space is always wasted space:) Why make an extra step to clean it up?

How one writes the code to create a file makes a big impact. Just don't do it the DEU way<g>

Looking for BEHAVIOR is the standard way to detect a HEXEN type structure.

Share this post


Link to post
loser said:

Ah yes, that's true. I'm sorry, I wasn't thinking earlier when I wrote that. Now that I understand what you're doing, you're right; i.e., your method is always extremely fast at the cost of a little space. Maybe I'm just being stubborn about it, but I think I'm going to stick with the current approach. Somehow the wasting of disk space horrifies me. I guess I'm just showing my age is all; the first PC I ever built had a whopping 1,024 bytes of memory, so I got used to making every byte count!

Share this post


Link to post
deepteam said:

Re: speed.

Speed is not a problem when writing a "perfect" file. It's a litte bit -maybe- for > 2mb files. Even then, it's not a big deal on todays hardware that xfers at +12MB/sec. Usually it's instantaneous. Even on a 486 it didn't take long at 500KB/sec.

So it's better to not have "holes", since wasted space is always wasted space:) Why make an extra step to clean it up?

How one writes the code to create a file makes a big impact. Just don't do it the DEU way<g>

Looking for BEHAVIOR is the standard way to detect a HEXEN type structure.

Hey, Jack, long time no "see". I don't know about your user base, but a fair number of mine use WadAuthor to edit the main IWAD itself. And again I don't know about Deep (or whatever Deep spinoff/descendent you're selling today), but writing that big DOOM.WAD file takes a while in WadAuthor--even on pretty fast hardware.

Share this post


Link to post
Phileosophos said:

//@struct SPECIALSTRUCT | This structure contains information required to// cause actions to happen within the map. The type may indicate a feature// built into the game, or it may indicate a scri

And somewhere in all that jibberish lies his plans for world domination...

Or a really big bomb.

Share this post


Link to post
Phileosophos said:

Hey, Jack, long time no "see". I don't know about your user base, but a fair number of mine use WadAuthor to edit the main IWAD itself. And again I don't know about Deep (or whatever Deep spinoff/descendent you're selling today), but writing that big DOOM.WAD file takes a while in WadAuthor--even on pretty fast hardware.

Hi John,

DeeP is now DeePsea (a windows editor since about '97).

A straight IWAD save from DeePsea for 14MB DOOM IWAD takes less than 2 seconds on my machine - a PIII800, 256mb (just did it)- including all that .bak stuff. But it's about the same when it was a PII450.

I've never worried about "time" in saving, even on a P100. Native windows disk caching does wonders. Even in DOS, smartdrive took care of things quite well.

Basically, the saves run at the maximum dtr of the disk drive (if it's not fragmented) which can be over 20MB/sec. The older "large" drives hit about 4-8mb/sec.

I suppose we differ in how we code the file I/O. And Yes, the whole file is copied and recreated from scratch - as the .BAK version indicates:)

Share this post


Link to post

Hi, friend. Do you have any progress to report on your very promising WadEdit? The last version we saw was back in January, and I was wondering if there was a new version.

Update: Never mind. I visited your web-site and read about all of the new features and improvements. Keep it up.

Share this post


Link to post
Lüt said:

And somewhere in all that jibberish lies his plans for world domination...

Or a really big bomb.

Oh come now, that was a completely harmless C++ code snippet. Yup. No plans for world domination in there... Ok, I admit it: I want a donut. Other than that, though, I'll let the world keep running itself.

For now.

Oh, and if you're interested in my plans for this evening, I'll be doing the same thing I do every night. Trying to take over the... uh... nevermind. I've said too much.

Share this post


Link to post
deepteam said:

Hi John,

DeeP is now DeePsea (a windows editor since about '97).

A straight IWAD save from DeePsea for 14MB DOOM IWAD takes less than 2 seconds on my machine - a PIII800, 256mb (just did it)- including all that .bak stuff. But it's about the same when it was a PII450.

I've never worried about "time" in saving, even on a P100. Native windows disk caching does wonders. Even in DOS, smartdrive took care of things quite well.

Basically, the saves run at the maximum dtr of the disk drive (if it's not fragmented) which can be over 20MB/sec. The older "large" drives hit about 4-8mb/sec.

I suppose we differ in how we code the file I/O. And Yes, the whole file is copied and recreated from scratch - as the .BAK version indicates:)

First, it's cool to hear DeeP is now DeePsea. The couple of times I looked at the original DeeP, I always wondered how much neater it might be as a Windows app.

Second, I got tired of fussing around with this concern for speed, so I took some actual benchmarks. I copied the roughly 12 MB DOOM.WAD file using Windows Explorer, which took less than 2 seconds as you suggested. I then made some edits in WadAuthor that would not force a node rebuild, and the save for the full file took less than 2 seconds.

In short, I guess I can quit worrying about speed (grin). It's funny how software goes. I forget who said it, but where software is concerned, premature optimization is the root of all evil. Now I can just write the darned thing.

Share this post


Link to post

Now we both have benchmarks - hahaha. I think the only speed issue that Rex? referred to is related to nodebuilding. So everybody stand up and cheer! Make those 20mb WAD files without fear of growing hair.

The windows thing is so much easier to code for. There were a few tricky things that had to be resolved to emulate some DOS tricks, but overall it's duck soup<g>

Share this post


Link to post

Node building speed? Was that one of the big selling points for your editor? That sounds kind of familiar to me. To be completely honest: I don't really understand the node building code in WadAuthor. I mean, I understand what it's doing conceptually, but it's somebody else's code, and once I got it working, I never fussed with it again aside from some obvious optimizations.

Share this post


Link to post

The nodebuilder was the first thing I ever wrote for DOOM - at that time it was way faster than BSP, like 1 minute vs 10 minutes. I wouldn't say it's -the- big selling point of DeePsea:) Depends on the processor and level size on how big a deal it is to somebody. I was also able to tune it for polyobjects - which are very tricky to design for.

The style of DeePsea is linedrawing (although prefab style is also done) with some very unique assets. My coolest thing was figuring out how to draw across lines and automatically generate intersections. Then there was the zoom thing, new port support and browsing issues. As one thing gets done, it opens up time for the next learning adventure.

Share this post


Link to post

Heh. Yeah, I imagine the whole line intersection thing was a bit tricky. That's one of the reasons, in fact, that WadAuthor has not yet supported a line-drawing set of creation tools. That is, I've never figured out the "right" way to make sure all the lines end up with the right sector tags, how to handle overlap, etc. Of course, I know a lot more now than I did then, so perhaps I can yet pull something off. It's really quite amusing to go wading through this code base that I haven't touched in about 5 years.

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  
×