Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
deathz0r

dsda-doom endoom support [split]

Recommended Posts

4 hours ago, kraflab said:

You consider the main menu and interface to not be part of the game? You're genuinely left wondering and don't understand how that might be different than a screen that pops up after the user has exited the port?

 

I mean, i was wondering what the kind of thing is that makes you go nope. The title screen appears before the main menu and could thus susceptible to the same reasoning if you ask me.

 

Personally, it is your port, so nobody can sway you against anything you want to remove or implement. I am just saying that ENDOOM (Lesser so ENDBOOM!) does see usage in a matter significant enough to keep up.

Quote

This descent into inanity is why I usually don't engage with these topics and don't track issues on the repo. It's good to have a reminder again.

That is geniunely a pity because in no way am i attacking you, your port or anything else and it pains me that this is the kind of answer i have to go with it for being interested in your decision and the arguments you laid out.

 

Atleast i learned about inanity, so no harm done lol

 

11 minutes ago, Gez said:

Technically it's not. Doom just sends a bunch of stuff to STDOUT, something that modern ports can still do and that would be perfectly invisible to anyone who starts them from a graphical environment. Showing the ENDOOM screen on Windows and other GUI interfaces requires a new feature.

Like TITLEPIC, ENDOOM is a feature that can be modified in the same way you can modify COLORMAPS and TRANMAPS. If people go the extra mile to implement a custom ENDOOM, why should that work be neglected?

 

If the (ongoing) reason is clean up of the codebase, would a mere toggle or reference in the menu to edit it in through .cfg be such a costly refactor?

 

So my actual (inane? ;)) question would be: What is the cost of re-implementing this in a minimal fashion, codewise?

Share this post


Link to post
6 minutes ago, Ravendesk said:

Well, from his post I infer that he suggested something very close.

The "nobody should ever criticize our holy port, ever, especially lowly peasants such as non-speedrunners" attitude is exactly what Kinsie was referring to earlier, and you can see how prophetic it was given the response given later. Posting an opinion or expressing a preference or making a point of criticism is something everyone on this forum is entitled to do, because all of our opinions matter. Then Kraflab is free to completely disregard it and continue to do his own thing. It's how forum threads work. Funny, that. As for how hard it might be to maintain, I don't know, but it's certainly something that exist in other ports that allow for speedrunning, and it's something that people put work in. It's absolutely not unreasonable for them to express disappointment that the feature has been removed, and considering Kraflab said he might be tempted to remove the full screen HUD (of all things) or mouselook support, if not for the fact that he knows too many players rely on those, suggests to me that he is more interested in removing things that he does not personally use, rather than things that are too much of a nightmare to maintain. But that's just my lowly peasant non-speedrunner impression, hey.

Share this post


Link to post
1 minute ago, Dynamo said:

It's absolutely not unreasonable for them to express disappointment that the feature has been removed

I agree that it's not unreasonable. What is unreasonable however is a lot of spite and sarcasm instead of a constructive search for some solution.

 

Development of a big project is very often about finding good compromises, but they won't be found if it is just one developer and a lot of people doing exercise in irony. 

 

So I suggest instead of flaming in this topic, to look into the code, find some roots of the mess caused by this feature, design an alternative approach to it's implementation and discuss it instead.

Share this post


Link to post
3 minutes ago, Redneckerz said:

Like TITLEPIC, ENDOOM is a feature that can be modified in the same way you can modify COLORMAPS and TRANMAPS. If people go the extra mile to implement a custom ENDOOM, why should that work be neglected?

Because it's something that is thrown at the system to display when the program closes.

 

Vanilla Doom never displayed ENDOOM. It just told DOS to display it. On Windows, when a program is closed, it leaves behind no remanence of its execution on the screen. Its window is closed. So if you want to show ENDOOM, you have to make quitting the game not actually quit the game and instead display a special window that is there just to make quitting the game take longer.

 

So it's cool that it's fancy and all, but it's definitely not a critical part of the software.

 

As for your example, should I point out that modified COLORMAPS and TRANMAPS have no guarantee at all to work as expected in all ports?

Share this post


Link to post
7 minutes ago, Gez said:

Because it's something that is thrown at the system to display when the program closes.

 

Vanilla Doom never displayed ENDOOM. It just told DOS to display it.

And with that, the classic experience is that ENDOOM is shown.

 

I dunno, i just want to stress i am not against the removal per-chance, but in my mind (And it seems the minds of many) ENDOOM is such an inherent part of the Doom experience in general (despite, as you say, Doom itself doesn't display it, but it just tells DOS to do so, meaning under Windows it needs to resort to something like libtextscreen to get the same behavior) that it feels off not having it.*

 

Spoiler

* So consider this more of a feeling's opinion than a technical opinion. The Icon of Sin knows that when it comes to technical specifics, you are always on the money, Gez...

 

I realize that you can't develop a port based on what people feel and i reckon Kraflab would agree with that. Henceforth i was looking into different sectors.

 

If its gone with no substitute that A: is clean on Code and B: is easy to implement, then so be it.

 

But in that case, perhaps we need to clarify which ports support ENDOOM then :)

7 minutes ago, Gez said:

As for your example, should I point out that modified COLORMAPS and TRANMAPS have no guarantee at all to work as expected in all ports?

Well gosh darn it, maybe they should! Maybe we should have a standard that guarantees working things common to the Boom standard.

 

Small jest aside, i am not a hitherto knight of keeping ENDOOM if it makes little sense - I am just saying, it is used often enough to be relevant, and it is cool art.

Share this post


Link to post
1 minute ago, Redneckerz said:

And with that, the classic experience is that ENDOOM is shown.

 

I dunno, i just want to stress i am not against the removal per-chance, but in my mind (And it seems the minds of many) ENDOOM is such an inherent part of the Doom experience in general (despite, as you say, Doom itself doesn't display it, but it just tells DOS to do so, meaning under Windows it needs to resort to something like libtextscreen to get the same behavior) that it feels off not having it.*


Filthy speedrunner here, but for what it's worth, I hadn't seen the ENDOOM screen in almost twenty years. It's something I had to be reminded exists, google a picture of, remember that I had in fact seen it when I played DOS doom as a kid, then realize its not something I miss when playing the game today.

 

I'd argue that its omission in this port isn't really hurting anyone, and it certainly is not "an inherent part" of the "classic experience".

Share this post


Link to post
14 minutes ago, kraflab said:

I find it frankly disgusting to suggest that I only listen to speedrunners. I've implemented various features specifically for mappers and casual players that have no relevance for speedrunning, as well as dedicated substantial time debugging issues with dehacked or other lumps for mappers. Those requests have often come in through the forums. Since I don't have a lack of things to do, I don't really need more streams of communication.

 

Kinsie is being dismissed for their absurdly disingenuous post, not because they aren't a speedrunner.

I don't think I ever suggested that you only listen to speedrunners. I think Ravendesk was the first to suggest that...?

 

I only suggested that there was no need for wide public distribution beyond a specific group if said group is your only focus. I've done some tiny little things for specific people in the past, and it was cool and fun and I had no need to care what the rest of the world thought. Good for the soul!

Share this post


Link to post
18 minutes ago, Kinsie said:

I only suggested that there was no need for wide public distribution beyond a specific group if said group is your only focus.

Which part of the forums are we in again?

Share this post


Link to post
59 minutes ago, Gez said:

So if you want to show ENDOOM, you have to make quitting the game not actually quit the game and instead display a special window that is there just to make quitting the game take longer.

To elaborate a little bit on this: this is only an issue in case it's not optional. But I think this is a rather strange point to make in a game that deliberately wastes one to two seconds of your time to play a sound clip whenever you select yes on the quit game prompt, which takes longer to sit through than the ENDOOM screen does. Both ENDOOM and the sound clip can be disabled in the GZDoom options, for example, so it goes to show how both can be implemented without making quitting the game a hurdle, should anyone care to do so.

Share this post


Link to post

As a Vanilla mapper, I did find it a bit disappointing that this was being stripped out of DSDA Doom. I also find that giving the player the most options is the best bet, and I think it's weird to strip something out for seemingly no reason. Plenty of mod authors (especially Vanilla and also early released wads), take time an effort to create the ENDOOM screen for their wad. Even the recently Eviternity wad has a badass ENDOOM screen, and that's an MBF wad.

 

I think that most people don't know it's an option in first place (or simply forgot), because for the longest time in PrBoom Plus (with DSDA Doom being a branch), it's been disabled on default. The beauty of it though, was that it was actually an option the user could turn off and on. So while most people didn't want/know about it, the people who did care about were able to toggle that option. By stripping the option away, you are deliberately telling those people who did use it that you don't care about the ENDOOM screen and that you don't care about giving users a choice to see the ENDOOM or not.

 

Perhaps if you really wanna strip out the ENDOOM code, you could move it to a separate optional EXE that is called when DSDA Doom closes, if the option is toggled. That way it could be done more like how you stripped out the native coloured blood option in favour of instead reading a user made coloured blood deh file.

Share this post


Link to post

As a Speedrunner and kinda mapper I can't say I care about the ENDOOM, only gameplay and the geometry in a level, the support of ENDOOM doesn't amount to anything speedrunning related so the removal of it means nothing to me and keeping it just to appease some people doesn't seem like a good idea, plus the removal of code that isn't relevant to the subject is always nice

Share this post


Link to post
1 hour ago, Meowgi said:


Filthy speedrunner here, but for what it's worth, I hadn't seen the ENDOOM screen in almost twenty years. It's something I had to be reminded exists, google a picture of, remember that I had in fact seen it when I played DOS doom as a kid, then realize its not something I miss when playing the game today.

 

I'd argue that its omission in this port isn't really hurting anyone, and it certainly is not "an inherent part" of the "classic experience".

I'd argue that your statement perfectly reflects how groups of Doomers have different experiences altogether in how they see and use Doom.

 

Ultimately this boils down to how important this is for speedrunners. Considering DSDA is first and formost made for Speedrunning, i'd say that adds additional weight against Kraf's decision.

 

The big thing (for it much is a thing here) is that DSDA has the disadvantage (relative to speedrunners that is) that it is also often used by non-speedrun Doomers. Its that group that may have a differing view here.

 

Fuck it, lets fork DSDA even more and make it a general port :P

1 hour ago, Doomkid said:

This community will argue over literally anything, god damn

I disagree :P

 

Kidding. I think its good this gets discussed, but i get where you are from Doomkid.

Share this post


Link to post
21 minutes ago, Master Medi said:

As a Speedrunner and kinda mapper I can't say I care about the ENDOOM, only gameplay and the geometry in a level, the support of ENDOOM doesn't amount to anything speedrunning related so the removal of it means nothing to me and keeping it just to appease some people doesn't seem like a good idea, plus the removal of code that isn't relevant to the subject is always nice

 

While I understand your position here, it seems to highlight a certain division between the two groups of users DSDA has acquired over its existence.

There's the speedrunners on one side, but also a growing group of regular players who value the port's features.

So the important question now is, how should this develop? If DSDA decides to focus on the speedrunners it will inevitably cause some underserving of the other group.

Should that really happen it's maybe time to not actually fork the port but instead backport what's possible to current PrBoom so both groups get what they want and we have a baseline engine for the feature support minus speedrunning tools.

 

But would that really be the best outcome here? It'd again split available resources pointlessly - the community would be better served by a single line of development where all effort can get in.

 

 

On topic of ENDOOM:

 

For me these text screens are a historic part of Doom and its early modding. I)'ve been there in 1994/1995 playing all these levels with sometimes cool, sometimes weird text screens on exit. They are a part of how I experienced Doom in the past. That's why I jumped right into it and added support to ZDoom back in the day once it got text screen support for Heretic's startup screen. And considering that this caused a genuine renaissance of using ENDOOM screens in modding - even in high profile ZDoom mods - shows that I am not alone in this. The use of ENDOOM had virtually disappeared in 2007 - but later saw a strong resurgence.

Edited by Graf Zahl

Share this post


Link to post
6 minutes ago, Graf Zahl said:

So the important question now is, how should this develop?

 

The way the only person currently developing the port wants to develop it. If enough people want to see ENDOOM support for DSDA-Doom, the project is totally open source, and it really isn't splitting resources if its been stated there will not be support otherwise. I feel like we're going in circles here.

Share this post


Link to post

Let's be honest here. DSDA Doom may have been started specifically for speedrunners, but because of all the new features and advancements of the port (like rewind, and like how I can map IDDT to like a single key), casual doom players have also started to use the port. So now DSDA Doom has two different groups each using the port, like Graf said.

 

So, either the devs have to decide to have the port forked, and continue DSDA Doom port to be only for speedrunners... Or they should take into account their casual doom users, and add optional features to appease them as well.

Share this post


Link to post

It's not a zero-sum game and the groups aren't separate.

Most speedrunners also play the game casually, and many are also mappers (including me).

Furthermore, the "speedrunning features" are often things that benefit everyone (e.g., rewind, extended hud).

 

Endoom doesn't have any relationship to speedrunning. Removing it is not a "pro speedrunning" decision and I don't know how the conversation got there. The outcome of this has nothing to do with anything being brought up right now.

 

Evidently, my focus on speedrunning features and quality of life has created a port that also appeals to casual players. The design philosophy hasn't changed, so I find it unlikely that the outcome will change.

Share this post


Link to post
1 minute ago, Arsinikk said:

So, either the devs have to decide to have the port forked, and continue DSDA Doom port to be only for speedrunners... Or they should take into account their casual doom users, and add optional features to appease them as well.

 

Dev* - singular, and anyone can fork the port and do what you're suggesting. It isn't a decision that requires a community vote. It does require someone to step up and actually do it though.

 

It's really easy to sit here and theorize and discuss how we each individually believe the future of this port should look, but ultimately its up to -again- the sole dev who is supporting it currently. If "non-speedrunners" want a fork with ENDOOM support, then someone needs to step up and fork it.

Share this post


Link to post

I've been reading through this a while and regarding a potential fork of DSDA-Doom, I wonder if it would be a possibility to use an existing fork instead of a brand new one. I know From Doom With Love is based on DSDA-Doom, so maybe updating and porting potential features to FDWL could be the solution if agreed upon. I don't have experience to be able to know if this is a good solution, but I figured I'd throw it out there in case it happens to be ideal.

Share this post


Link to post
9 minutes ago, Meowgi said:

It's really easy to sit here and theorize and discuss how we each individually believe the future of this port should look, but ultimately its up to -again- the sole dev who is supporting it currently. If "non-speedrunners" want a fork with ENDOOM support, then someone needs to step up and fork it.

I really don't know what you expect me to do. I'm not a programmer. There's nothing wrong with theorising since it might actually inspire another dev to pick up the idea and do what I can't. While I'm appreciative of what kraflab has done with the port, it's clear that he has no interest in changing his stance on ENDOOM.

 

12 minutes ago, kraflab said:

 Endoom doesn't have any relationship to speedrunning. Removing it is not a "pro speedrunning" decision and I don't know how the conversation got there. The outcome of this has nothing to do with anything being brought up right now.

 

I feel this is sorta missing the point. The point is that ENDOOM has no relationship to speedrunning and that you have plenty of users of your port that do not speedrun. Therefore some of these non-speedrunning casual players would like a way to view the ENDOOM in your port. You have said "no", and obviously this has disappointed some of the users that actually used the feature in your port. You can't really get mad at players who are using a feature-leading port, when you remove a certain feature, since it's not like they can go to another port for rewind and other DSDA Doom-only features.

Share this post


Link to post
15 minutes ago, Arsinikk said:

I feel this is sorta missing the point.

You're misunderstanding the situation entirely. My removal of this feature has nothing to do with what anyone else thinks and is purely the result of the rationale I posted near the start of this thread. It isn't happening because any person or any group of people want or don't want the feature to be removed. The objections by any person or group are not being valued more or less than any other group. There are also speedrunners who like this feature - obviously, because as I said it has nothing specific to do with speedrunning and thus affects all players equally. Some people just love to have an us vs them narrative to play out their fantasies in an internet forum.

Share this post


Link to post

Guys, it's really simple.

If a dev for an open source project feels the need to remove/add a feature, you're welcome to ask why but I don't really think you need to fight over it

Share this post


Link to post

@kraflab If someone was able to create a simple ENDOOM.exe viewer, would you be willing to add some code DSDA Doom to check for the exe and maybe open it after closing DSDA Doom, only if the exe was in the directory?

 

I think that all DSDA Doom would have to do is check for the exe, run it right before closing and send the arguments that were ran to launch DSDA Doom (like -file MM2.WAD), so that the ENDOOM.exe would know what was to pull the ENDOOM from.

 

To be honest, I've never been a fan of how source ports show the ENDOOM; in a window that's to scale instead of doing a fullscreen thing so you can actually see it.

 

If someone made an exe like that, would you be willing to make it so DSDA Doom would check for it, send the launch arguments to it, and run it before DSDA Doom closes?

 

That way everyone could be happy. (Of course, someone would have to create the viewer first).

Share this post


Link to post
3 minutes ago, Arsinikk said:

@kraflab If someone was able to create a simple ENDOOM.exe viewer, would you be willing to add some code DSDA Doom to check for the exe and maybe open it after closing DSDA Doom, only if the exe was in the directory?

 

On that note, GZDoom's code is quite simple, it's really just the font and a handful of functions for creating a bitmap out of the text screen that then can be rendered by the backend. The only caveat is that it uses a full Unicode font right now, but this should be easily replaceable with the binary font of older versions.

 

There's no dependencies on large and clunky libraries like libtextscreen.

 

3 minutes ago, Arsinikk said:

To be honest, I've never been a fan of how source ports show the ENDOOM; in a window that's to scale instead of doing a fullscreen thing so you can actually see it.

 

Funny. When I changed GZDoom to do exactly that, a few people complained. I guess you can't please anyone... :D

 

Share this post


Link to post
Guest
This topic is now closed to further replies.
×