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

32-Bit Map Format Proposal

Recommended Posts

I think instead of demanding source ports just change to YOUR spec graf you might want to solicit the thoughts and opinions of other authors that don't necessarily frequent doomworld forums. It's great that you've taken "charge" of this but I doubt all port authors are just going to jump to your spec without thought or question. And to me, again not being a programmer but a player/minor mapper/multiplayer server admin it seems like restricting 8 character mapnames is a step in the WRONG direction.

Share this post


Link to post
Mancubus II said:

I think instead of demanding source ports just change to YOUR spec graf you might want to solicit the thoughts and opinions of other authors that don't necessarily frequent doomworld forums. It's great that you've taken "charge" of this but I doubt all port authors are just going to jump to your spec without thought or question. And to me, again not being a programmer but a player/minor mapper/multiplayer server admin it seems like restricting 8 character mapnames is a step in the WRONG direction.

Err...

Julian Hope said:

I have an alternative to this extradata naming lump: reverse the map lump name, fill with # or _ or whatnot for lumps names < 8.

"E1M1"     becomes "####1M1E"
"TITLEMAP" becomes "PAMELTIT"
"FACTORY"  becomes "#YROTCAF"
Name collisions should end up being minimal. What do you think?

Share this post


Link to post
Mancubus II said:

It seems like restricting 8 character mapnames is a step in the WRONG direction.



All other alternatives create bigger problems. This seems to be the safest way to do it IMO. As soon as 8-character names are involved you can no longer uniquely reference the lump.


Besides, I am not disallowing 8-character map names. I am only disallowing extradata for these maps because it can't be unambiguously assigned.

Share this post


Link to post
Julian Hope said:

I have an alternative to this extradata naming lump: reverse the map lump name, fill with # or _ or whatnot for lumps names < 8.

"E1M1"     becomes "####1M1E"
"TITLEMAP" becomes "PAMELTIT"
"FACTORY"  becomes "#YROTCAF"
Name collisions should end up being minimal. What do you think?



For names shorter than 8 characters not much is gained. For 8 character names you can easily construct lots of cases (even sensible words) that might cause problems.

Share this post


Link to post
Graf Zahl said:

For names shorter than 8 characters not much is gained. For 8 character names you can easily construct lots of cases (even sensible words) that might cause problems.

Examples?

Share this post


Link to post
Julian Hope said:

Examples?

The word "LEVEL" backwards is unchanged.

A bigger concern for me is that the backward name could easily clash with an existing WAD entry. Having a special symbol (like '#') in the name is a good protection against such clashes.

Also a backward name (like ROT-13) is just weird for the user. While user interaction with these names is supposed to be small (the ports and editors deal with it), they will see this lump-name from time to time, may need to manually delete it, etc..

Share this post


Link to post

i'm for the 7-char-only rule... remember that the maps can have real-world names seperatley (MAP07 = "dead simple"). i doubt anyone not using slige would get up to MAP9999

Share this post


Link to post
Mancubus II said:

I think instead of demanding source ports just change to YOUR spec graf you might want to solicit the thoughts and opinions of other authors that don't necessarily frequent doomworld forums. It's great that you've taken "charge" of this but I doubt all port authors are just going to jump to your spec without thought or question. And to me, again not being a programmer but a player/minor mapper/multiplayer server admin it seems like restricting 8 character mapnames is a step in the WRONG direction.


I see what you are saying, but Graf is doing the right thing by developing a specification in the public domain. Ultimately it is his decision what goes into the specification and it remains to the port authors as to whether they choose to implement it. In the same way that ajapted established a standard for nodes built for GL renderers, Graf is doing the same for an extended map format. We should support him in that process and I do not think there is a better way of doing this apart from sticking every port/editor author on a plane to his location, hiring out one hotel and a conference centre for us all.

(Should Graf want to do the conference I'll have a room with a view please :).

Share this post


Link to post

DarkknightXC praised Graf:
...

I'd like to point out Quasar started this topic with a public spec and that "Graf's spec" is a lightly modified version of Eternity's extradata lumps.

Ajapted said:

The word "LEVEL" backwards is unchanged.

A bigger concern for me is that the backward name could easily clash with an existing WAD entry. Having a special symbol (like '#') in the name is a good protection against such clashes.

That's why, with the system I propose, "LEVEL" would become "###LEVEL". Counter-examples have to be reversible 8-letter words. You can find some that's for sure but, like I said before, this reduces name collision to a minimum without sacrificing 8-letter lump names.

Share this post


Link to post
Julian Hope said:

I'd like to point out Quasar started this topic with a public spec and that "Graf's spec" is a lightly modified version of Eternity's extradata lumps.


Apologies if I've misdirected any praise/abuse (delete as appropriate). I support this effort as a whole and still want a room with a view :).

Share this post


Link to post

sod it, why not just copy ms-dos's long file name hack

MYPOINLTESSLYLONGLEVELNAME1
MYPOINLTESSLYLONGLEVELNAME2
MYPOINLTESSLYLONGLEVELNAME3
MYPOINLTESSBOSSBATTLELEVEL

becomes:

MYPOI#01
MYPOI#02
MYPOI#03
MYPOI#04

and have:

(MYPOI#01)

global.stuff
{
mapname="MYPOINLTESSLYLONGLEVELNAME1"
}

and dissalow non [A-Z0-9] map names while your at it so the # cant possibly clash

Share this post


Link to post

Because it introduces a control lump or is ambiguous. Both are undesirable here.

Come on! The last page of this discussion was only concerned with the naming of the lump. Is this really such a big issue?

What's the problem with disallowing 8 character names to reduce the amount of potential problems? Some people here behave as if such a limitation would be the end of the world.

To put this into relation:

Aside from ZDoom's TITLEMAP I have seen one map so far that uses an 8 character name (the credits in Simplicity.) Is it really worth implementing a bloated mechanism or risking name clashes for something this rare (and this easily avoided)?

Share this post


Link to post
cycloid said:

sod it, why not just copy ms-dos's long file name hack

Because (imo) the burden it places on the level editor authors would be too great.

Share this post


Link to post

Yes, and it's completely unnecessary. I've never seen a WAD with more than 99 maps in it, and assuming we choose the add-[-to-beginning-of-maplumpname system, you can in principle use MAPxxxx to have 9999 logically and consistently named maps in a single wad.

Remember that the map lumpname is just a label for the map, and the end user never needs to see or use it. The MAPINFO lump should be used to give the maps pretty long names (and unique numbers if they have weird, nonstandard names).

I'll also use this opportunity to remind you of the Joint MAPINFO spec, which is still unfinished. Here's the latest draft.

Share this post


Link to post
smite-meister said:

Remember that the map lumpname is just a label for the map, and the end user never needs to see or use it. The MAPINFO lump should be used to give the maps pretty long names (and unique numbers if they have weird, nonstandard names).
[/url].



The only place where it is used by the player is a 'map' console command. But for something like that standard names are better anyway.

Share this post


Link to post

yeah that was my previous point, number maps MAP01 to MAP99, if 99 isnt enough then you can go up to MAP9999. even a 99 episode megawad with 99 maps per episode is only 6 chars: E99M99... !

Share this post


Link to post

I think you all miss the point about non-standard map names. It allows people (NOT CODERS BUT ACTUAL USERS) to jump to maps from different games (i.e. wads) within the same session. In that regard, a more "explicit" lump name is useful.

It's tempting to dismiss the issue as unimportant as it is not that fundamental technically. However, it's a feature degradation. IMO, 8-letters is already hard enough a limit.

But I still think reversing the lump name and padding with # if needed is a good enough workaround, plus it's straight-forward to implement.

As a side note, making a standard IS easy. What takes time are details like these ones. If you guys don't wanna discuss these, then don't publish a public draft.

Share this post


Link to post
Julian Hope said:

I think you all miss the point about non-standard map names. It allows people (NOT CODERS BUT ACTUAL USERS) to jump to maps from different games (i.e. wads) within the same session. In that regard, a more "explicit" lump name is useful.

It's tempting to dismiss the issue as unimportant as it is not that fundamental technically. However, it's a feature degradation. IMO, 8-letters is already hard enough a limit.


It's so easy to dismiss because nobody uses it.
And frankly, before thinking up more convoluted schemes to allow 8 character names I'd rather invest the time in drafting a layout how to load stuff from .zips instead of .wads. That'd be more useful.
The WAD format is so painfully limited that one more restriction to ensure more robustness isn't that bad. Some people here even suggested to disallow non-standard names completely!

Share this post


Link to post
Julian Hope said:

I think you all miss the point about non-standard map names. It allows people (NOT CODERS BUT ACTUAL USERS) to jump to maps from different games (i.e. wads) within the same session.

This is of very little use, since even Doom1 and Heretic have overlapping mapnames, and if you wanted to jump from a Doom1 map to a Doom2 map, you would (in principle) have to rebuild your texture cache and your internal MAPINFO representation using the other IWAD before running the new map.

Or did you mean jumping from one PWAD to another? Again there are the texture cache and MAPINFO problems, and AFAIK by far most PWADs still use standard, overlapping, maplumpnames. Even if they do use custom mapnames, there is still no guarantee against random name collisions.

If you want to load several PWADs in a single session and jump between them, a better alternative would be to add an optional wad-selector prefix to the map command:

map wad3::MAP07
meaning: Re-read MAPINFO and textures using wad3 as the primary source, then start MAP07 from wad3.

Share this post


Link to post
Graf Zahl said:

It's so easy to dismiss because nobody uses it.
And frankly, before thinking up more convoluted schemes to allow 8 character names I'd rather invest the time in drafting a layout how to load stuff from .zips instead of .wads. That'd be more useful.
The WAD format is so painfully limited that one more restriction to ensure more robustness isn't that bad. Some people here even suggested to disallow non-standard names completely!

If you think this is not worth your precious time, don't do it. I too would like to see zip file support but that's not the point. You entered this discussion bragging about every single point and taking leadership for no apparent reason. And when you get feedback regarding your own solutions, you don't accept criticism?

Noticed the thread starter simply gave up?

I made an honest proposal because I thought it could please people who were against your idea just because of this 8-letter limit. I'm just following your own idea here whereas, to be honest, I wouldn't make such a silly file format with so many limitations. Anyway, you wanna do it that way? Fine with me, people object about a possible limitation, I try to find a solution within the boundaries YOU defined. Now if you just wanna write YOUR own standard, do it. Don't come and complain later when no one uses it.

Share this post


Link to post
smite-meister said:

...

I meant this:
doom -file TC1.wad TC2.wad

then jump from one level to another from within doom. Suppose the two TCs are for Doom2, then if both TCs use standard map names, you're fucked and end up having maps from TC2 only.

The possibility of jumping from one map to another from its lump name is useful to modders when they need to make comparisons between different versions of their maps. They don't wanna specify a "final" episode, just random maps or map parts to be able to choose and design.

These extradata will not be only used for production-ready wads and, as such, they shouldn't introduce new limitations to an engine that already has far too many.

Share this post


Link to post
Julian Hope said:

I meant this:
doom -file TC1.wad TC2.wad

The possibility of jumping from one map to another from its lump name is useful to modders when they need to make comparisons between different versions of their maps. They don't wanna specify a "final" episode, just random maps or map parts to be able to choose and design.

Come on, I don't think any modder/author will save each version of each of his maps using a unique custom lumpname, which is the only way that could work.
Adding the wad-prefix for the map command is the easiest way to do this, and that way you can limit yourself to standard mapnames. Comparing two versions of MAP14:

doom -file TCv1.wad TCv2.wad
map TCv1::MAP14
map TCv2::MAP14
Best of all, this can be done as a sourceport feature (if seen necessary) and thus does not need to affect the ED standard in any way.

Share this post


Link to post
smite-meister said:

If you want to load several PWADs in a single session and jump between them, a better alternative would be to add an optional wad-selector prefix to the map command:

map wad3::MAP07
meaning: Re-read MAPINFO and textures using wad3 as the primary source, then start MAP07 from wad3.



And that doesn't even take into account that various other resources might be changed as well by the WADs. Re-reading global data is a futile undertaking in most cases so anything requiring such a step is doomed to fail anyway.

But qualifying a map by the WAD name is an interesting idea.

Share this post


Link to post
Graf Zahl said:

But qualifying a map by the WAD name is an interesting idea.

Question is: what to use? Filename? ID name?

Share this post


Link to post

I'd rather invest the time in drafting a layout how to load stuff from .zips instead of .wads. That'd be more useful.

Doomsday has had this feature for a while now. Lumps can be placed directly into a compressed ZIP/PK3, you can use the folder hierarchy as namespaces, theres rules for enforcing lump load order, your not limited to 8 char names etc etc etc.

Share this post


Link to post

I just finished reading the thread and proposed specification and so far everything's fine with me.

Share this post


Link to post
Julian Hope said:

These extradata will not be only used for production-ready wads and, as such, they shouldn't introduce new limitations to an engine that already has far too many.

Standard DOOM.EXE does not support arbitrary map names (be it 8 letters or less), so it's hardly a "new limitation".

Share this post


Link to post

I haven't given up on anything, there just hasn't been much for me to discuss lately. I'd like to see this come out in a way that will be both sc_man and libConfuse compatible, and that will actually garner support from editors. We still haven't established that any editors are prepared to implement this, and until somebody says they're interested, we can push specs around for years and get nothing done.

Share this post


Link to post
Quasar said:

We still haven't established that any editors are prepared to implement this, and until somebody says they're interested, we can push specs around for years and get nothing done.



That's the problem. The only one who has shown some interest so far was SlayeR who said he'd add it to Slade.

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
×