Quasar
Moderator
Posts: 4615
Registered: 08-00 |
Graf Zahl said:
Why not do a text based format? That would make things much easier, eliminate most of the need for version control and also makes many of the awkward multi-format handling unnecessary. And if a database for property was created it could be ensured that if a feature is supported it is done the same way everywhere.
There are so many problems with a text-based format, though. Number one problem is specifying yet another input language, and this time one that people actually agree on. I would personally want it to use a syntax compatible with libConfuse, but that's not really any good for zdoom which uses the Raven SC parser for all its scripts.
Also, going to text-based IO for maps would pretty much eliminate a very important tenet of the project, and that is gaining editor utility support. As is, DOOM Builder would need relatively moderate modifications to handle a third map format. Asking CodeImp to add a new language parser (and keep in mind most of his code is in Visual Basic, too) is probably not going to get very far.
Finally, there's the issue of efficiency. The non-specific fields in my binary specification could easily be mapped to packed structures. Text doesn't map to anything, and you need a dual-loop finite state automaton parser to deal with it.
Graf Zahl said:
Most importantly, remove and mention of 'implementation specific' from the draft. Every known feature that should be supported should have a unique representation in the data. The moment you leave the specific use of flags and other properties to each port's developer we will quickly get the same mess as we have now. This should be avoided in the planning stages already.
The goal of the spec being to get several major ports (or at LEAST zdoom) to agree with the standard required these details to be left out. When specials and flags are specified, it goes a bit beyond a map format and starts to dictate how ports can implement their features. Let's see some of the problems with this, piece by piece.
Graf Zahl said:
- The thing flags word should clearly assign a specific function to each bit. If 32 is not enough extend it to 64 bits. If you want you can reserve some flags for port-specific use.
How is it possible to achieve a common denominator when there's no limit on what ports can add, and no firm overlap for what they already support? Example: 3 bits being dedicated to control the specific class appearance of items in Hexen seems a waste of 3 bits otherwise, and isn't going to help me personally when I add generalized player class support to Eternity. I added translation support to the format in order to hopefully cover this kind of thing. If a map says its preferred translation is Hexen, then you understand its flags field is in Hexen format. It requires more translation/conversion code, but certainly not much more than zdoom is already using.
Graf Zahl said:
- The specials for things and lines should clearly differentiate between Doom-format and Hexen-format. If the records themselves are the same size for both I recommend against using the presence of BEHAVIOR as the deciding factor. And Hexen-type specials should be standardized so that every implementation must adhere to the same name and function for each number. For Doom-format it is too late to do that but for Hexen it is not.
Eternity looks at things quite differently when it comes to support of Hexen-style map specials, and the ones I've already begun to implement are not strictly Hexen/zdoom compatible because I disagree with being bound to limitations of the Hexen map format -- that's mainly the point of this proposal. For an example, take a look at the parameterized linedefs documented in the Eternity editing reference. By using ExtraData, it is possible to use these specials in DOOM -- but it is not convenient, precisely because you need ExtraData.
Eternity also implements a more general trigger system than Hexen. Player/monster/projective activatability statuses are de-wed from the impact/push/walk/etc activatability statuses, and the one-sidedness, repeatability, and other properties are also capable of being specified independently. To require me to switch over to the more limited Hexen idea of PLAYERIMPACT instead PLAYER | IMPACT would be a step in the wrong direction.
Unlike zdoom, I don't even have the luxury of combining normal line types with the Generalized/Parameterized line system, because my old line types must have certain quirks, limitations, and special cases required for compatibility, but that shouldn't be present in the latter system. If I had to combine these systems, I would be facing a rewrite of tens of thousands of lines of code, possible sacrifice of compatibility, and a lot of annoyances.
Using bits of the special to mean certain things is certainly a tempting idea, however it excludes use of a significant range of linedef special numbers and introduces more issues that will agitate cross-port compatibility.
Graf Zahl said:
where 'identifier' is a 4 character token that names the property (and should be registered by the commitee you suggest) to be defined and 'value' is the value being assigned (the format depends on the property.) These are easy to skip in the loading process and avoid having to define extended versions of the various records for each new feature.
I'm a little puzzled by this suggestion because it is extremely close to the mechanism I already suggest for implementation-dependent fields (meaning specifed by one port or another and not an official part of the standard).
Graf Zahl said:
One thing that can be omitted IMO is the BLOCKMAP lump. Even for the largest maps I know the internal blockmap builders need only fractions of a second to build it so there really is no need to waste space for it. AFAIK the only port which doesn't have a BLOCKMAP builder included is Legacy so just for that I see no need to implement it.
Regarding nodes, there's some room to save space. Most of the properties of a seg can be calculated at load time. There is no need to store the angle and the offset. Both values can be quickly retrieved from the linedef they belong to. Reading these from the lump only makes them susceptible to bugs in the node builders. (ZDBSP and WARM definitely have problems with the offset value.) Even the direction is easily calculated by checking the distance to the linedef's vertices so you can cut down a seg's size from 24 bytes to 12 bytes without sacrificing any information (and as we all know, segs can become by far the largest resource in a WAD.)
Again, however, these requirements/changes begin to dictate port features and would require changes to all implementing ports to calculate an appropriate-size blockmap or to calculate missing seg data. While the original reason for adding that seg data (speed) is less of a concern now, it's still convenient to have it ready on map load. My format aimed to require the most significant changes to implementing ports be that of widening their internal data type fields, which seemed a good goal to me, though I may be mistaken.
|
10-24-05 04:43 
