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

So I didn't say anything previously, because I was debating whether I wanted to stir the pot or not, but I think I should at least give my thoughts on a couple things, since DSDA Doom is my main port of choice - It is the port that I enjoy playing on the most, both for it's rendering and "game feel".

1) I'm glad that since version 0.27, turning on ENDOOM no longer results in DSDA Doom hard crashing when exiting.

Though I will say that with my experience on Windows 11, how ENDOOM is implemented is absolutely useless and so I just end up turning it off. Having it print in the console window and just immediately disappear is quite lame, and is basically the equivalent of just not seeing the ENDOOM at all.

I'm not saying this to stir more controversy, I'm just telling you how it currently is. I think I've seen certain people recommend to use different default consoles to stop it from just exiting, but honestly I think that it should not be on the user to have to do that. Having to change a default console on Windows just for DSDA Doom is quite honestly ridiculous. This is all I will say on this matter, as I do not want a repeat of the previous ENDOOM clusterf---.

2) This was actually done in the latest major release of DSDA Doom, but I'm not really a fan of removing features from the port that were in the original Doom. To this point, I am specifically talking about the screen zoom being removed.

You'd expect source ports to generally keep features included in the original game, and expand features on top of it. It seems strange to me, for original features to be stripped out (just to clarify, I am not talking about ENDOOM here, as ENDOOM is technically outputted after the program is closed, so you could see it as not part of the original game in a way).

I'm not saying I actually use this features (I don't), but it's more about what removing this features means for the future. It means that you have no problems stripping out other stuff from the game that was there originally, and that honestly concerns me. What other features will you decide to strip out of the port, since original features such as that have been removed? I often tend to joke about this with other Doomers, but I do find it a bit worrying... I can't wait to see the HELP screen get removed in a later update.

15 minutes ago, Arsinikk said:

Though I will say that with my experience on Windows 11, how ENDOOM is implemented is absolutely useless and so I just end up turning it off. Having it print in the console window and just immediately disappear is quite lame, and is basically the equivalent of just not seeing the ENDOOM at all.

Try to run DSDA-Doom from the console. Or create a dsda-doom.bat file in the port directory with this code:

dsda-doom %*
pause

You can run this bat instead of exe, console window with ENDOOM will stay after program exit.

Or use launcher https://github.com/Pedro-Beirao/dsda-launcher

26 minutes ago, rfomin said:

Try to run DSDA-Doom from the console. Or create a dsda-doom.bat file in the port directory with this code:

dsda-doom %*
pause

 You can run this bat instead of exe, console window with ENDOOM will stay after program exit.

 Or use launcher https://github.com/Pedro-Beirao/dsda-launcher

This would not help my case, because I use Doom Launcher to manage my hundreds of WADs. Even so, if I used ZDL or some other launcher, the fact that I need to create a bat file or run it through the console is poor user experience imo.

Even so, wouldn't it make more sense to just execute the "pause" command by default? (Forgive me as I do not know how the DSDA Doom code works, so it's possible that it doesn't work that way). I'd assume anyone on Windows (or any OS) who would set ansi_endoom 1, would want it to pause by default anyway. There's no other reason they would set that option, unless they wanted to see and look at the ENDOOM.

It seems like a bad idea to make particular launchers to have to add their own support for the "pause", rather than just implement it in the engine itself. Then you'd run into every launcher having to add support for this specific use case for this one specific engine.

Then again, I've never been a huge fan of printing the ENDOOM in a small console window anyway (I'm not going to argue about how it should be done, since I don't know how the engine is coded). I will however give my experience as a user of the engine itself, and currently I'd say with how the ENDOOM implementation is, it isn't even worth me turning on honestly.

16 minutes ago, Arsinikk said:

This would not help my case, because I use Doom Launcher to manage my hundreds of WADs. Even so, if I used ZDL or some other launcher, the fact that I need to create a bat file or run it through the console is poor user experience imo.

Use dsda-doom.bat instead of dsda-doom.exe in the Doom Launcher and it will work.

18 minutes ago, Arsinikk said:

Then again, I've never been a huge fan of printing the ENDOOM in a small console window anyway (I'm not going to argue about how it should be done, since I don't know how the engine is coded).

You can increase console window size and change font. Right click console window title bar->Properties. 

8 minutes ago, rfomin said:

34 minutes ago, Arsinikk said:

This would not help my case, because I use Doom Launcher to manage my hundreds of WADs. Even so, if I used ZDL or some other launcher, the fact that I need to create a bat file or run it through the console is poor user experience imo.

Use dsda-doom.bat instead of dsda-doom.exe in the Doom Launcher and it will work.

 

34 minutes ago, Arsinikk said:

Then again, I've never been a huge fan of printing the ENDOOM in a small console window anyway (I'm not going to argue about how it should be done, since I don't know how the engine is coded).

You can increase console window size and change font. Right click console window title bar->Properties. 

I think you are missing the point I'm trying to make. My point isn't necessarily that it's impossible to get something to work the way I'd want. Nor is it that I wanted you to troubleshoot an issue I'm having.

The point is that for a person to get the ENDOOM to work in a reasonable way, it requires jumping through a bunch of hoops to get there. Why not just make it easier for the user?

Trust me, I can work my way through complex stuff such as setting up VULD with a specific configuration to use DOOM32.EXE and a specific version of DEHACKED with [PARS], all while running DOSBOX with a specific config. I regularly fiddle with the Windows Registry to get certain parts of Windows to do what I want. I even have no problem compiling source code for specific doom ports for testing and troubleshooting. I even code my own infopacks my some of my WADs. I know how to do complicated software tweaking.

My problem is that most people do not. Are you going to tell every single person who wants to use the ENDOOM screen in DSDA Doom to create a BAT file with specific arguments to get it to stay? Many casual Doom players may not even know what BAT files are. That is my point, as many users that try and use the ENDOOM option are just going to say that it disappears and just never bother fix it and turn it off.

Maybe I would agree with your point if it was a parameter like -file or -complevel, but I think BATs and console arguments are a bit much for many modern users, especially nowadays. For someone who uses DOS or Linux, maybe, but not for many Windows users.

I'd just like to clarify that this is not a heated statement, I'm just trying to clarify, in detail, what I meant when I said DSDA Doom's ENDOOM support was poor. It is through the eyes of a casual player that just wants to play using a somewhat accurate sourceport and wants to have the ENDOOM screen shown on close. (Before you say "oh just use Woof", I'm not a particular fan of how the rendering works in Woof or Nugget Doom. There's something about how DSDA Doom renders high-resolution that is unmatched in demo-compatible sourceports imo).

48 minutes ago, Arsinikk said:

I'd just like to clarify that this is not a heated statement, I'm just trying to clarify, in detail, what I meant when I said DSDA Doom's ENDOOM support was poor. It is through the eyes of a casual player that just wants to play using a somewhat accurate sourceport and wants to have the ENDOOM screen shown on close. (Before you say "oh just use Woof", I'm not a particular fan of how the rendering works in Woof or Nugget Doom. There's something about how DSDA Doom renders high-resolution that is unmatched in demo-compatible sourceports imo).

This and the amputation of the hardware renderer are the reasons why I choose to stick with older versions when I'm in the mood to play with more traditional settings. Easier maintenance or not, removing features that are in active use is not good operating procedure.

Which is kind of a shame. Aside from these things DSDA is far and away the best of the demo compatible ports with its rapidly evolving feature set

27 minutes ago, Arsinikk said:

I think you are missing the point I'm trying to make. My point isn't necessarily that it's impossible to get something to work the way I'd want. Nor is it that I wanted you to troubleshoot an issue I'm having.

 

The point is that for a person to get the ENDOOM to work in a reasonable way, it requires jumping through a bunch of hoops to get there. Why not just make it easier for the user?

Not too many hoops to jump through. ENDOOM from DSDA-Doom has its advantages - you can choose a font, raster or vector based with proper antialiasing, etc. The problem is that Windows had no terminal emulator by default, so the authors of Chocolate Doom wrote their own, surprisingly it appeared in other ports. It's understandable that DSDA dev doesn't want to maintain it, since there are a huge number of terminal emulators out there.

I recommend using Windows Terminal App it should be the default in Windows 11, right?

42 minutes ago, Arsinikk said:

Are you going to tell every single person who wants to use the ENDOOM screen in DSDA Doom to create a BAT file with specific arguments to get it to stay? 

Well, arguably ENDOOM is an advanced feature that not many people know about. If I didn't play the game in the 90s, I probably didn't know about it.

48 minutes ago, galileo31dos01 said:

Another one in the list, me. Even though I was never into dsda/prboom's OPL2 as much as OPL3 in crispy in its most pure self, when using viddump the only two soundfonts you could choose where opl or fluidsynth, afaik, and between those I less preferred the latter by far. I would support adding opl back in, if that doesn't present too many new issues along the way. 

It was added with OPL3 from Chocolate/Crispy Doom enabled by default. Download the latest version :)

1 minute ago, rfomin said:

The problem is that Windows had no terminal emulator by default

Why is that a problem? You can do it like GZDoom which just renders ENDOOM into the game window, waiting for a keypress, and that works on all supported OSs and can of course be disabled in case the users don't like it.

1 minute ago, Professor Hastig said:

You can do it like GZDoom which just renders ENDOOM into the game window, waiting for a keypress, and that works on all supported OSs and can of course be disabled in case the users don't like it.

Actually, GZDoom has a little terminal emulator built in. It's not that simple...

2 minutes ago, Professor Hastig said:

Why is that a problem? You can do it like GZDoom which just renders ENDOOM into the game window, waiting for a keypress, and that works on all supported OSs and can of course be disabled in case the users don't like it.

The way ENDOOM works now is that it's actually an output after DSDA Doom closes. The devs wanted to strip out the ENDOOM code (and perhaps a terminal emulator like rformin said) from DSDA Doom completely, so it makes sense if they wanted to make DSDA Doom a bit lighter.

I still think that it'd be nice to have a separate ENDOOM.exe program that DSDA Doom could send the ENDOOM information to, have it open after DSDA Doom closes, display the ENDOOM in full screen, and then close on key press. Of course, I'm not an exe programmer (at least to that capacity), so I can't say how difficult that'd be to implement. But it seems like having a separate program could make things pretty simple for the user and easier for the developer. Still I don't wanna say too much, cuz I don't know what it would require to code such a program.

8 minutes ago, rfomin said:

Actually, GZDoom has a little terminal emulator built in. It's not that simple...

If you call a routine that copies the glyphs from an embedded font into a bitmap a terminal emulator, then yes. Because that's all there is - a few kb of code that turn ENDOOM into a bitmap and then render the whole thing.

10 minutes ago, Professor Hastig said:

If you call a routine that copies the glyphs from an embedded font into a bitmap a terminal emulator, then yes. Because that's all there is - a few kb of code that turn ENDOOM into a bitmap and then render the whole thing.

Please don't make this a repeat of what happened the last time ENDOOM and DSDA Doom was discussed.

Just as last time, I've been respectful of the dev and the work that they've put in. It's a better idea to try and make everyone happy than try and argue semantics.

Obviously there is a reason the dev doesn't want to have the ENDOOM code in. Let's leave that as it is and instead focus on ways we can make the dev's work easier. That's why I suggested a separate ENDOOM.exe solution.

6 minutes ago, Arsinikk said:

That's why I suggested a separate ENDOOM.exe solution.

How is that going to make work easier? Now you got to maintain two projects instead of one!

I know perfectly why the ENDOOM code was dumped and I agree with the assessment that it turned out far too complex for its own good and essentially a nuisance.

That doesn't mean there's no simpler and less impactful means to get the screen back in a fashion that doesn't turn into a development hindrance.

9 minutes ago, Professor Hastig said:

How is that going to make work easier? Now you got to maintain two projects instead of one!

I was thinking that if dsda-dev doesn't want to develop a ENDOOM-type viewer, another dev could come up with it.

Obviously it's possible since other ports like GZDoom have ENDOOM solutions. All someone would have to do is strip just the ENDOOM terminal displaying code and isolate it.

Then all that DSDA Doom would have to do then is send the ENDOOM data of the WAD to the separate exe.

Plus, I'm not sure what you mean by maintaining two projects. ENDOOM has worked the same for 20 years. I doubt such a program would have to updated that frequently, if at all.

47 minutes ago, Arsinikk said:

Then all that DSDA Doom would have to do then is send the ENDOOM data of the WAD to the separate exe.

How is installing another exe in the same folder as dsda less of a hoop-jumping exercise than making the .bat file with pause?

15 minutes ago, Gez said:

How is installing another exe in the same folder as dsda less of a hoop-jumping exercise than making the .bat file with pause?

It is easier for the user. They just drag and drop an exe in the folder and it works. A BAT file requires you to create a BAT, type in the commands, and if you are using a launcher, you can't launch it using the normal exe.

Yeah I'm used to dealing with BAT files, so it's easy for me, but for casual windows users, it may as well be hacking to them. Am I literally the only person that realises that BAT files are not normal for casual users? Casual users just wanna drop a file in and have it work when they run the exe. Quite honestly, causal users would just want the ENDOOM functionality embedded in DSDA Doom... But we can't have that, because DSDA-Dev doesn't want the code in the DSDA Doom. And so I'm looking for other solutions.

Plus you ignoring the fact that some users would like a solution that is more similar to GZDoom with a full-screen option. Having a separate program would allow that, possibly with extra options. Who knows?

1 minute ago, Arsinikk said:

It is easier for the user. They just drag and drop an exe in the folder and it works. A BAT file requires you to create a BAT, type in the commands, and if you are using a launcher, you can't launch it using the normal exe.

No, actually it is not. You are thinking in Windows terms now, but doing the same action in Linux or macOS is no longer trivial - neither would the .bat be, of course. So ultimately this would be a platform specific solution which I don't think sounds that appealing to the developers.

You are forgetting something else as well: This won't be seamless. Launching another EXE means a context switch, forcing new windows to pop up, possibly animated by the OS and definitely causing some visual disturbance during the transition. If you want a seamless display of ENDOOM when quitting the game the only option is to do it the GZDoom way, i.e. render ENDOOM to a bitmap and display that on the game screen while waiting for the user to press a key to quit.

53 minutes ago, Professor Hastig said:

 

How is that going to make work easier? Now you got to maintain two projects instead of one!

I know perfectly why the ENDOOM code was dumped and I agree with the assessment that it turned out far too complex for its own good and essentially a nuisance.

That doesn't mean there's no simpler and less impactful means to get the screen back in a fashion that doesn't turn into a development hindrance.

 

An ENDOOM viewer obviously is a lot less complex than a source port. In the DOS age, there used to be seperate programs that do this.
 

1 hour ago, Arsinikk said:

The way ENDOOM works now is that it's actually an output after DSDA Doom closes. The devs wanted to strip out the ENDOOM code (and perhaps a terminal emulator like rformin said) from DSDA Doom completely, so it makes sense if they wanted to make DSDA Doom a bit lighter.

 

I still think that it'd be nice to have a separate ENDOOM.exe program that DSDA Doom could send the ENDOOM information to, have it open after DSDA Doom closes, display the ENDOOM in full screen, and then close on key press. Of course, I'm not an exe programmer (at least to that capacity), so I can't say how difficult that'd be to implement. But it seems like having a separate program could make things pretty simple for the user and easier for the developer. Still I don't wanna say too much, cuz I don't know what it would require to code such a program.

A bat file can be converted to an exe, and even with a custom icon. So essentially, DSDA could simply disable the ENDOOM from ever appearing, but with said bat converted to exe, display it anyway. I use Slimm Bat To Exe for it that allows custom icons, but there is also this. 

Perhaps @jval could strip out the editing features of his ENDEDIT and make ENDVIEW?

If DSDA gets shipped with the bat file so people don't have to create it, will the complaints stop? A third-party program would literally do nothing else, and would require writing some interface code for it in DSDA, which defeats the purpose of removing ENDOOM code in the first place.

14 minutes ago, Redneckerz said:

A bat file can be converted to an exe, and even with a custom icon. So essentially, DSDA could simply disable the ENDOOM from ever appearing, but with said bat converted to exe, display it anyway. I use Slimm Bat To Exe for it that allows custom icons, but there is also this. 

I actually didn't think of this. I myself have used BAT 2 EXE before, and then used another program to add a custom icon to it. Lol but if Slimm Bat To Exe does both that's even better.

To be fair, I think having an BAT file turned EXE would work well. The reason I brought up a new ENDOOM exe is cuz it could possibly allow for more customisation and features specific to ENDOOM only.

16 minutes ago, Gez said:

If DSDA gets shipped with the bat file so people don't have to create it, will the complaints stop? A third-party program would literally do nothing else, and would require writing some interface code for it in DSDA, which defeats the purpose of removing ENDOOM code in the first place.

I could be wrong, but doesn't DSDA Doom export the ENDOOM code into the console while it exits? Couldn't that data just be sent to another EXE without changing too much? I don't see how you'd be required to add back interface code back into DSDA, if you are just sending the data to another program that has that interface code. (Forgive me as I don't know how DSDA exactly deals with ENDOOM code).

A third-party program, as I said above, could possibly allow for more customisation and features specific to ENDOOM only. The beauty of this option would be that DSDA-Dev would not have to worry or deal with ENDOOM again. Looking forward, it could also potentially be used by other source ports as well.

3 minutes ago, Arsinikk said:

I could be wrong, but doesn't DSDA Doom export the ENDOOM code into the console while it exits?

That's literally just a print to stdout.

5 minutes ago, Arsinikk said:

Couldn't that data just be sent to another EXE without changing too much?

You need to get that other exe to replace stdout.

1 hour ago, Arsinikk said:

I actually didn't think of this. I myself have used BAT 2 EXE before, and then used another program to add a custom icon to it. Lol but if Slimm Bat To Exe does both that's even better.

 

To be fair, I think having an BAT file turned EXE would work well. The reason I brought up a new ENDOOM exe is cuz it could possibly allow for more customisation and features specific to ENDOOM only.

So essentially, a bat that does a call to stdout (or can intercept that and display it in the terminal). 

Then again, how many people would want this? I know its a little effort, but what are the gains? 

3 minutes ago, Redneckerz said:

Then again, how many people would want this? I know its a little effort, but what are the gains? 

Well tbh the ENDOOM discussion seems to pop up quite often in the DSDA Doom threads.

Tbh the only reason I mentioned anything in this thread is cuz someone else mentioned the Windows implementation of ENDOOM and how it disappeared almost immediately. If anything an ENDOOM solution would cause people to stop mentioning it in these threads, and if they did, people could just direct them to a link instead.

Tbh the ENDOOM "craze" may have been slightly my fault for starting the ENDOOM appreciation thread in the first place, which still has people posting new and old ENDOOMs of PWADs. Since now that Doomers keep coming across that thread, they now wanna see the screen show up in their ports to appreciate the art.

I use the official DSDA Launcher on MacOs and ENDOOM automatically shows up in a window after quitting pretty much the same way it does with Chocolate Doom

Yep, PBeGood4 added endoom support directly in the official launcher. You don't even need to change the port settings directly as the launcher handles it. Messing with the terminal or batch files is something for advanced users who like to tinker or customize things. E.g., I like that endoom now shows up in my terminal using my own font setup. If someone doesn't like to tinker and also doesn't want to use the launcher, then endoom doesn't exist for them.

5 hours ago, Redneckerz said:

A bat file can be converted to an exe, and even with a custom icon.

It's even possible to skip the conversion altogether by simply creating a shortcut to the .bat file and selecting the icon you want for said shortcut.

6 hours ago, rfomin said:

Actually, GZDoom has a little terminal emulator built in. It's not that simple...

DelphiDoom also renders the ENDOOM screen in the game window, with raster font, with a few dozen lines of code. (repo)

Perhaps someone can convert it to C, and use it.

8 hours ago, Redneckerz said:

Perhaps @jval could strip out the editing features of his ENDEDIT and make ENDVIEW? 

Done:

1 minute ago, jval said:

 

DelphiDoom also renders the ENDOOM screen in the game window, with raster font, with a few dozen lines of code. (repo)

Perhaps someone can convert it to C, and use it.

 

Done:

 

 

LMAO. You know this wasn't a demand or anything right? I was merely suggesting. My gratitude is forever.

This is absolutely amazing. @Arsinikk get in here!

7 minutes ago, jval said:

10 hours ago, rfomin said:

Actually, GZDoom has a little terminal emulator built in. It's not that simple...

 

DelphiDoom also renders the ENDOOM screen in the game window, with raster font, with a few dozen lines of code. (repo)

Perhaps someone can convert it to C, and use it.

Sure, Woof also renders ENDOOM screen in the game window. Your code can also be called a little terminal emulator.

I don't understand how the current version of ENDVIEW program can help in this case. User want to drop exe file in port directory to show ENDOOM after DSDA-Doom exit.

Where's the terminal and where's the emulation? All this does in all these ports is a straightforward rendering to a bitmap. In other words: very simple code without any complexity at all.

A 'terminal emulator' implies capabilities of entering text or scrolling the screen or other more advanced features.

Chocolate Doom's library is more than 100x as much code as all of these.