Ways to implement a new map format?

Archive of the old editing forum
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.

Ways to implement a new map format?

Postby Bio Hazard » Sun Jan 23, 2005 1:12 pm

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...
User avatar
Bio Hazard
Lord of the Lord of Nitpicking.
 
Joined: 15 Aug 2003
Location: ferret ~/C/ZDL $

Postby Wasted Youth » Sun Jan 23, 2005 1:20 pm

I think this would be a nice feature. I have had times I wish this feature exsisted.
User avatar
Wasted Youth
 
Joined: 05 Jan 2004
Location: Earth

Postby Nmn » Sun Jan 23, 2005 1:22 pm

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 :rock:

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).
User avatar
Nmn
 
Joined: 16 Apr 2004

Postby Chilvence » Sun Jan 23, 2005 2:12 pm

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.
User avatar
Chilvence
I had been waiting for Doomscript....
 
Joined: 11 Aug 2003

Postby HotWax » Sun Jan 23, 2005 2:44 pm

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.
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby Nmn » Sun Jan 23, 2005 2:59 pm

HotWax wrote: 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.
User avatar
Nmn
 
Joined: 16 Apr 2004

Postby jallamann » Sun Jan 23, 2005 3:00 pm

Legacy is aiming towards zdoom compatibility...
User avatar
jallamann
isn't very active on the forums at all
 
Joined: 24 May 2004
Location: Ålesund, Norway

Postby HotWax » Sun Jan 23, 2005 3:10 pm

ROFFLE!!!!

No, seriously though.

ZDoomGL is ZDoom with OpenGL. So duh.

ZDoom has Boom features because Randy rocks.
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby Graf Zahl » Sun Jan 23, 2005 3:26 pm

HotWax wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Enjay » Sun Jan 23, 2005 3:39 pm

Graf Zahl wrote:- 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...
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Postby farlowj » Sun Jan 23, 2005 3:48 pm

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.
farlowj
If at first you don't succeed, skydiving is not for you.
 
Joined: 16 Feb 2004
Location: Michigan

Postby Graf Zahl » Sun Jan 23, 2005 3:58 pm

Enjay wrote:
Graf Zahl wrote:- 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Bio Hazard » Sun Jan 23, 2005 4:13 pm

graf, you know the code pretty well, about how hard would it be to pull off a format change like this?
User avatar
Bio Hazard
Lord of the Lord of Nitpicking.
 
Joined: 15 Aug 2003
Location: ferret ~/C/ZDL $

Postby Graf Zahl » Sun Jan 23, 2005 4:37 pm

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 allExpand view
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 allExpand view
// 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 allExpand view
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 allExpand view
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 allExpand view
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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Graf Zahl » Sun Jan 23, 2005 4:40 pm

Bio Hazard wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Next

Return to Editing (Archive)

Who is online

Users browsing this forum: No registered users and 3 guests