Defining a new enhanced source port standard (Boom+/MBF+)

[kb1]

Recent threads have revived discussion on the current state of compatibility between source ports that strive for limit removal and mod capability enhancement. Currently, the best a map author can hope for, in terms of modding capability, that can be expected to run in most all source ports, is the vanilla format, plus the additions afforded by Boom and MBF. After the release of Boom and MBF, port authors began adding features that, for whatever reasons, were not accepted and adopted by all source devs. Of course, this forces map authors to choose a port to mod for, if they want those extra capabilities, and it forces players to use that port to play these maps.

 

There will always be advanced, port-specific features, and that's a good thing. It promotes continuous advancement. But, it would be nice if port devs could add some of those features in a standard way that all ports could take advantage of.

 

This thread is to serve as a place where we can discuss a possible update to this standard, beginning with a narrow focus on which features can be readily added, without conflicting with each port's philosophy and direction.

 

This idea has been attempted before, and failed, I think because the proposals did not encompass all possibilities, or did not take into account some capabilities of this port or that. Because of this, I suggest some ground rules:

• Start small - For this first phase, we should only include things that all ports can use. For example, 3D floors is out, as it requires drastic changes to the renderer, and game logic. But a replacement for, say 242: Boom water/prop transfer is a good place to start
• Future Extensibility - There should be no updates that prevent the ability to expand capabilities in the future.
• Use existing port-specific capabilities wherever possible - The new standard should leverage on the existing capabilities afforded by advanced ports such as ZDoom, Eternity, Legacy, Edge, Vavoom, etc. No need to re-invent the wheel. But we may have to modify how they are accessed, to fit into a global standard.
• Research each addition - We don't want to, for example, use a linedef number that a source port is already using. Boom took the bulk of linedef numbers, leaving a small subset. We should compile lists of unique scarce resources per port, to see what's available
• Dev Review - For this to succeed, the devs need to be involved. The port devs intimately know how their port works, and they have plenty of good ideas to contribute. We must collaborate like never before, if this thing is to get off the ground.

 

Eventually, after converging on what this update should entail, these ideas can be compiled into a specification, which will be submitted for modification/approval. That can, in turn, be turned into a source code module, which, not unlike Boom, can be dropped into a project with minimal changes, improving the chances of wide adoption.

 

But, we're nowhere near there yet. This thread can be a place for new ideas to be included in that standard. Please restrict replies to discussing ideas for an upgrade to our current standard, if possible.

[Graf Zahl]

10 minutes ago, kb1 said:

• Research each addition - We don't want to, for example, use a linedef number that a source port is already using. Boom took the bulk of linedef numbers, leaving a small subset. We should compile lists of unique scarce resources per port, to see what's available

 

For that one I can already say that all numbers between 272 and 500 are out. There are countless conflicts between ZDoom and Eternity here, and Eternity is still giving the Hexen specials an ascending number in this area. 500 and up have never been used by any port but to be on the safe side, considering that Eternity will continue allocating numbers here, only start from 600 up for new values.

[Albertoni]

There's just one thing I'd want in prboom, and thus in a new standard. Transfer Wall Brightness. Yeah, I know there are a thousand tricks to fake it, it's just a matter of ease of use.

[kb1]

4 hours ago, Graf Zahl said:

For that one I can already say that all numbers between 272 and 500 are out. There are countless conflicts between ZDoom and Eternity here, and Eternity is still giving the Hexen specials an ascending number in this area. 500 and up have never been used by any port but to be on the safe side, considering that Eternity will continue allocating numbers here, only start from 600 up for new values.

You know, I was thinking about that: Maybe the linedef type should be internally represented as 32-bit, with a set of game, or even port enums to differentiate - something like this:

#define GAME_DOOM    (0x00000000)
#define GAME_HERETIC (0x00010000)
#define GAME_HEXEN   (0x00020000)

Maybe even in combination with this:

#define PORT_VANILLA   (0x00000000)
#define PORT_LEGACY    (0x00100000)
#define PORT_ETERNITY  (0x00200000)

Most of these would map to the same effect, as with &0x0000FFFF, but lines with effect 272 - 500 could get mapped internally to unique linedef actions. For older port-specific maps, ports could auto-apply PORT_XXXX on map load, providing support. A new MAPINFO flag could specify PortType and MapType, with PortType defaulting to the actual port you're playing, and MapType being determined with heuristics. These could also be set via a command-line override,, or maybe even a special lump for each setting, allowing -file LEGACY.lmp to force a mapset to use Legacy-type linedefs.

 

The idea being that, once the engine determined which game and port that map was for, linedefs could be interpreted based on which port ans game the map was defined for. This would suggest the need for something I've wanted to see for years: A map type, and port type identifier. This is easy in UDMF, and, of course, you can determine a Doom vs. Hexen format with heuristics, or the presense of the BEHAVIOR lump, but ZDoom's Doom-in-Hexen format might require more. A standard map type identifier could be part of the standard, and it'd make engines and editor's job a whole lot easier. ZDoom currently uses conversion tables to disambiguate linedefs and things, right?

 

One more identifier that I think is important is Standard Version Number. This will provide a mechanism to handle compatibility in both directions: future and past. So, if implemented in MAPINFO, you could exactly describe a map as, for example: DOOM/ETERNITY/LEVEL 1 Standard. This would be a beautiful thing for map viewers, editors, and the game engine itself. For the first time, we could definitively tell the user "This map has features I don't understand. Load anyway?". With something like that, even if your port cannot support the map's features, you can tell the user.

 

At home I have a launcher I've been working on, and a database of Doom WADs. The database program has a function that tries to determine which port to launch, for each WAD. That code is multiple thousands of lines long, and it only does a fair job at properly choosing the right port! It's a nightmare, but it could be avoided by marking the maps with identifiers. What do you think?

 

Another possibility is simply to use the unused remaining linedef types, and not be concerned with being able to load an old port-specific map for Port X in Port Y. I think this kinda misses the point, and would be unfortunate. There's no reason why we cannot do better, except that it requires more careful planning.

 

Boom tried to be wise, in the allocation of linedef types. They tried to put the most useful linedefs numbers below 256, to provide support to editors that only supported 8-bit linedef numbers. Similarly, we should put the most useful effects in the low 16-bits, and the more exotic effects can be only accessible via UDMF.

 

I think UDMF and DECORATE should be part of this new standard, not as Phase 1, but for an eventual goal. There are good arguments for both: UDMF can specify any and all possible additions to the map format, by its very nature. And DECORATE is a complete, compact, time-tested thing/frame definition language. Even the addition of scripting could be compartmentalized by defining the script language type at the top. I'm big on global identifiers that can be used to define how to interpret what comes next, as it provides future flexibility.

 

3 hours ago, Albertoni said:

There's just one thing I'd want in prboom, and thus in a new standard. Transfer Wall Brightness. Yeah, I know there are a thousand tricks to fake it, it's just a matter of ease of use.

I noticed that from the other thread. This sounds like a good, easy-to-implement addition. There's another thread from a few years ago that has some more linedef suggestions, as well as thing codepointers. I'll see if I can't hunt it down.

[Arctangent]

12 minutes ago, kb1 said:

DECORATE should be part of this new standard,

There are reasons why it shouldn't, unless the universal parser is designed to not allow horror stories.

[kb1]

7 minutes ago, Arctangent said:

There are reasons why it shouldn't, unless the universal parser is designed to not allow horror stories.

I don't think anyone tries to add bugs in their implementation. The bug you linked references a version of DECORATE that's beyond an initial "DECORATE-lite" as it mentions a code pointer with arguments i.e. an ACS code pointer. This would probably be considered too advanced for an initial global adoption of DECORATE, especially when many source ports don't even support Hexen - where ACS originated.

 

But, yeah, good point: Be careful to implement DECORATE, and any other code, carefully, and do good testing.

[Arctangent]

I was not referring to the topic itself, rather randi's last post in it.

[traversd]

@kb1 asked in the other thread so this is a simple list I've made a couple of years ago. It is simple, level authoring specific (ie: it is all about level data, not other aspects of the engine or game definitions) so in this sense it probably fits the bill of being conservative XD but is also probably somewhat naive/uninformed/ignorant of bigger picture stuff.

 

Summary:

• Boom(Ex)tended run as complevel 20? (-cl20)
• What runs under -cl9 now must work under -cl20 (so -cl20 could supercede -cl9). This would mean bugs in -cl9 should remain ie: Cannot fix generalised crushers. Instead make a new generalised crusher#2 set that do work

Things to add:

• Generalised sets for the remaining major linedef specials:
  • Lighting
  • Elevators
  • Crushers (#2)
  • Transfers
  • Teleports
  • Exits (example of level authoring specific thinking - but this would allow more flexible level progression such as going back and forth between levels)
• Additional linedef specials:
  • (static) Transfer sky all tags - Transfer upper texture to all instances of f_sky1 in map regardless of tag (specials 271/272 override this one though)
  • (static) Transfer sky (reversed) all tags - Transfer upper texture to all instances of f_sky1 in map regardless of tag (specials 271/272 override this one though)
  • (static) Warp floor (speed & warp pattern set by x & y offsets) - Apply some portal/fluid warp affect to floor of all sectors with same tag. Can be used for water effect or teleporters.
  • (static) Warp ceiling (speed & warp pattern set by x & y offsets) - Apply some portal/fluid warp affect to ceiling of all sectors with same tag. Can be used for water effect or teleporters.
  • (static) Warp linedef (speed & warp pattern set by x & y offsets) - Apply some portal/fluid warp affect to linedefs with same tag. Can be used for water effect or teleporters.
  • (W1/WR) Resurrect monsters in tagged sector. Only player or non-monster thing can activate
  • (W1/WR) Kill all monsters in tagged sector or 0 tag for all monsters in map (damage = thing starting health x random value between 1 and 2 to vary standard death and gibbed deaths. Only player or non-monster thing can activate

• Additional sector types:

  • No damage to player (invincible, showing godmode eyes in hud)

  • Kill anything that touches sector floor. For void deaths

  • (player only) teleport to tagged sector when player touches the floor

  • grouped sector for special action (use to make multiple sectors behave the same - ie: multi-sector lift/door or crusher. If one sector of the group is blocked from moving, all grouped sectors are also blocked). Grouping is done using the tag value.

There is more notes I made ages ago, but they need some more thought before (possibly) putting forward.

 

[Graf Zahl]

I'll be honest here: This discussion is already heading in the wrong direction, thinking about steps 5-10 before laying out the basics where to start.

 

@traversd: While most of what you propose are good ideas, I really think that this shouldn't be shoehorned into Doom's map format.

Before starting on any of that my proposition would be to add Hexen format support to PrBoom first (sans ACS for the start to keep things simple) because it already lifts a lot of the restrictions and offers more options to do things.

 

What this would require is porting over the thinker system of either ZDoom or Eternity - I'd just add the ported thinkers as duplicates to avoid interference with demos - and possibly first to port the code to compile as C++. C++ not to turn everything into classes but to have the benefit of better error checks, easy access to the STL - I really missed the vector class when writing UMAPINFO -, and easier backporting of existing C++ code - it would make it a lot easier to lift code from ZDoom to accelerate development.

 

And once Hexen format is working, add an UDMF parser. When that is done a lot of stuff will already become a lot easier because the mapping restrictions that inevitably come into play when sticking to Doom's map format will inevitably become a roadblock and crutches like Eternity's Extradata are the worst thing that can happen.

 

In other words: Defining a standard in words is not really going to solve anything because each time in the past such tossing around of ideas has resulted in a stalemate of opinions. It would be much better to actually develop a port that implements the propositions and serves as a baseline for others to follow. And this port must be PrBoom-based, so that we have a minimal baseline.

 

And most importantly: Be realistic! Ideas need to be implementable with reasonable effort.

 

[BigDickBzzrak]

 

What? One of those threads is evolving into something constructive??

Keep it up folks, this is great!

 

10 hours ago, Graf Zahl said:

500 and up have never been used by any port but to be on the safe side, considering that Eternity will continue allocating numbers here, only start from 600 up for new values.

AFAIK 3DGE uses some >800 actions, don't forget that. :]

 

One little suggestion that I would ***LOVE*** to have:

Have an effect that could render just a fake flat at some height. You know, just a flat hanging somewhere in the air, without requiring any upper/lower textures or anything (like 242).

I hope I am understandable.

 

(How would I implement that: have a dummy sector with the action, and render the fake floor at dummy floor's height. If looking at it from above, you'll see the floor flat of the dummy, if looking from below, the ceiling flat of the dummy.)

 

EDIT: OK Graf, thanks.

Edited April 22, 2017 by bzzrak : sniff sniff

[Graf Zahl]

17 minutes ago, bzzrak said:

One little suggestion that I would ***LOVE*** to have:

Have an effect that could render just a fake flat at some height. You know, just a flat hanging somewhere in the air, without requiring any upper/lower textures or anything (like 242).

I hope I am understandable.

If that were doable trivially, all ports had 3D floors by now. Sorry, but the way the software renderer works that's just not feasible.

 

[Da Werecat]

3 hours ago, traversd said:

What runs under -cl9 now must work under -cl20 (so -cl20 could supercede -cl9). This would mean bugs in -cl9 should remain ie: Cannot fix generalised crushers. Instead make a new generalised crusher#2 set that do work

What about cl11? It added things, changed things, broke things, and probably fixed some things. Right now it's the basis for the default complevel, AFAIK.

 

I was under the impression that the new standart will try to fix the old problems. That's why it should be a new complevel, not an extension of an existing one. Some bugs can't even be worked around without replacing the old behavior - monsters getting stuck on ledges, for example. I'd be interested in seeing this kind of stuff gone.

 

OTOH, if there's a possibility that the bug in question can be critical to how an existing map works, then it should be preserved in its current state. For example, if a linedef action works, but not exactly in the indended way, there's a chance that someone used it as it is, and I think that if this hypothetical cl20 is going to be the default one, it should work reasonably well with vanilla, Boom, and MBF maps.

 

Generalized crushers simply don't work, so the mapper is likely to try them, shrug (or consult the forums), and replace the action with something that works. It's highly unlikely that there are "latent" unwanted crushers lying around in the existing maps.

 

2 hours ago, Graf Zahl said:

Hexen format support

Developers typically know better, but I'm not sure I'm behind this. I think if you need a new map format for this kind of extension, you're already thinking too big. I thought it was supposed to be just an addition to what's already there, i.e. a bunch of new linedef actions, sector properties, codepointers, and an occasional bugfix.

[Liberation]

I've been hesitant over posting in the previous threads as I'm not a port developer but however would like to give my 50p's worth.

 

A basic standard for mapping should be -

• UMAPINFO
• Full BOOM/MBF
• BEX

So yes basically Prboom with mapinfo support as a phase 1, it has to be small steps otherwise port authors would fall behind or be bogged down with work they are potential not interested in.

 

Going forward you come up against issue straight away -

• HEXEN/UDMF Format - Will port authors want to go down this route? It could alienate ports straight away.
• Demo compatibility - This is a mess already, it needs to stop. The new standard needs to have only 1 compat level, if you make a video for a map that uses the new standard then it should be viewable on any engine that is supporting this and clearly supports videos. Probably more of a port issue now I think about it...  No it does need to stop, Cl this and Cl that, it needs to be standardised to move forward.
• Adding new linetypes - The fact that ports have a whole host of unique linetypes that couldn't be cherry picked due to conflicts with other ports could be an issue, it would have to be delicate operation with perhaps only the most beneficial being added in small numbers. 

 

Phase 2 would be along the lines of adding linetypes and sector features that are easy to implement for all port developers, expanding on the boom linetypes etc, while not conflicting between ports.

 

So a more futuristic standard for mapping should be -

• UMAPINFO
• Full BOOM/MBF
• BEX
• An extended list of line and sector types. 

 

At this point I think further discussion could be held, if all or most ports get to this standard with out confliction, then and only then could anything more advanced be discussed. 

Edited April 22, 2017 by Liberation

[Graf Zahl]

1 hour ago, Da Werecat said:

Developers typically know better, but I'm not sure I'm behind this. I think if you need a new map format for this kind of extension, you're already thinking too big. I thought it was supposed to be just an addition to what's already there, i.e. a bunch of new linedef actions, sector properties, codepointers, and an occasional bugfix.

Hexen format itself is not important. UDMF is but to get UDMF we need Hexen format specials so implementing Hexen format first makes sense.

Although UDMF nominally supports Doom specials, editor support for this is lacking and unlikely to materialize.

I can outright tell you that extending the Doom format will sooner or later run into a brick wall because it doesn't have sufficient fields to play with. Just have a look at Eternity's Extradata to see what this would mean.

But these are long term goals. Getting Hexen format off the ground is something that requires a lot of work because the underlying system is entirely not suitable for it. I wouldn't start on this unless I was sure that it'd lead somewhere.

 

[traversd]

16 hours ago, Da Werecat said:

What about cl11? It added things, changed things, broke things, and probably fixed some things. Right now it's the basis for the default complevel, AFAIK.

My understanding was that cl9 (boom 2.02) or cl(-1) is more the standard as I see more authors quote "tested in cl9" or "tested in prb+". I'm not aware of the differences between the two. Maybe cl(-1) is a merger of cl9 & cl11? I think cl9 is kind of a merger of cl11 & cl9 already as it allows sky transfers which are MBF in origin correct?

[Da Werecat]

7 hours ago, traversd said:

I think cl9 is kind of a merger of cl11 & cl9 already as it allows sky transfers which are MBF in origin correct?

Yeah. Well, more like the DB config for Boom has the sky transfers in addition to Boom features. As for PrBoom+, it allows sky transfers in all complevels, I think, since it's just a cosmetic feature that won't hurt if you use it in a vanilla map.

 

7 hours ago, traversd said:

Maybe cl(-1) is a merger of cl9 & cl11?

You could say that cl11 is a superset of cl9, aside from a few small differences in how some things work, or at least that's how it should be. Complevel -1 should support everything cl11 supports in order for all supported maps to work correctly. But I don't know the specifics.

[Linguica]

Could someone please make a graphic showing, like, a chart of complevels and what they mean so we can all save it and not constantly have to look up what they are?

[Gez]

All you've got to remember is 2, 9, and 11. Others are largely irrelevant.

 

But if you want a graphic, why not.

 

[traversd]

On 22/04/2017 at 10:15 PM, Liberation said:

So a more futuristic standard for mapping should be -

• UMAPINFO
• Full BOOM/MBF
• BEX
• An extended list of line and sector types. 

I'll admit I had not considered the MAPINFO component but this is essentially what I had in mind in terms of extending the the Boom 2.02 standard. Points 2 & 3 are (according to Doomwiki) "yes" to "mostly" implemented in the major active source ports - Although the table on Doomwiki relates to Boom, not Boom+MBF. I've only really thought about this in terms of additional line specials/sector types because it feels inappropriate to ask too much of the major active source port maintainers to implement a large raft of changes. Hopefully an alternative MAPINFO format and additional line specials/sector types would be considered - and since the current level of Boom features are still used heavily, it should mean that we don't need to extend/change the current features too much, otherwise we start to get into more advanced port feature sets that, that is what the advanced ports do best ;)

 

3 hours ago, Gez said:

All you've got to remember is 2, 9, and 11. Others are largely irrelevant.

Unless the other major ports have implemented Boom+MBF it feels like starting at cl9 and incorporating aspects of cl11 might afford the major active port maintainers the most consistent starting point?

 

cl9+cl11=cl20? ;)

 

On 22/04/2017 at 9:42 AM, Graf Zahl said:

For that one I can already say that all numbers between 272 and 500 are out.

What is the maximum number for a linedef special? I see in the prb+ source there is a genend value of 30000. Could that be increased to 60000 to allow room for additional generalised specials?

[traversd]

Examples of what I had noted down for some additional generalised linedef specials:

 

• Lighting
  • Trigger (S/W/G/C)*
  • Target
    • Highest adj light val
    • Lowest adj light val
    • 0
    • 255
  • Effect
    • No effect
    • Random on/off
    • Blink 0.5s
    • Blink 1s
    • Pulse
    • Fade up to target
    • Fade down to target
• Exit
  • Trigger (S/W/G/C)
  • Target
    • Next map
    • Same map
    • Tag value as map slot
      • Doom2=MAP<TAG VALUE>
      • Doom=E<TAG VALUE DIGITS 1-2>M<TAG VALUE DIGITS 3-4> ie: 0101=E1M1, 1010=E10M10
    • End Episode (play end of episode text)
    • End Game (ie: Map30 sequence) - Just read Graf's UMAPINFO post - hopefully the NextMap/SameMap/TargetMap could still work alongside any UMAPINFO definitions?
  • Pistol start next map (Y/N)
• Property Transfer
  • Trigger (S/W/G/C)
  • Target
    • Sector on front side of linedef
    • Sector on back side of linedef
    • Front side-def of tagged linedef
    • Back side-def of tagged linedef
  • Property
    • Transfer floor texture
    • Transfer ceiling texture
    • Transfer sector type
    • Transfer front side-def lower texture++
    • Transfer front side-def mid texture
    • Transfer front side-def upper texture
  • Model
    • Trigger
    • Numeric

* The 'C' in the Trigger sections means 'conveyor' and intends to be used in place of the model/change combo currently used for the existing generalise linedefs to allow non-player walkover activation (the documentation for Boom states monster can activate, but from a walkover point, even decorations can trigger which is a better option for contruction of conveyor scripting than voodoo dolls as it allows skill/gametype setting using the existing Boom thing type options.

 

++ Sector based transfers would do nothing for linedef targets but linedef targets could apply to all linedefs in a tagged sector?

Edited April 23, 2017 by traversd : Just read Graf's UMAPINFO post - hopefully the NextMap/SameMap/TargetMap could still work alongside any UMAPINFO definitions?

[kb1]

On 4/22/2017 at 4:20 AM, Graf Zahl said:

I'll be honest here: This discussion is already heading in the wrong direction, thinking about steps 5-10 before laying out the basics where to start.

 

@traversd: While most of what you propose are good ideas, I really think that this shouldn't be shoehorned into Doom's map format.

Before starting on any of that my proposition would be to add Hexen format support to PrBoom first (sans ACS for the start to keep things simple) because it already lifts a lot of the restrictions and offers more options to do things...

Yes, it is a bit early to seriously consider adding any new specials, but I do appreciate people discussing them and brainstorming about what's possible: It helps me stay focused on what we're trying to do here.

 

To be honest with you, I did not expect that you were considering spending any appreciable amount of time on PrBoom+ - I thought your commitment was on UMAPINFO (nice job, by the way!) If you are doing more with it, we should prepare to be very careful to synchronize, because I am committed to creating the first rough draft of this new specification, as well as porting my KBDoom code underneath this specification, as a fork, into the latest PrBoom+. Everyone has been "asking me about my source port", and as everyone knows, I've been holding off. A lot of that was due to procrastination, but mainly, I didn't want to just release yet another conflicting source port. Instead, I want to contribute something that encourages cross-port compatibility.

 

C++ and Hexen Format:

I can't say that I agree with two of your major goals: Conversion to C++, and Hexen support, especially in this phase. Both of these goals conflict with the idea of keeping it simple, and widely adoptable. Many ports have no immediate plans to support Hexen, Heretic, or Strife, for example. And there's a large learning curve going from C to C++, which conflicts with wide adoption - again, some people want to start with something that resembles the Vanilla/Linux 1.10 source release.

I don't want to convince you to inhibit your efforts, but I'm going to be going in a different direction. Having said that, I do not intend on writing code that conflicts with your goals, quite the opposite, in fact. But, I will not be converting my source to C++ any time soon.

 

Back to the Hexen issue: If the map editors do not yet have sufficient UDMF Doom support, that can be added. Yes, Doom editing will hit a brick wall. The fact that you cannot specify a thing Z coordinate without hacking (KBDoom optionally interprets the lower 3 bits of the Angle field as Angle, and the upper bits as Z * 8, to support thing placement on 3D floors) is a big issue. Because we are defining a new standard, I suggest taking the Doom format to its limits, before forcing a map format upgrade. Personally, I want my port to support all the other idTech1 games, but not all ports do. At that stage we can discuss a Heretic/Hexen/Strife set of specifications. However, UDMF *can* eventually apply to this spec, but it's too big for a Phase 1.

 

@traversd: Interesting ideas! This is good stuff. But, instead of fixing existing linedefs with a complevel, creating a new linedef special that has different/fixed behavior solves the issue, without adding to the dizzying number of complevels.

Complevels are there to support differences in ports that are no longer maintained. Can you imagine the confusion that can be caused by having a "original Boom 2.02" complevel, and a "Boom 2.02 + Boom Phase 1" complevel, etc.? You'd be half-way through an hour-long map, only to have a sector not operate - this is a nightmare.

I intend on having a clear separation of duties, between demo version indicators, complevels, and the modification of any existing data structure, functionality, etc. Using PrBoom+ as a base instills an awesome sense of responsibility, to avoid disrupting the demo sync apparatus, the gameplay feel, etc.

 

@Da Werecat: I must be clear about this: Having stated what I did about complevels above, I am not totally against adding a complevel in principle, but it must be for the correct reason. And, it may eventually make sense to do so, with one caveat: Only PrBoom+ supports complevels, so requiring that we, for example, must choose -cl 20 to use the new standard seems misguided. Again, complevels are there to tell the engine to emulate an OLD port. There will be fixes, but they will be in the form of new linedefs, which none of the old ports understand, so there is no conflict.

 

@Liberation: Yes, you've got the right idea: Phase 1 must remain simple and focused, and easy to add support for, if we are to expect its wide adoption. Looking at your bullet points:

• Full Boom/MBF, and BEX: Yes, this should be a prerequisite. And, BEX comes from Boom and MBF, it can be included as well.
• UMAPINFO: This is a wonderful, useful addition to Phase 1, as it provides lots of immediate mod capability, and it's relatively easy to implement (once written), and applies universally to any port.
• Extended specials: This can provide the incentive to add Phase 1 support to your port, so I think it should be included. The number of added specials is not so important. What is important, is the feasibility of adding support, without causing conflicts in port philosophy. For example, any port that supports light transfer can handle the newly discussed ceiling/wall/floor light transfer proposals.
• Complevel and demos: This standard will not ensure that a port can properly play back demos from any version - that's up to the port devs to decide how fluently the port can render demos. The standard will be independent of complevels, by design. They may seem like related concepts, but they're not.

 

[Da Werecat]

34 minutes ago, kb1 said:

complevels

I should probably clarify how I see this working.

 

I don't think that any command line parameters should be needed to activate the new features. They must all be available by default. But they should be disabled in existing complevels for emulation accuracy.

 

Since there are conscious exceptions even now (like sky transfers), some of the new features may still be allowed to work in cl9, cl2, et cetera, provided they don't wreck demo compatibility with emulated engines.

 

As for the potential "-complevel 20" or the like - this shouldn't be needed unless the changes are gonna be rolled out in several phases. New phase = old default behavior is compleveled for compatibility. Technically, this is gonna be emulation of an old engine.

 

Even if there's gonna be only one official phase, the current default behavior of PrBoom+ should be preserved, probably.

[Graf Zahl]

1 hour ago, kb1 said:

And there's a large learning curve going from C to C++, which conflicts with wide adoption - again, some people want to start with something that resembles the Vanilla/Linux 1.10 source release.

I was expecting this to come up again.

Let me restate: What I want is not turn this into classes but make the procedural code compile as C++.

And to make C code compile as C++, the only thing that's really needed is a lot of type casts, and of course fixing sloppy code that goes wild with C's lax syntax.

But going C++ brings three immediate advantages:

 

1. Better error checking. If there is one point about C I truly dislike is its laxness when it comes to accepting questionable code. C++ mercilessly errors out on most of this.

2. The ability to use third party C++ code. And this can become a major roadblock if the code remains C. Someone suggested using JSON as format for MAPINFO. Here's the catch: The only good JSON library I am familiar with is RapidJSON which is C++ and cannot be used from C. So I'd have to find another, far more clumsy alternative or roll out my own wrapper.

3. You do not have to use C++ stuff, but if done right it can massively reduce code size. Just as a simple example, the UMAPINFO parser contains a large part of code for allocating and freeing strings and arrays. If this had been C++ I could have used std::vector and std::string which not only would have reduced code size massively, it'd also make the code a lot more secure because the underlying library takes care of the needed allocations instead of having to write it all out explicitly and double-check it is all correct and each malloc/strdup matched with a free.

 

 

1 hour ago, kb1 said:

so requiring that we, for example, must choose -cl 20 to use the new standard seems misguided. Again, complevels are there to tell the engine to emulate an OLD port. There will be fixes, but they will be in the form of new linedefs, which none of the old ports understand, so there is no conflict.

I haven't looked too deeply into the complevel stuff yet, especially what decides which complevel is chosen by default - but in my opinion the default should be to have all features active, and only manually selecting another complevel if needed for recording a demo or testing.

 

[printz]

There are no standard source ports. Just aim for the most comfortable one.

[wesleyjohnson]

This is why I worked on my enhancements without mentioning it on DoomWorld.

This kind of forces me to reveal some of my plans.

 

For the last few years I have been writing up descriptions for an enhanced Doom "Doom2107".  As 2017 got here before I was ready, I guess the name will have to change.  There is an simpler version called "Doom2015" with only the easy to implement stuff.

 

My rules for the Doom2017 enhancements are:

1. Implementation is up to the individual port.  The description will state what the effect will be, completely enough that demo compatibility could be done if desired.  Visual effects and non-savable effects can be as good or bad as the port maintainer wants.

2. Some linedefs can be implemented crudely at first, with later refinement in visual quality.  The visual quality does not

impede savegames nor demo compatibility.

3. Involves only additions to linedefs and objects.  No change in format.  Must work with existing editors and node tools like zennode.  Implementation must not require cooperation from other tool maintainers.  Do not want to make any tools unusable nor require any specific tool as this will end up being limited to certain tools and most certainly one of them will end up being windows-only.

4. It is possible to use existing fields of the existing format in innovative ways.

DoomLegacy use some interpreted text in a texture name to control fog, but that may be too much for other ports.

I use a modified Yadex to edit level maps with this feature, so it may be difficult for editors too.

On the other hand, using the level map facing direction to modify object behavior is easy and every editor can do it.

5. Not stepping on existing linedef numbers is critical.

6. Any enhancement that cannot be implemented by a reasonable number of ports can be pushed off into a separate

enhancement, such as "Doom2020".  I would likely still implement it in DoomLegacy, but it there would no longer be any requirement in the implementation of "Doom 2017"

 

Now, if this project goes along the same lines, I see some possibility for this succeeding.

If it gets more requirements, like hexen format or UDMF, no matter how attractive, it will force too many changes to existing

ports to be an enhancement.   DoomLegacy code options are already complicated and I think most other port maintainers will want to keep this to some new linedefs and new object types, so they have minimal code disruption.

 

Examples of what I was planning, from "Doom2015" (from memory).

Several new monster types with new behaviors.  This is a short brief, my actual descriptions go on for several pages.

1.  Small rat monster.

2.  Robot monster with interactive behaviors.   Player tolerant until provoked.

3.  Robot that picks up dropped items and takes them to a marked disposal area.  Can take objects from teleport area.

4.  Security robot type.   Has objects that it visits to define a patrol area.

5.  Sensor objects that send alarm to security robot type.

6   Alarm light object for when security system is triggered.

7.  Master Computer object that interacts with the robot monsters.  When attacked, it can call upon all security robots to defend it.   This gets progressive depending upon what robot monsters are still available.

Has progressive damage.

 

Some new object types:

1. Electric arc.  The facing direction of the object controls the arc type, timing, and damage amount.

2. Control objects to turn off electric arcs, making them passable.

3. Smoker.  Creates smoke for smoking ruin.   Visual effect only.

 

Some ideas that may be objects, or linedefs, or both (maybe).

1.  Monster health-boost,  like a monster vending-machine.

2.  Supply system.  Push a button, get a health pack, or whatever else is in the queue.

3.  Monster attractant, and repellant.   Affects groups of monsters, like all flesh type, or all robot type.

 

This is getting boggy for one post.

 

 

[wesleyjohnson]

Some linedefs and sector effects.

1. Sliding doors.   Must be compatible with existing node builders.  May be too advanced for this enhancement level.

2. Moving walls.    Wall can move out an push the player off a ledge.  Must be compatible with existing node builder.   May be too advanced for this enhancement level.

3.  Object delivery.  When a button is pushed, the designated sector moves objects within it to the edge to be picked up.

Emulates getting stuff off a shelf or out of a drawer, or out of a machine.

[wesleyjohnson]

Enhanced object display.

1. Naming system for 16 angles of facing.  Is compatible with existing 8 angles of facing.

2. Naming system for selective higher resolution object sprites. Allows having high resolution sprites for

only the sprites that face the player.  The port detects which sprite images are supplied at load time and adapts.

3. Naming system for simple objects, with 2, 4, or other selective repeated patterns.  This is actually very simple to implement.

[Graf Zahl]

That's a lot of stuff. Some remarks:

 

27 minutes ago, wesleyjohnson said:

Several new monster types with new behaviors.  This is a short brief, my actual descriptions go on for several pages.

I do not think that adding specific new things is such a good idea. A better approach would be to provide a small set of new code pointers and then implement some DECORATE lite feature - if the implementation is done carefully enough it could be used by all ports interested here. The UMAPINFO parser also tries to steer clear of dependencies that not all ports have and should be 100% portable, except for a handful of external dependencies that need to be provided.

 

24 minutes ago, wesleyjohnson said:

1. Sliding doors.   Must be compatible with existing node builders.  May be too advanced for this enhancement level.

If you mean like polyobjects, the least you need is a node builder that is aware of how they get defined and then can handle them properly. I do not see this be as a viable feature in Doom format maps. Even Eternity only implemented them through Extradata.

If you think about Strife's animated doors, that's a feature that should be easily portable because it has no render dependencies.

18 minutes ago, wesleyjohnson said:

1. Naming system for 16 angles of facing.  Is compatible with existing 8 angles of facing.

The naming system already exists in some ports, this can be taken as-is, provided that the calculations are done properly to pick the correct angle.

20 minutes ago, wesleyjohnson said:

2. Naming system for selective higher resolution object sprites. Allows having high resolution sprites for

only the sprites that face the player.  The port detects which sprite images are supplied at load time and adapts.

That also already exists with the HI_START/HI_END namespace. PrBoom+ already supports this as does ZDoom, not sure about Eternity. Thus it is one of the likliest candidates for some Boom+ standard.

22 minutes ago, wesleyjohnson said:

3. Naming system for simple objects, with 2, 4, or other selective repeated patterns.  This is actually very simple to implement.

I have no idea what you mean with that. Can you give more detail?

 

[kb1]

5 hours ago, Da Werecat said:

I should probably clarify how I see this working.

 

I don't think that any command line parameters should be needed to activate the new features. They must all be available by default. But they should be disabled in existing complevels for emulation accuracy.

 

Since there are conscious exceptions even now (like sky transfers), some of the new features may still be allowed to work in cl9, cl2, et cetera, provided they don't wreck demo compatibility with emulated engines.

 

As for the potential "-complevel 20" or the like - this shouldn't be needed unless the changes are gonna be rolled out in several phases. New phase = old default behavior is compleveled for compatibility. Technically, this is gonna be emulation of an old engine.

 

Even if there's gonna be only one official phase, the current default behavior of PrBoom+ should be preserved, probably.

Theoretically, older maps should not be using linedefs that have never been defined, which is why it makes sense to have new features use new identifiers. I suppose a map or two may have some bad linedef nums, by accident, but those have to be extremely rare, as there's useful no reason for them to exist.

Of course, PrBoom+ behavior will be preserved.

4 hours ago, Graf Zahl said:

I was expecting this to come up again. (going C++)

You make a good case for going C++ for better parsing, more code flexibility, and for add-on modules. But for core doom source, for me, C++ is way down the road. I wanted to ask about the UMAPINFO: Earlier I talked about putting some per-map identifiers into the format:

MapType, Port, and maybe PortVersion, and/or StandardVersion. Have you given these any thought, or considered their usefulness? (The description is in the 4th post of this thread). This was in reference to the idea of converting port-specific linedefs to common numbers. I also asked how ZDoom accomplishes this. It may be possible to encourage port devs to start using unique numbers for their new linedefs that don't conflict. But even if that doesn't happen, a protocol for conversion could provide another way to solve the problem. Can you share your thoughts?

 

4 hours ago, printz said:

There are no standard source ports. Just aim for the most comfortable one.

Technically true. But there can be a standard for data.

43 minutes ago, wesleyjohnson said:

(described lots of add-on stuff)

Good, interesting stuff! I have to agree with Graf, though, on adding as much of that as possible using existing, or generic code-pointers and linedefs, etc, even if you intend on the new objects being standard equipment. KBDoom has its core WAD file that it needs to run, but it also comes with a non-user-editable Effects wad file, that defines things like extra blood effects, smoke, fire, etc. This file defines all the new things, which use custom code pointers, sounds, pickup and weapon sprites, that all get dynamically added to the engine. However, this file is completely removable, or can be turned off with a command-line switch, leaving the game running in a completely stock manner. This is a good way to add the kinds of thing content you describe, when combined with some useful, but generic code pointers. It's a lot of work to set up, but very nice to have.

[Graf Zahl]

15 minutes ago, kb1 said:

Theoretically, older maps should not be using linedefs that have never been defined, which is why it makes sense to have new features use new identifiers. I suppose a map or two may have some bad linedef nums, by accident, but those have to be extremely rare, as there's useful no reason for them to exist.

I guess whatever you do, some person will always do the odd thing and create something broken.

Like this mod for Doom1 containing a chaingunner in one level...

No need to guide every far out eventuality with a safety check. Sometimes you have to accept that what's broken may not work as intended.

 

18 minutes ago, kb1 said:

This was in reference to the idea of converting port-specific linedefs to common numbers. I also asked how ZDoom accomplishes this. It may be possible to encourage port devs to start using unique numbers for their new linedefs that don't conflict. But even if that doesn't happen, a protocol for conversion could provide another way to solve the problem. Can you share your thoughts?

I'm not really sure that this may accomplish anything. Right now there's two distinct numbering schemes that exist: Legacy/ZDoom/EDGE (which steered clear of each other's numbers unless implementing them themselves) and Eternity. And if you look closer there's very little in the extended numbers that may be backportable to a basic standard. Even more importantly, the only maps using these linedefs are so port specific that there's no point trying to make them work. If a Boom+ standard materialized it should simply exclude all of this and use a number range that's free of conflicts.

Concerning ZDoom, it defines complete translation tables to map Doom format linedefs to Hexen format, but none of that is helpful here because it does not remap some clashing numbers but does a full translation into a different format.