Ways to implement a new map format?

[Bio Hazard]

I got to thinking yesterday: Why can't we have a new map format? im sure ZDoom could keep compatibility with old format files the same way it deals with doom format maps. I propose a change.

Could a few more bytes be put into sidedef defs to allow scaling information? since ZDoom can already scale textures, i don't see why it couldnt be done on a per-side basis (there should be seperate offsets and scaling values per upper/mid/lower basis, but i don't think the renderer is designed to do that)

and could some extra bytes be added to sector defs to allow texture offsets and scaling information? again, the code is already there to do it real-time with scripts, so i dont see why it couldnt be done on a per-sector basis

I'm not sure how ZDoom could know what format it is, but I assume that it could be detirmined the same way hexen format is differintiated from doom format. if it cant, why not make a FRMTINFO lump that contains the version number of the target ZDoom version?

It might take a while for the map editors to implement support for the new format, but i'm sure it could be done...

good idea or completly impossible?

I do realize that nobody is going to agree with me and i will get flamed for having an idea because thats just how this community is. But that won't stop me. i am able to ignore people if i dont like what they say...

[Wasted Youth]

I think this would be a nice feature. I have had times I wish this feature exsisted.

[Nmn]

You should contact with my Programmer (praise him too)-Grubber. We used to discuss the new map format ideas many times, altough I'm green as fresh cannabis in programming, I remember he mentioned a lot of things, like floors and ceilings having their own light values (so we don't have to use transfer_ceilinglight etc.). I've also learned that models will probably never implemented to Zdoom, because it's engine is not polygonal. Those were all concepts, but very interesting ones.

On another note, believe it or not, he had the idea of the "titlemap" before it was implemented in Zdoom. (altough we named it "logomap")
o_O

Praise the Programmer

If I wished anything in this new map format it would definitely have to be flawless 3d floors (either portals or not-so-buggy stacked sectors) with the ability to move between each portal upon hitting the border (F_Sky floor/ceiling).

[Chilvence]

I've often thought this would be a good idea, and with Doom Builder around, it would be easy enough for whoever implements this new format to build an up to date editor to suit it. But its something that needs a much bigger scope than just one port - think a global rethink of how many things are achieved, involving anyone who would have an intrest in such a thing. After all, if its was to be done, it should be done once, and done well.

[HotWax]

Haven't you figured out by now that port authors will never work together? Do you see any other port implementing support for any of ZDoom's extra features? I don't see this any different. Though I doubt Randy will even consider it at this point, if a new format is going to be made it's going to be ZDoom-only.

[Nmn]

Do you see any other port implementing support for any of ZDoom's extra features?

Zdoomgl?

and Zdoom has Boom features, and it's an another source port.

[jallamann]

Legacy is aiming towards zdoom compatibility...

[HotWax]

ROFFLE!!!!

No, seriously though.

ZDoomGL is ZDoom with OpenGL. So duh.

ZDoom has Boom features because Randy rocks.

[Graf Zahl]

Haven't you figured out by now that port authors will never work together? Do you see any other port implementing support for any of ZDoom's extra features? I don't see this any different. Though I doubt Randy will even consider it at this point, if a new format is going to be made it's going to be ZDoom-only.

So what? Due to the abundant features ZDoom maps are incompatible with any other source port anyway. I'd say yes for an extended map format that would be a more comfortable means to get all the level information in.

Right now the limits imposed by the old map formats are:

- The thing/linedef flags field is 16 bit even though there are several more bits that should be supported
- A line id has to be set by line special as it is now making it unnecessarily tedious, especially if you want to use a line special on that line
- Texture offset information is far too limited. It would be preferable to have scaling values for all 3 textures on a linedef
- Texture scaling information would be nice as well
- For sectors texture offset, angle and scaling values could be put into the map format itself.
- Several fields which are limited to one byte or word could be extended to a full 32 bit integer
- ZDoom could use a few more line trigger types than it has right now.

The only thing holding it back is the lack of support by editors. Now, I am quite certain that DoomBuilder and DeepSea would have support in no time but what about those who still use WadAuthor (as bad and obsolete as it is...) or other older editors? Not to mention all the WAD tools like node builders etc.

[Enjay]

- Texture offset information is far too limited. It would be preferable to have scaling values for all 3 textures on a linedef

Offset values would be good (linked by default?). The number of times I've wanted to offset an upper texture by a different value to another texture on the same line...

[farlowj]

It would also be helpful for adding more LineID types, like Chris said about the heightmap thingie. As long as the map format is something ZDoom understands, abstract concepts of map construction can be achieved easier.

For those of you who don't feel like figuring that statement out: ZDoom could do more stuff.

[Graf Zahl]

- Texture offset information is far too limited. It would be preferable to have scaling values for all 3 textures on a linedef

Offset values would be good (linked by default?). The number of times I've wanted to offset an upper texture by a different value to another texture on the same line...

That's what I meant. You'd need both scaling and offset for full flexibility.

[Bio Hazard]

graf, you know the code pretty well, about how hard would it be to pull off a format change like this?

[Graf Zahl]

So here's what I propose:

1. Things:

The thing format is the one that needs the least adjustment. There are no new fields that are required but some should be extended.

Code: Select all

struct ExtMapThing
{
	unsigned short thingid;
	short		x;
	short		y;
	short		z;
	short		angle;
	short		type;
	int			flags;
	short		special;
	short		args[5];
};

special and the args are extended to 16 bits and the flags field to 32 bits.

The following flags should be available:

Code: Select all

// old flags:
MTF_EASY			0x0001	// Thing will appear on easy skill setting
MTF_MEDIUM			0x0002	// Thing will appear on medium skill setting
MTF_HARD			0x0004	// Thing will appear on hard skill setting
MTF_AMBUSH			0x0008	// Thing is deaf
MTF_DORMANT			0x0010	// Thing is dormant (use Thing_Activate)
MTF_FIGHTER			0x0020
MTF_CLERIC			0x0040
MTF_MAGE			0x0080
MTF_SINGLE			0x0100	// Thing appears in single-player games
MTF_COOPERATIVE		0x0200	// Thing appears in cooperative games
MTF_DEATHMATCH		0x0400	// Thing appears in deathmatch games

MTF_SHADOW			0x0800
MTF_ALTSHADOW		0x1000
MTF_FRIENDLY		0x2000
MTF_STANDSTILL		0x4000
MTF_STRIFESOMETHING	0x8000

// new flags:
MTF_NOSTATISTICS	0x10000	// object doesn't count for kill or item score (useful when using monsters in cutscenes etc.)
MTF_STEALTH			0x20000 // turn this into a stealth monster without the need of using DECORATE
MTF_DONTMORPH		0x40000	// makes a monster unmorphable (and yes, this is really needed!)
MTF_NOTRIGGER		0x80000	// this object cannot trigger any special line
							// the rest should be reserved for later

2. Linedefs

Two new fields and all fields should be doubled in their size. 32 bit indices for vertices and sidedefs would allow much larger levels than are possible now without any real restrictions in complexity.
Again the flags field should be extended as well to allow setting all current line flags and possible future extensions. The line activation type should be moved into its own field to allow for some extensions in the future. Activation should be controlled by bit fields so that differentactivation types can be combined on one line (like a line that can be shot and pushed for example.)
Of course the line id should be settable directly in the editor, not indirectly via line special.

Code: Select all

struct ExtLineDef
{
	short		lineid;
	int		v1;
	int		v2;
	int		flags;
	short	activationtype;
	short	special;
	short	args[5];
	int		sidenum[2];
};

#define ML_BLOCKING			0x0001	// solid, is an obstacle
#define ML_BLOCKMONSTERS	0x0002	// blocks monsters only
#define ML_TWOSIDED			0x0004	// backside will not be present at all if not two sided
#define ML_DONTPEGTOP		0x0008	// upper texture unpegged
#define ML_DONTPEGBOTTOM	0x0010	// lower texture unpegged
#define ML_SECRET			0x0020	// don't map as two sided: IT'S A SECRET!
#define ML_SOUNDBLOCK		0x0040	// don't let sound cross two of these
#define ML_DONTDRAW 		0x0080	// don't draw on the automap
#define ML_MAPPED			0x0100	// set if already drawn in automap
#define ML_REPEAT_SPECIAL	0x0200	// special is repeatable
#define ML_3DMIDTEX_ETERNITY	0x0400	// let's reserve this for the future
#define ML_RAILING			0x0800
#define ML_BLOCK_FLOATERS	0x1000
#define ML_CLIP_MIDTEX		0x2000	// Automatic for every Strife line
#define ML_BLOCKEVERYTHING	0x8000

3. Sidedefs

Separate offset values for each of the 3 textures and x- and y- scaling values for each of them should be enough. Extending the sector field to 32 bit is not necessary.

Code: Select all

typedef struct
{
	short	textureoffset[3];
	short	rowoffset[3]
	short	scalex[3];
	short	scaley[3];
	char	toptexture[8];
	char	bottomtexture[8];
	char	midtexture[8];
	short	sector;	// Front sector, towards viewer.
} mapsidedef_t;

4. Sectors

Texture offset, scaling and rotating for both floor and ceiling should be settable directly

Code: Select all

typedef struct
{
	short	floorheight;
	short	ceilingheight;
	short	flooroffsetx;
	short	flooroffsety;
	short	floorscalex;
	short	floorscaley;
	short	floorrotation;
	short	ceilingoffsetx;
	short	ceilingoffsety;
	short	ceilingscalex;
	short	ceilingscaley;
	short	ceilingrotation;
	char	floorpic[8];
	char	ceilingpic[8];
	short	lightlevel;
	short	special;
	short	tag;
} mapsector_t;

5. Vertices

Let's not forget this: Extend map vertices to full fixed point precision. Way too often this lack of precision makes creating small structures a chore.

To recognize the new format I suggest to put a signature into the level header lump to allow recognizing it without resorting to the presence of a BEHAVIOR lump as is necessary for distinguishing between Doom and Hexen format.

[Graf Zahl]

graf, you know the code pretty well, about how hard would it be to pull off a format change like this?

One day of work at most. That does not include changing all the mapping tools though.