New source port desired features

[MarketAnarchy]

I'd like to create a poll that gets people's opinions on what would be REQUIRED and DESIRED features for a new source port.

 

I'm certain that I would overlook features that people would want if I were to try to create such a survey on my own, so I'm asking everyone to put forth their best suggestions. I'll compile the submissions into one survey and hopefully we can get some solid feedback from the doom community so we really understand what it is that WE want.

 

A very small number of examples I can imagine are:

PRBoom Demo compatibility

3d floors

Scaling graphics

Limit removing

Rotatable flats

scripting

GZDoom scripting backwards compatibility
DEHACKED backwards compatibility

Vanilla support

Basically anything you think is important, I'd want to know.

So, please make two lists like this:

REQUIRED features:

DESIRED features:

Hopefully I can make a survey that will help guide developers.

Robert

[Edward850]

3 hours ago, MarketAnarchy said:

PRBoom Demo compatibility

Vanilla support

Why are you repeating yourself?

[Fletcher`]

3 hours ago, MarketAnarchy said:

3d floors

Scaling graphics

Limit removing

Rotatable flats

scripting

GZDoom scripting backwards compatibility
DEHACKED backwards compatibility

Vanilla support

So, you want gzdoom?

[Gez]

What does "vanilla support" actually mean? Because the ability to load and play the original games is a feature of just about every source port. (Except SRB2, if you count that as a source port.)

[scifista42]

DESIRED: All features of all other ports, backwards compatibility with all other ports, a single universal scripting language for everything in the game.

REQUIRED: A whole new game engine, I guess.

[MrGlide]

I was going to make a big ol joke reply, But I really need to go back to bed. As for any serious comments for this I think Making a "Required" field when pertaining to a subject where a Programer has to work for free is not only absurde, But Disrespectful. Nothing is "Required" as these people don't own you anything. I think the only logical "requirement" for something to be considered a Doom source port is if it runs Doom in any kind of form.

[StalkerZHS]

Scalability of bits per pixel or whatever (choc doom in windowed 960x600 is a lock blockier than a modern source port at windowed 960x600).

 

The ability to switch between software and openGL without closing out the game (GLboom can already do this tho)

[Voros]

DOOM64.WAD support

 

Full BEX parser for Chocolate Doom. 

[Urthar]

Amongst other features, Dark Forces had moving and rotating sectors, which would be pretty cool.

[Avoozl]

I wouldn't mind Doom 64's gradient lighting capability in GZDoom.

[MarketAnarchy]

9 hours ago, Edward850 said:

Why are you repeating yourself?

Why do you waste your time and mine with snarky comments like this? 

Playing boom demos is NOT the same thing as being able to disable settings and play in a vanilla format.

[MarketAnarchy]

9 hours ago, rf` said:

So, you want gzdoom?

It doesn't matter what I want. I'm asking what YOU and the others in the community want.

 

MAYBE you could just answer the question instead of assuming ill intent?

[MarketAnarchy]

7 hours ago, MrGlide said:

I was going to make a big ol joke reply, But I really need to go back to bed. As for any serious comments for this I think Making a "Required" field when pertaining to a subject where a Programer has to work for free is not only absurde, But Disrespectful. Nothing is "Required" as these people don't own you anything. I think the only logical "requirement" for something to be considered a Doom source port is if it runs Doom in any kind of form.

 

When I program, I ask my clients for a list of requirements and a list of desires. It's a standard thing in the industry where I work. There's nothing wrong with knowing what features are imperative to have, even if someone volunteers to do the work. I ask the same question of non-profits that I donate my programming skills to.
 

Perhaps you aren't familiar with the vernacular of the industry.

[MrGlide]

Fair enough. what about an automatic record demo button?

[Edward850]

2 hours ago, MarketAnarchy said:

Why do you waste your time and mine with snarky comments like this? 

Playing boom demos is NOT the same thing as being able to disable settings and play in a vanilla format.

So far, any port that has full support for both vanilla and Boom has the ability to play back Boom demos. The concepts go hand and hand nowadays.

 

... Granted there's only two ports that do (prboom+ & Eternity).

[Master O]

How about ipv6 support (for Multiplayer)?

[MrGlide]

I think we all could agree that a source port that could bring some of the mapping functionallities that UDMF brings to the table while keeping vanilla gameplay and demo compatibility Would be absolutely stellar. I'd also like to see an in program wad loader Like most emulators have now days, I think that would be spankin. 

[Edward850]

9 minutes ago, MrGlide said:

I think we all could agree that a source port that could bring some of the mapping functionallities that UDMF brings to the table while keeping vanilla gameplay and demo compatibility Would be absolutely stellar. I'd also like to see an in program wad loader Like most emulators have now days, I think that would be spankin. 

So Eternity then? It has UDMF and advanced features, demo compatibility (for everything except memory quirks) and in-engine wad loading from its menus.

[MrGlide]

I feel embarrassed to say this but I didn't know that, thank you Edward. I'm going to check it out right now.

[fraggle]

On 5/14/2017 at 3:11 PM, MarketAnarchy said:

 

When I program, I ask my clients for a list of requirements and a list of desires. It's a standard thing in the industry where I work. There's nothing wrong with knowing what features are imperative to have, even if someone volunteers to do the work. I ask the same question of non-profits that I donate my programming skills to.

I understand where you're coming from but MrGlide actually has an important point that you're not considering. The cases you describe are fundamentally different in nature; specifically: when you say "required", who is it that requires them? If you're a company developing a product for a customer, or if you're donating your time to a non-profit, the answer is simple: you have a clear customer with particular needs that you're trying to satisfy.

 

That isn't the case here: you're just posting a thread asking "what is required?". Required by whom? The one thing that's abundantly clear after years of working on developing Doom source ports is that that's a question that varies wildly from one person to the next. For one user, the ability to play with Brutal Doom is a requirement; for the next, the ability to play vanilla demos is a requirement. Unless you're going to pick a particular user and decide (for example) "I'm going to develop Edward850's perfect source port" the notion of requirements is kind of meaningless.

 

As a side note - and again, this is from my own experience from years of developing Doom source ports - you'll probably find that this notion of developing a source port with features people want is going to be a dead end. I've heard these called "feature ports" and they tend to not be very fun to work on, because there's already a dominant feature port (ZDoom, now GZDoom) that everyone uses, you'll end up spending years trying to compete against it to no success, and there will always be an endless list of additional features people want from your source port.

 

If that's the kind of source port you want to work on then I suggest you just spend your time contributing to GZDoom. If your code is good then I'm sure Graf Zahl will be thankful for the help. That's the real feature that people want - they want to continue using the source port that already does what they want, which is *ZDoom and has been for years. The requirement for most users is "it is *ZDoom".

 

The other option is to take the niche route which is what I've done with Chocolate Doom. Do something fundamentally different in philosophy to existing source ports and set a clear goal for what you're trying to achieve. Don't do what you think "users want", do what you want and find interesting to make (it's absolutely untrue that "what you want doesn't matter" if you're the one putting in the work). If you can't say "no" to feature requests then you don't have a clear goal. Making something different to what we already have is more interesting anyway, and you'll probably find it's a lot more personally rewarding than voluntarily making yourself a slave to the whims of a nebulous user base.

[printz]

2 hours ago, fraggle said:

As a side note - and again, this is from my own experience from years of developing Doom source ports - you'll probably find that this notion of developing a source port with features people want is going to be a dead end. I've heard these called "feature ports" and they tend to not be very fun to work on, because there's already a dominant feature port (ZDoom, now GZDoom) that everyone uses, you'll end up spending years trying to compete against it to no success, and there will always be an endless list of additional features people want from your source port.

Is that a jab at Eternity? Anyway, I've proven for myself that I'm capable of programming something fairly complex start to finish (which is much better than when I try to make Doom levels) with the Eternity Heimdal release, and hobby programming is draining my social life away, so I'm leaving the port back in the warm hands of its parent, Quasar. I may still have bursts of inspiration and maybe even suffer something that makes me want to return to Doom programming for another awfully long time, but I hope that happens late, as I feel like my priorities are elsewhere, and that's definitely not contributing to stronger ports such as GZDoom (the mere forum colour theme and the feel of some of its community bother me, and I dislike its UI). I'd be happy though if Graf Zahl wises up and adds edge portals — and people actually release maps with linked portals, Eternity or GZDoom — because edge portals are not fully replaceable by 3D floors and really give you the feeling that you can expand your map in any direction you can think of.

 

I know in my case the niche port route is AutoDoom (player-versus-environment Doom bot), which is also worthier as a geeky hobby (it wouldn't affect my social life that badly either, because I always find AI enthusiasts I can show it off to), but also much more difficult.

 

Still, just to answer the thread, what I really want to see is moving sectors, not necessarily aided by portals (but most likely having polyobjects and dynamic BSP). It has been my long term idea to do it in Eternity. In retrospect, not something of very much worth in the long run, unless I use it to build my own WADs. Mod quality is a crapshoot and it's not worth my time developing the medium for them.

Edited May 15, 2017 by printz : Added last paragraph.

[Zaiman12345]

REQUIRED: 3D model support, real freelook. (like GZDooM)

DESIRED: Pixel smoothing NOT being required, I like my pixel-y sprites and textures just the way they are, and multiple render modes for slower computers.

AND, something really cool for Classic fans, True Classic mode! Classic rendering, pixel-y view, only vanilla mods, etc. Just a thought, since DOSBOX can be a pain, and other, more classic ports aren't fully classic.

[Gez]

So... Chocolate Doom with 3D models and full freelook?????

[fraggle]

1 hour ago, printz said:

Is that a jab at Eternity?

Not at all, this is my own experience from working on SMMU years ago. But I don't think I'm alone in this experience.

 

1 hour ago, printz said:

I know in my case the niche port route is AutoDoom (player-versus-environment Doom bot), which is also worthier as a geeky hobby (it wouldn't affect my social life that badly either, because I always find AI enthusiasts I can show it off to), but also much more difficult.

Yeah, AutoDoom is another really good example of something that's off the well-beaten track of feature ports. I love that project, by the way - along with AutoWolf. You've done some really great work and it's very satisfying to watch the bots do their stuff. Fresh, new and interesting, which is what we should all want to see coming out of the Doom source hacking scene.

[printz]

9 minutes ago, Gez said:

So... Chocolate Doom with 3D models and full freelook?????

Isn't that Doomsday?

[Gez]

Doomsday has actually quite a lot of advanced features besides rendering stuff (look up DED and InFine) and I'm not sure they bother much with demo compatibility.

[Catoptromancy]

I would really like a streamlined or highly playable Chocorenderlimits. Meaning that all controls, features, and F keys work as normal and can be played exactly like chocolate-doom. The ` (console key) toggles renderlimits mode, rebinding all the F keys and enables all the screen spam. 

 

There would also be two modes of playing with "renderlimits mode" off. In Mode  1, If a vanilla limit is reached or very close(user defined range), the Disk Icon pops-up and stays for a few seconds, maybe plays DS_RADIO. Gameplay is otherwise uninterrupted. Mode 2, if a vanilla limit is reached, gameplay stops with a message "visplane/other limit has been reached, press Y to continue" this stops player movement in specific area, allowing for screenshots, save games, turning on "renderlimit mode" and such. Pressing Y again will allow player to continue for 5 seconds without another message, so player has time to leave affected area. 

 

And a third mode that is completely silent. This would make the truest limit removing port. No bug fixes, or even the slightest extra feature. Just higher limits. 

 

Edited May 16, 2017 by Catoptromancy

[Xaser]

Protip: If you broadly ask "What's required?" to an audience of basically everyone, the answer tends to resemble "basically everything."

[Agentbromsnor]

I'm going to sound like a broken record, since I've been harping on this feature a lot in the past... :p

I would love to see vertex shading for models in a Doom port. I prefer working with GZDoom, since I'm most familiar with it, so perhaps someone could make this happen. I'm sure Graf Zahl would appreciate the help.

I do agree that it would probably be pointless to create another 'feature port' (ports like EDGE look bloody amazing but are collecting dust...).

[Blastfrog]

2 hours ago, Agentbromsnor said:

I would love to see vertex shading for models in a Doom port. I prefer working with GZDoom

Funny you should mention that, I brought this up to Graf in a PM not too long ago. Here's what he had to say:

 

On 5/9/2017 at 3:33 AM, Graf Zahl said:

It's being discussed. There's a few technical problems to be solved first.