dsda-doom v0.27.1 [split - zoom removal / endoom again]

[Arsinikk]

2 hours ago, dsda-dev said:

speedrunners

Not even going to go into how some of my best friends are speedrunners...

 

2 hours ago, dsda-dev said:

source port development

It's not like I don't work with source port developers all the time to fix issues... Or that I am a web developer who is used to working with code. Or even that I've coded my own infopack applications. That's some conjecture there.

 

2 hours ago, dsda-dev said:

decided to take up strong opinions about how everything works and why decisions are made. You also decided to ignore the flaws in your argument that I brought up and instead doubled down on them. Your assumptions about why I make decisions are wrong and your assumptions about speedrunners are wrong.

Tbf I don't really have strong opinions about this. I have strung together a logic map based on what other users have posted about and what your responses have been like. It is the conclusion I have come to of why things have ended up where there are, and tbh you haven't exactly disproved any of the points I have brought up. If there's certain features that you have removed, in which I have come to the wrong conclusions, then why not enlighten me.

 

2 hours ago, dsda-dev said:

Your assumptions about casual players are wrong too.

My discussions on my Discord server tell me otherwise. Many players I talk to who have used DSDA Doom are hesitant to use it, simply due to feature removal.

 

2 hours ago, dsda-dev said:

Why do some people feel the need to be so loud with their ignorance? Is it the lure of the spotlight?

Honestly it's because of how you respond and don't clarify why things were done. For example, your most recent statement here: "If someone doesn't like to tinker and also doesn't want to use the launcher, then endoom doesn't exist for them." comes off as harsh with no attempt to empathise with any such user in that group. Talk about ignoring a certain userbase that uses your port.

 

2 hours ago, dsda-dev said:

By the way you can't just say all respect and then repeatedly attack my character and intelligence. I do consider being told I ignore most of the players, as well as saying I'm too dumb to realize other people think differently than me to be personal attacks. There is no other way to take that.

If you wanna take it that way, sure I guess. I never said you were dumb. I do think by not acknowledging that many causal Windows users do not wanna mess with BAT files nor command line, shows that your perspective on what's normal for many causal users is a bit skewed. I wouldn't say this is surprising, as you tend to dive into complicated code being a program developer. However I think that this can blind some people of the experience of other users that don't like working with code.

 

Regarding your character, you are are honestly not the nicest source developer that I talked to, which makes it difficult to have an actual discussion with. Your harsh comments toward some users about the port do not help your case.

 

2 hours ago, GarrettChan said:

This shows that you only care about specific feature *that you have a chance to use somehow* removal instead of keeping the integrity of whole basic game thing... You think there's no blowback, but in reality it has. We probably just don't go to the DSDA-Doom thread and argue that whatever it should be kept. I'm also a bit disappointed that DSDA-Doom doesn't support multiplayer, but oh well, it's what it is. These ports you mentioned, they changed the game a lot, so I don't enjoy playing any multiplayer on any of these ports.

This is a fair point... I think my point was mostly that in the sphere of doom sourceports, multiplayer is often not considered a priority unless multiplayer is the main purpose of the port. That's my guess into why it hasn't come up again.

 

2 hours ago, Andromeda said:

15 hours ago, Arsinikk said:

It is the only source port with rewind

PrBoomX

 

15 hours ago, Arsinikk said:

I think alot of these threads could be avoided if a specific fork was made that focuses more on QoL aspects and non-runners to make casual players more happy, that pulls in the updates made from the main DSDA Doom branch.

From DOOM With LOVE was created with that in mind, but it was quickly abandoned - that tells me that the demand for such a fork is diminute at best.

 

13 hours ago, Arsinikk said:

I'd rather not go into depth about the classic opengl renderer, however I will say that many early 2010 PWADs have been designed around that renderer's light modes.

^{[citation needed]}

 

13 hours ago, Arsinikk said:

UDMF in a classic doom port

The Eternity Engine

I'll go through these a bit in a sort of rapid fire format, since I sorta think this sorta misses the point a little. The goal of me posting in this thread isn't to make me happy, it's to stop the future posts complaining about the *removal of this feature* and such.

 

PrBoomX - has rewind. I am aware of the port, but it still misses features such as the indexed renderer and lite-UDMF support. Plus it's closer to PrBoom Plus than DSDA Doom, which I kinda see as a con. DSDA Doom runs much better performance-wise.

 

From DOOM with LOVE - I actually didn't realise this was based on DSDA Doom (for some reason I thought it was based on Woof). This is a fair point as it was abandoned. Tbf that makes it all more important to try and get certain features in DSDA Doom, if forked ports are just going to get abandoned.

 

Classic OpenGL Renderer [citation] - This came from a close friend in my Discord server that I'd rather not name drop for his sake. His examples were that Sunlust and Epic 2 were designed with the old OpenGL PrBoom Renderer in mind, and now that that's gone some maps may not look as they were intended to look. However it is not a stretch logically to assume that certain mapsets made around the early 2010s were based on the old OpenGL Renderer light modes.

 

The Eternity Engine - I won't go into detail about how I personally feel about the engine and it's slow development. I will say I'm grateful for what Eternity has paved the way for features added into other ports. The Eternity Engine does have some UDMF support, but of course that's kind of besides the point because it's missing features such as rewind and the new indexed renderer.

 

I don't think it's a stretch that users of DSDA Doom would want a source port to be the best port it could be and that's why when certain features are removed, people ask for them.

 

1 hour ago, baja blast rd. said:

Fwiw I don't want to dogpile but I can't help but point out that this is made-up -- when it comes to what speedrunners focus on, and even how the program works. (DSDA-Doom has long had an in-game reset feature, which makes load times next to 0 amortized.) There are other fictitious ideas about speedrunners, but that one seemed to capture the way people are making stuff up the best.

Perhaps this is the only explanation my brain could come to for why certain features would be cut, as reasons for features getting cut don't ever seem to be explained besides the dev saying that he found them to be unimportant.

 

11 hours ago, Graf Zahl said:

While that is true, remember what subforum we are in here?

As long as DSDA is hosted in the 'demos' section that misconception will continue to hold on. Why not sticky the main development thread in the 'source ports' section? That'd send a clearer message.

As Graf Zahl said above, DSDA Doom being placed in the speedrunning thread does overshadow the speedrunning idea all over the port, and if you wanted to disconnect that misconception than it'd probably be better to move it into the source ports subforum. Else everyone (including me) will always look at the port only being directed towards speedrunners.

 

1 hour ago, baja blast rd. said:

There's also this invention of a unified "speedrunner group" that apparently cares about one thing, when speedrunners can differ pretty wildly. Even the idea of sides is a pretty big misconception here. Speedrunners are pretty often dedicated casual players too. Even the most active casual players sometimes -- Vile probably streams more wads in half a year than most people play in several.

Tbh many speedrunners have voiced their opinions on some of these features (especially about ENDOOM) here and their outlook has typically been that they don't care much for extra features. Every "misconception" has elements of truth and whenever I see speedrunners commenting on these threads, it's mostly to say that the feature isn't important to them. So my logic isn't quite that far of a jump. Perhaps it is only the loud and outspoken that feel this way.

 

The idea of grouping "speedrunners" together was to highlight that depending on how certain people use a program can shape what features they deem important. In a port that is in the "speedrunning" subforum, I think it's a valid concern that users that just play doom for fun also have their opinions heard. When I see people complain about ENDOOM or the old OpenGL Renderer, the response from the dev is often "we aren't adding that back" without any other explanation. This leads to those users thinking that the dev doesn't care about their concerns. I'm not sure if it's because the dev doesn't want to deal with those comments, or they just don't feel the need to elaborate, but it comes off as callous and uncaring.

[Andromeda]

16 minutes ago, Arsinikk said:

Classic OpenGL Renderer [citation] - This came from a close friend in my Discord server that I'd rather not name drop for his sake. His examples were that Sunlust and Epic 2 were designed with the old OpenGL PrBoom Renderer in mind, and now that that's gone some maps may not look as they were intended to look. However it is not a stretch logically to assume that certain mapsets made around the early 2010s were based on the old OpenGL Renderer light modes.

Both of those wads were also developed with the software renderer in mind, so by extension they should look as intended in the indexed light mode as well.

[TheLoneliness]

At the end of the day, all this boils down to; if you don't like what the current DSDA version changed you have following options:

1. Realize that DSDA is a free software made completely in the developers free time to be a tool for the community and they are in no way, shape or form obligated to make changes that a loud minority wants, trying to force that only makes you seem like you feel you're entitled to it.

 

2. Simply use an older version that has the feature that you miss or use a different port entirely. Even if this is the best/most used port, that doesn't mean it should try to cater to every single niche group of people.

 

3. Develop your own port that has all the features you want and need, or if you lack the required knowledge, pay someone to do it.

[maxmanium]

My main and only complaint about all this is that, IMO, if you're going to be labelled as the successor to PrBoom-Plus, don't be surprised when its userbase doesn't like removing things they're used to.

[Edward850]

11 hours ago, Arsinikk said:

new indexed renderer

What is "index rendering" and why is Eternity supposed to have it?

[JadingTsunami]

26 minutes ago, Edward850 said:

What is "index rendering" and why is Eternity supposed to have it?

 

This is referring to dsda-doom's redone OpenGL renderer which is palette-based.

 

11 hours ago, Arsinikk said:

DSDA Doom runs much better performance-wise.

 

Hmm, I have never heard the claim that dsda-doom is better performance-wise than PrBoom-Plus. What is this claim based on?

[Arsinikk]

37 minutes ago, JadingTsunami said:

Hmm, I have never heard the claim that dsda-doom is better performance-wise than PrBoom-Plus. What is this claim based on?

Actually I'd like to retract that statement. I think I let my previous technical issues with PrBoom Plus cloud my judgment here a bit and equated that towards performance, but that's definitely the incorrect term to use there.

 

Even so, I wouldn't even be able to probably tell a difference between the two, since I have a high-end PC.

 

I remember having some stuttering issues (possibly relating to high framerates) with PrBoom Plus before, but those have been fixed since. Previous problems such as jerky mouse movement and lack of high DPI scaling support have also since been fixed (in the latest 2.6.66 version that is). I cannot comment on your PrBoomX, as I have yet to try it out.

 

I will say that DSDA Doom seems to run audio differently than PrBoom Plus, and I personally prefer how DSDA Doom does it. (Sorry I don't know how to explain it better than that, but I think the audio sounds a bit different between ports).

[rfomin]

13 hours ago, Arsinikk said:

I do think by not acknowledging that many causal Windows users do not wanna mess with BAT files nor command line, shows that your perspective on what's normal for many causal users is a bit skewed.

I'm already regretting suggesting this BAT solution. Just wondering what kind of hypothetical casual user it is that can figure out Doom ports without installers, IWAD and PWAD files, various launchers, etc, but can't use a simple BAT file.

[Arsinikk]

17 minutes ago, rfomin said:

I'm already regretting suggesting this BAT solution. Just wondering what kind of hypothetical casual user it is that can figure out Doom ports without installers, IWAD and PWAD files, various launchers, etc, but can't use a simple BAT file.

I think I was more talking about having to make the BAT file yourself.

You did mention including a BAT file, which is easy enough for a casual user.

 

Although I do find the BAT solution to be more of a "band aid" solution in general.

Especially if its only use is "pause on close with ENDOOM" the BAT file.

It'd make much more sense to me if it was just a option in the main config file.

[Arsinikk]

Thinking on this a little more, I think the problem is less about the ENDOOM implementation, and more about it using different consoles for different platforms.

 

The uphill battle that you face is that the default Windows console does not have a pause implemented, and so any casual Windows user that turns on ENDOOM will just have it print out in the console and immediately close. Your expectation for these users is either to use a BAT file to add a "pause" or to change the default console on their machine to enact a pause, I guess?

 

I'm a little confused why a pause couldn't just be added program wise, so we'd be able to avoid having to have BAT files at all. Like if "ansi_endoom 1" on the Windows platform, add pause. Then again, it may not work since the way your BAT adds the "pause" is via an instruction before the program has even launched.

[rfomin]

4 minutes ago, Arsinikk said:

I'm a little confused why a pause couldn't just be added program wise, so we'd be able to avoid having to have BAT files at all. Like if "ansi_endoom 1" on the Windows platform, add pause. Then again, it may not work since the way your BAT adds the "pause" is via an instruction before the program has even launched.

You also need to find out if the program is attached to the console or not. All these hacks add up and defeat the purpose of deleting the ENDOOM code in the first place.

 

My point is that all DSDA-Doom users are very hardcore. They want Doom to be exactly like vanilla mechanically, but with advanced features. Also, Kraflab didn't suggest using BAT files.

[ebrl]

This thread reads like a hit job.

[Professor Hastig]

36 minutes ago, rfomin said:

My point is that all DSDA-Doom users are very hardcore.

 

That's some very broad generalization, putting 'all' into that sentence.

 

My personal opinion about the whole matter is that depending on terminal output for modern GUI/game applications is not correct. It is a totally alien concept for the average Windows user - who may just be as 'hardcore' about the game mechanics, but doesn't care much about using outdated design principles.

It is fine as an option but if you ask me, all output the game does should be in its main window and nowhere else - that includes the ENDOOM screen if the user desires to see it. Of the ports I occasionally used only Eternity and GZDoom seem to strictly follow this principle.

 

[rfomin]

24 minutes ago, Professor Hastig said:

It is fine as an option but if you ask me, all output the game does should be in its main window and nowhere else - that includes the ENDOOM screen if the user desires to see it. Of the ports I occasionally used only Eternity and GZDoom seem to strictly follow this principle.

DSDA-Doom is the only port I know of with console output enabled on Windows. All the others, including Chocolate Doom and PrBoom+, were not build with console enabled at all. Woof has a woof.com executable with console output, but this is optional.

[Professor Hastig]

I am aware of how Woof did this, but the price you pay is that all info being printed is sent into the void - or a text file the uninitiated user does not know of. So in the end it's still the same - the console-less variant is mostly useless because you cannot see what it has to say.

It is just not how modern software should do UX design, even if it is a port of a 30 year old game.

 

[rfomin]

All information that Woof prints is optional. If an error occurs, a message box is displayed. Chocolate/Crispy and other conservative ports work in a similar way.

 

I've always liked console tools, even in Windows. Now I think the point of view has changed and Microsoft has improved the console considerably. I'm not saying everyone should use it, but the DSDA-Doom approach seems like an interesting alternative to me.

[Classic SSG Enjoyer]

6 hours ago, JadingTsunami said:

What is this claim based on?

Fantasy 

[Finnisher]

ENDOOM is nice to have but a DOS like screen that you look at for a few seconds the first time you see it and then never again likely, a big deal? Hardly.

 

Screen zoom or viewport size was in the original to help people with low spec systems run the game. It therefore is definitely not a needed feature anymore.

To be honest I'm surprised source ports have it in the first place anno 2023, apart from being able to toggle full HUD on and off.

 

There is "staying authentic to original" and then there is "pointlessly copying everything from the original when a better alternative exists or the reason for thing X being there is no longer present".

[Professor Hastig]

39 minutes ago, Finnisher said:

Screen zoom or viewport size was in the original to help people with low spec systems run the game. It therefore is definitely not a needed feature anymore.

To be honest I'm surprised source ports have it in the first place anno 2023, apart from being able to toggle full HUD on and off.

 

It is indeed rather pointless these days, but judging from this thread you can rest assured that if it was removed, someone out there would complain.

What genuinely bothers me is the removal of the true color renderer a few versions ago. That was a major change by comparison.

 

[dasho]

I'm not shilling EC, but we have OpenGL available at all times (not sure if DSDA does under the hood when using software rendering so not going assume this is viable for them) and just draw the ENDOOM screen using a spritesheet VGA font when the quit dialog appears, in the same window that the program uses. This doesn't have to involve the console at all and (in my opinion) is an improvement for not adding an extra input to clear the subsequent window and truly exit. Don't know if something like that is feasible or even desired but just throwing it out there.

 

[LexiMax]

If we're talking interface improvements, I think that Rum & Raisin deserves consideration.  If most DOOM ports look like an evolution of DOS Doom, and GZDoom/Eternity look like they're cribbing Quake 2, Rum & Raisin actually looks modern.

 

[rfomin]

Rum & Raising is great, but this kind of UI can only appeal to programmers :) I think the Unity port has a decent modern UI. Of course, with DSDA-Doom we'll have to add a lot more options to the menus, but still.

[Graf Zahl]

2 hours ago, dasho said:

I'm not shilling EC, but we have OpenGL available at all times (not sure if DSDA does under the hood when using software rendering so not going assume this is viable for them) and just draw the ENDOOM screen using a spritesheet VGA font when the quit dialog appears, in the same window that the program uses. This doesn't have to involve the console at all and (in my opinion) is an improvement for not adding an extra input to clear the subsequent window and truly exit. Don't know if something like that is feasible or even desired but just throwing it out there.

 

 

 

That's exactly the same approach GZDoom uses. The result is a CPU-side bitmap that gets uploaded as a texture, but it could just as easily be rendered to a software canvas. In fact it was before I made the code cross-platform last year.

 

1 minute ago, rfomin said:

Rum & Raising is great, but this kind of UI can only appeal to programmers :) I think the Unity port has a decent modern UI. Of course, with DSDA-Doom we'll have to add a lot more options to the menus, but still.

 

Let me guess: Dear IMGui. I wouldn't even call that modern. It's just another blast from the past - these elements were all invented in the 80's or 90's and haven't really aged that well - especially with that color scheme.

My personal take is that the core UI is better left alone, but what can be done is making nicer, more modern looking option menus. Unfortunately when I overhauled GZDoom's menus I only went half way with it, and now it's too late to redo it again, it'd break all mods that extend the menus with custom items.

 

[ceski]

11 hours ago, Arsinikk said:

I will say that DSDA Doom seems to run audio differently than PrBoom Plus, and I personally prefer how DSDA Doom does it. (Sorry I don't know how to explain it better than that, but I think the audio sounds a bit different between ports).

This is another subsystem that's pretty much the same in most source ports. There's no difference unless you manually changed a setting in your .cfg. At a glance, there are sections that were cleaned up and support was added for the Raven games. That appears to be it, unless I missed something.

[Graf Zahl]

PrBoom's sound code was quite a bit more messy than the other ports so the statement was correct, assuming the cleanup happened after forking Prboom+

 

 

[ceski]

35 minutes ago, Graf Zahl said:

PrBoom's sound code was quite a bit more messy than the other ports so the statement was correct, assuming the cleanup happened after forking Prboom+

 

Yep, this is comparing the fork you made as it is now (archived) against the dsda-doom master.

[JadingTsunami]

2 hours ago, ceski said:

This is another subsystem that's pretty much the same in most source ports. There's no difference unless you manually changed a setting in your .cfg. At a glance, there are sections that were cleaned up and support was added for the Raven games. That appears to be it, unless I missed something.

 

I had a look and agree the sound code is the same. So this seems to be another perceptual vs. actual difference, unless as you rightly point out there is a config setting mismatch somewhere or a different soundfont in use, etc.

[Arsinikk]

3 hours ago, JadingTsunami said:

I had a look and agree the sound code is the same. So this seems to be another perceptual vs. actual difference, unless as you rightly point out there is a config setting mismatch somewhere or a different soundfont in use, etc.

I did actually decide to record both PrBoom Plus and DSDA Doom using a demo and then syncing up the audio and testing whether they sound different, and I think they are very close. I could of sworn that the SFX sounded a bit sharper in DSDA Doom, but after testing I don't think many people would be able to tell the difference. Unless the sound that I was remembering was for an older version of PrBoom Plus, but the new one is pretty close to DSDA Doom.

 

The testing was done with via fresh installs from both PrBoom Plus v2.6.66 and DSDA Doom v0.27.2 (I did however tweak a couple settings including resolution, statusbar and menu appearance - doom format (only in PrBoom), and made both ports use microsoft_gs_wavetable.sf2 for the soundfont via fluidsynth). You can see a comparison here, but tbh I can't really tell the difference. There may be a slight difference if you synced up the audio of both videos and cut between the two, but it's negligible imo.

 

I did notice a couple things that I did not notice before while working with fresh installs.

1. DSDA Doom actually doesn't have high DPI scaling, requiring me to override it in compatibility settings. I guess I didn't realise this because even if I replaced the exe with a new version, Windows remembers the compatibility settings set on the exe. Interestingly enough, PrBoom Plus does have high DPI scaling support.
   
   This makes a difference if in Windows you have display scale setting other than 100%. Because I have a 1440p 24'' monitor, I have it set to 125% (set by default from the system btw). This results in DSDA Doom when in full screen (or having the window the same resolution as the screen) being zoomed in and cutting off the edges of the screen. Basically rendering the game 25% more than it should be.
    
2. PrBoom Plus v2.6.66 defaults to using OPL3 for midi playback because apparently it doesn't come with any soundfont and therefore doesn't use fluidsynth on default. (let me clarify that the setting is set for fluidsynth, but it uses OPL3 if it can't find a soundfont).

[ceski]

3 minutes ago, Arsinikk said:

PrBoom Plus v2.6.66 defaults to using OPL3 for midi playback because apparently it doesn't come with any soundfont and therefore doesn't use fluidsynth on default. (let me clarify that the setting is set for fluidsynth, but it uses OPL3 if it can't find a soundfont).

 

Right, by default DSDA-Doom uses this soundfont as a lump named SNDFONT inside dsda-doom.wad. You can extract the lump and rename it to anything.sf2.

[JadingTsunami]

24 minutes ago, Arsinikk said:

I did actually decide to record both PrBoom Plus and DSDA Doom using a demo and then syncing up the audio and testing whether they sound different, and I think they are very close. I could of sworn that the SFX sounded a bit sharper in DSDA Doom, but after testing I don't think many people would be able to tell the difference.

 

The code is the same, so there's no difference at all. They're the same, assuming the settings are equal.