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

[Graf Zahl]

18 hours ago, Jon said:

Maybe a trigger linedef that woke up any monsters in tagged sectors, useful for monster closets and the like.

 

With that type of feature you'll have to be careful depending on what you want, because alert information in Doom is permanent and once a sector is marked as alerted, everything that gets spawned or teleported there will react to it later as well. No idea if that's what you want.

 

[Jon]

23 minutes ago, Graf Zahl said:

 

With that type of feature you'll have to be careful depending on what you want, because alert information in Doom is permanent and once a sector is marked as alerted, everything that gets spawned or teleported there will react to it later as well. No idea if that's what you want.

 

 

I imagined just calling wake on all things in the sector at trigger-time, not making it a permanent sector property. Similar to Strife's alarms.

[Jon]

4 hours ago, bzzrak said:

Hey, how about a linedef that plays a sound when activated? 

 

...I can dream, right?

 

No need to be snarky, this seems like a perfectly fine feature request. Can we refine it a little?

• does any other doom engine already have this fully implemented (heretic, hexen, strife?)
• or a console port?
• play any sound at all?
• at what locality: "global" or point-source?
  • if global, who hears it: triggering player, or all players?
• should this wake monsters up?

[Graf Zahl]

1 hour ago, Jon said:

 

No need to be snarky, this seems like a perfectly fine feature request. Can we refine it a little?

• does any other doom engine already have this fully implemented (heretic, hexen, strife?)

Hexen uses ACS do do it, none of the other games has something similar.

 

[VGA]

It can take as a parameter the same as the PlaySound Dehacked code pointer: a Dehacked sound number and a full-volume toggle. (We are talking about parameterised linedef actions, I hope)

[Graf Zahl]

Dehacked sound number will be very limiting, though. Not many ports can extend that table for custom sounds. Some other value that maps to an actual sound name may be better - that's something even PrBoom can do.

 

[Jon]

I thought lump name in the Midtex, for walkover lines at least. Not sure where to stuff a volume argument.

[VGA]

2 hours ago, Graf Zahl said:

Dehacked sound number will be very limiting, though. Not many ports can extend that table for custom sounds. Some other value that maps to an actual sound name may be better - that's something even PrBoom can do.

 

Well, I am hoping ports will add the blank states, the SPxx spritesets and the 100 extra things that Doom Retro and Crispy Doom have ALREADY added, the effort is minimum and does not mess with compatibility. And then blank sounds up to Dehacked number 255 (or 256?), how hard can it be to extend the sound table?

 

So any linedef can reference an existing or a new sound using an integer, just like the code pointers do. And the name convention can be DSEXT** or something. Well, I am not arguing with the people who are doing the coding, of course. :D

[printz]

Based on the first pages of the thread, where it was even suggested to refactor PrBoom+ into C++, I'm going to repeat what I was saying previous times: Eternity should absorb all of PrBoom+'s optimizations and highlights (all the demo facilities and GLBoom), PrBoom+ itself should cease development, and Eternity be renamed as PrBoom+ or ++ or 2, so people will find it and download it. Then we'll potentially have a richer common base of features with big old ZDoom.

[SaladBadger]

Ok, I know you have good intentions in mind with this for the community overall, but I'm just not quite sure how I feel about telling someone to stop developing their port and move to and start working on a different port instead. I dunno how much PrBoom+ and Eternity have diverged from their common parents (I assume quite a bit), but with whatever level of divergence it is, how hard would it be in practice to actually port over those things?

[kb1]

16 hours ago, bzzrak said:

Hey, how about a linedef that plays a sound when activated? 

 

...I can dream, right?

I think MBF has a thing action that does this - the sound goes into one of the extra params (misc1). A linedef could do the same, I suppose, with the TAG number being the sound number. It's not the best concept: playing a sound via number, since the numbers could potentially change. Now, a linedef could have a sidedef with the name of the sound lump in it - that could work and be reliable.

[VGA]

I already mentioned PlaySound

 

https://www.doomworld.com/eternity/engine/codeptrs.html#objsound

 

It says (New in MBF), I have been using it in my mods, works fine

[printz]

Sorry but a line special whose purpose is to alert monsters is boring, when you can use the vanilla way of persuading the player to shoot the lone imp, trooper, barrel or simply switch to the same effect. Seems as boring as the idea of using Thing_Spawn instead of letting monsters come in naturally.

Edited July 21, 2017 by printz

[kb1]

@VGAOops, sorry VGA - I had a reading malfunction...

 

On 7/20/2017 at 3:17 PM, printz said:

Based on the first pages of the thread, where it was even suggested to refactor PrBoom+ into C++, I'm going to repeat what I was saying previous times: Eternity should absorb all of PrBoom+'s optimizations and highlights (all the demo facilities and GLBoom), PrBoom+ itself should cease development, and Eternity be renamed as PrBoom+ or ++ or 2, so people will find it and download it. Then we'll potentially have a richer common base of features with big old ZDoom.

I'm pretty sure I voiced my opinion against an all-out conversion to C++.

 

I'm not sure if you are being serious or not. I'll assume you are. Some thoughts:

• My goal is not to end up with one universal port monopoly. The whole reason Doom editing is so rich is that many developers have put their hearts and souls into their own types of Doom modifications. Some of those features were repeated nearly identically across ports: That's the stuff I want to make universal. That's the stuff that should be available in all ports, and should work identically in all ports, and be added to a map in an identical way in all ports.
• With a one-size-fits-all port, there is always something that port does not do (cause the devs feel strongly against it philosophically, or because it doesn't fit into the dev's master plan, or whatever).
• With a one-size-fits-all port, this goofy feature that I and only I love, will never make it into the port.
• Vanilla Doom is a great way to learn C programming. It's fun to start with Doom, and find the pitfalls and shortcuts the id guys used. This kind of stuff is obscured in a big Do-Everything port.
• Maybe Entryway wants to continue developing PrBoom+. You could always rename to "Doom Eternity", if you think the name prevents people from downloading Eternity.
• I have big plans for KBDoom that don't necessarily coincide with Eternity's or ZDoom's or Legacy's plans. Yet, I want KBDoom to be able to load as many advanced maps as it can, as long as the map doesn't have incompatible features.
• Nothing prevents Eternity, or any other port, from adding PrBoom+ style complevel-type support. The only big drawback with PrBoom+'s complevel stuff is the sheer dedication to dead port demos. To successfully bring that stuff in means that every new feature you add must be able to coexist with 2 dozen different game types, and not affect any one of them. Can it be done? Yes. Is it difficult? It can be.

I guess my point is that we have many ports that do many different things. At first thought, it would be nice to cherry-pick the best features of each port, to make a super port. But, those ports were built for different reasons, with different philosophies. We have enough room for all kinds of ports.

 

With this spec, I am trying to increase the level of compatibility across ports, by first starting out small, then tackling bigger things. We may end up with A LOT of similarity between ports, which would be a great thing for players, mappers, and developers. This approach keeps the choice with each developer, and allows them to work on their own port, at their own pace. I am not trying to force a huge-impact change on anyone. For example, some ports will never adopt Heretic support. Such a developer wanting to update their port using this combined port's code would have to manually strip out Heretic stuff, which is a subtractive process.

 

I think a better approach is an additive process: Using a spec designed specifically to ease the additive process, a developer can implement pieces of the spec as he/she sees fit, at a snail's pace if need be. Maybe, one day, an optional phase of the spec can describe how to add complevel stuff to a port that complies with earlier phases. Maybe also Heretic and Hexen complevel stuff could also be supported.

 

In other words, I am hoping that this preliminary spec is the genesis of the opening of communication channels for the various developers, coordinating the adding of new features in ways that do not conflict with the plans of other ports. This goes way beyond linedef and sector types:

• Imagine ports negotiating feature support to enable compatible network games using different ports
• Save game and enhanced demo file compatibility
• Compatible Thingdefs, sound defs
• Custom UDMF properties being elevated to "standard" status by way of developer agreement.

 

It may seem silly, but a big question is: What is your port's mission? It's actually a valid question. What is your port trying to accomplish that makes it unique?

 

And, let me just say this, to all developers: Doom hacking should be fun. Doom exists for fun and entertainment. If what you're doing isn't fun anymore, what's the point?

 

 

Edited July 21, 2017 by kb1

[printz]

From your replies you two sound bothered by the idea. I just feel the ports are too similar in purpose, if only because of the effort to preserve demo comp. while also allowing fancy mods (I call MBF fancy already), yet not as advanced as GZDoom.

[Graf Zahl]

8 hours ago, InsanityBringer said:

Ok, I know you have good intentions in mind with this for the community overall, but I'm just not quite sure how I feel about telling someone to stop developing their port and move to and start working on a different port instead. I dunno how much PrBoom+ and Eternity have diverged from their common parents (I assume quite a bit), but with whatever level of divergence it is, how hard would it be in practice to actually port over those things?

 

It'd surely cause a lot of bloat and redundancy. But let's not forget that merging PrBoom and Eternity isn't done just by adding all the compatibility stuff to Eternity. PrBoom+ also has its OpenGL renderer and that is lacking some stuff Eternity needs, like portals - and having written a portal-aware GL renderer myself I can outright tell that it's far from simple to get this to work correctly.

[Gez]

7 hours ago, kb1 said:

The whole reason Doom editing is go rich is that many developers have put their hearts and souls into their own types of Doom modifications.

That I agree with. It's cool that there's a big variety of ports that develop in different directions. I'm glad they exist even if I don't personally use most of them.

[kb1]

17 hours ago, printz said:

From your replies you two sound bothered by the idea. I just feel the ports are too similar in purpose, if only because of the effort to preserve demo comp. while also allowing fancy mods (I call MBF fancy already), yet not as advanced as GZDoom.

I thought I detected a bit of frustration on your part, in your July 21 @ 3:17pm post - what's that about?

 

Hmmm. I don't think 'bothered' is the right word. Maybe 'concerned'... with the idea of replacing PrBoom+ There's nothing wrong with using features from different ports. And, there's nothing wrong with merging two ports. In fact, I am in the process of dropping KBDoom into a PrBoom+ variant, to take advantage of new control, sound, music, and video support (I'm still using MIDAS sound system from ZDoom 1.11, God help me). This is a big reason why I haven't released my source.

 

But PrBoom+ is basically a finished product, whereas Eternity has goals that dictate that it must continue to grow. Nothing wrong with either approach. But, as it stands today, I can download PrBoom+ and have a stable, high-performance platform for playing standard, Boom, and MBF .wads. If I want to add something to the source, I know where I'm starting at. I can rest assured that I am working with features that are time-tested, and I can predict that this is the way PrBoom+ will always be.

 

Eternity has VERY different goals...which is cool, but not the same thing. If the two were combined, and PrBoom+ development halted, I could not download a maintained version of the community-wide standard.

 

And, here's the kicker:

PrBoom+ represents the state-of-the-art compatibility model for Doom. PrBoom+ supports everything considered to be compatible across all enhanced ports, and only those things. That's what the new Boom+ specifications are all about! With the spec, we can add a bunch of new functionality, across the board, to all enhanced ports, and call it the new standard. PrBoom+ is the absolute best port to showcase this new standard in, since PrBoom+ supports the agreed-upon standard, and only the agreed-upon standard.

 

That's why I want PrBoom+ to stay separate. It's the model for every other enhanced port out there.

 

I hope you understand what I'm getting at - this is not a stab towards Eternity - Eternity is awesome! I am simply arguing that I don't believe a PrEternity+ should replace PrBoom+ and cause PrBoom+ development to halt.

[kb1]

16 hours ago, Graf Zahl said:

 

It'd surely cause a lot of bloat and redundancy. But let's not forget that merging PrBoom and Eternity isn't done just by adding all the compatibility stuff to Eternity. PrBoom+ also has its OpenGL renderer and that is lacking some stuff Eternity needs, like portals - and having written a portal-aware GL renderer myself I can outright tell that it's far from simple to get this to work correctly.

I'd love to see a play-by-play description - a sort of "How-To" document that describes how your GL renderer works. I am sure that would be huge project itself! But it sure would be interesting.

[printz]

11 hours ago, kb1 said:

I thought I detected a bit of frustration on your part, in your July 21 @ 3:17pm post - what's that about?

Not frustrated actually, just smug that whatever I said several times in the past has actually some sense.

[Death Egg]

On 7/20/2017 at 0:17 PM, printz said:

Based on the first pages of the thread, where it was even suggested to refactor PrBoom+ into C++, I'm going to repeat what I was saying previous times: Eternity should absorb all of PrBoom+'s optimizations and highlights (all the demo facilities and GLBoom), PrBoom+ itself should cease development, and Eternity be renamed as PrBoom+ or ++ or 2, so people will find it and download it. Then we'll potentially have a richer common base of features with big old ZDoom.

I agree with absorbing the few missing features from prBoom+ (let's see someone volunteer and actually add them though) but I don't agree with just renaming it to something like prBoom++. If the aim is to get more players I'd recommend something that sounds less like a "programmer name" so to say.  (GZDoom, 3DGE and prBoom+ don't ready roll off the tongue or have the same zing to them as Eternity, Doom Retro or Doom Legacy imho)

[Graf Zahl]

41 minutes ago, Death Egg said:

(GZDoom, 3DGE and prBoom+ don't ready roll off the tongue or have the same zing to them as Eternity, Doom Retro or Doom Legacy imho)

Funny if you consider which of those ports are the most popular ones... :D

 

[Gez]

What's wrong with Jezy Doom, Threedge, or Professor Boom Plus?

[Death Egg]

4 hours ago, Graf Zahl said:

Funny if you consider which of those ports are the most popular ones... :D

 

I wouldn't say 3DGE is more popular than Doom Retro these days, but otherwise you got me there. ;p

[Jon]

3dge, as in the one with the sf project name "edge2", which is (and isn't) "edge"? I can think of one really big reason it's not more popular...

[VGA]

9 minutes ago, Jon said:

3dge, as in the one with the sf project name "edge2", which is (and isn't) "edge"? I can think of one really big reason it's not more popular...

Its vanilla and boom compatibility isn't very good? It is also a little buggy and clunky sometimes.

[Jon]

OK on the subject of a trigger to wake stuff up, I threw together a test WAD, there's a wall trigger which should be interpreted as SR, number 479 (clashes with EDGE's "ladder" type, because I adapted the WadC from a test map I wrote to try that feature out. (I didn't get it to work.)). Reminder: all numbers in prototypes are NOT fixed and are subject to change. Test wad is https://jmtd.net/tmp/trigwake.wad

 

No use without test code though right? Well I started something last week but haven't got it working yet. Prboom+ (at least on Mac) is a bitch to debug, at least using bad techniques... I can't get random fprintfs scattered around to actually display, no matter what I try :>

 

Edit: ok I think I figured this out on the train home but ran out out of time to push. Will try later

Edited July 24, 2017 by Jon

[Coraline]

On 7/23/2017 at 2:23 PM, Jon said:

3dge, as in the one with the sf project name "edge2", which is (and isn't) "edge"? I can think of one really big reason it's not more popular...

Yeah, it's just "edge". No pronunciation difference. ^_^

 

And, I am always open to hearing constructive criticism regarding the port -- however, maybe this thread isn't the best place for it. And don't get me wrong, there's a ton of reasons it's not as popular as it once was, or maybe as popular as it can be. I also know there's major issues with it at the moment, but we are trying to work through it. We just take things one day at a time. ^_^

 

@Jon: Also, if the ladder type clashes I'll go ahead and push it farther back as to not conflict with more current trigger types. Not the first time EDGE's custom linetypes had to have been pushed back, so it's no big deal ^_^

[Gez]

Nah, don't move it; it'd be pointless:

7 hours ago, Jon said:

Reminder: all numbers in prototypes are NOT fixed and are subject to change.

 

[Jon]

Here's a prototype alert for an S1 trigger to wake monsters in a sector: https://github.com/jmtd/prboom-plus/commit/67b16bbf94dc3f75eb5302705befe38fedcbe761

 

A reminder: my test WADs are all generated with WadC and their source is in the WADCSRC lump in the WAD file.

 

10 hours ago, Coraline said:

@Jon: Also, if the ladder type clashes I'll go ahead and push it farther back as to not conflict with more current trigger types. Not the first time EDGE's custom linetypes had to have been pushed back, so it's no big deal ^_^

 

10 hours ago, Gez said:

Nah, don't move it; it'd be pointless:

 

Seconded. please don't move it; it's kind of clashing on purpose so nobody relies on this number for this behaviour, the number is guaranteed to change. [ But: if you could explain to me how the ladder types are supposed to work, that'd be great! I tried applying it to a linedef which was on a sector boundary with a floor height difference of 64; I couldn't find a way of "scaling" the wall in game, which is how I thought it would work. ]