DOOM Retro v5.3 (updated March 3, 2024)

[VGA]

Krazov said:

I actually like going over 100%. Feels like an achivement.

Heh, the only real achievement is an all 100% finish!

[Brewtal_Legend]

any youtube vids of doom retro in action?

[VGA]

https://www.youtube.com/watch?v=LipPAKfKrNM

[bradharding]

VGA said:

https://www.youtube.com/watch?v=LipPAKfKrNM

Although I very much appreciate Wales Gaming for recording it, unfortunately the audio and video are out of sync on this one, and being recorded with v1.5, doesn't have the sexy shadows from v1.6...

I'd record a vid myself, but for the life of me can't get any video capture software working on my PC... :\

[Krazov]

Are there any freeware programs to record gameplay?

[Linguica]

Well there's http://camstudio.org/ which seems to work for a lot of people

[Krazov]

Thanks. I tried google something once, and failed to find anything suitable. Let's see how this works.

[VGA]

I tested Dehacked support with "Batman TC for DOOM2" but the results were ... bad :-)

[bradharding]

VGA said:

I tested Dehacked support with "Batman TC for DOOM2" but the results were ... bad :-)

Thanks for the report. I'll look into it using the batman tc specifically.

[bradharding]

Listening to feedback from the recent release of v1.6 of DOOM RETRO, I've just made a small point release, v1.6.1, available for download on doomretro.com. The changes are as follows:

• If a DeHackEd file (with a .DEH extension) is present with the same name and in the same folder as the selected PWAD, it will be automatically opened as well.
  
• Improvements have been made to when the player slides against walls.
  
• A bug has been fixed whereby the screen would not render fully after switching from fullscreen to windowed modes when pressing ALT + ENTER.
  
• Several compatibility fixes have been made when using DeHacked files and lumps.
  
• Savegames for Back To Saturn X are now separated by episode.
  
• A bug has been fixed whereby HacX: Twitch ‘n Kill wouldn’t load at all. Specific support has now been added for it.
  
• Fake contrast is now applied to outdoor area again.
  
• Thing triangles no longer appear for the invisible corpses in <i>Chex Quest</i> when using the IDDT cheat in the automap.
  
• The default value of snd_maxslicetime_ms has been changed from 120 to 28. This is consistent with Chocolate DOOM’s default, and reduces the slight lag when playing sounds.
  
• The centeredweapon setting has been added to doomretro.cfg. Setting it to true will center the player’s weapon each time it’s fired (the default). If false, Vanilla DOOM’s behavior is used.
  
• A bug has been fixed whereby input would momentarily become stuck if the splash screen was skipped at startup.
  
• Blood splats are now green in Chex Quest as intended.
  
• A bug has been fixed whereby switching to and from the chainsaw using the number keys really quickly would cause either a crash, or the player’s weapon to disappear completely.
  
• The player’s weapon bob is now consistent with Vanilla DOOM.
  

[bradharding]

WARNING: Vent post

Since DOOM RETRO's release almost 11 months ago, I've received a lot of positive support, which has certainly motivated me to continue its development. Unfortunately, some people haven't been so supportive, as they have expressed on Twitter and 4Chan. Stuff like:

"baby's first source port"

"...I have to say, wow, it's f**king software mode Doom with no options menu and nothing but the bare basics in the .cfg file. Why is this? Are there big plans for this somewhere down the road, or is it really this unremarkable?"

"Doom Retro is f**king garbage and is objectively inferior in every way to other source ports"

"awful and misguided"

Obviously these people aren't worth entering a dialog with, so I've decided to passively-aggressively work on a "philosophy" document to make my goals clearer. What do people think of the following opening paragraphs? ;)

DOOM RETRO has been forked from Chocolate DOOM, and although it has also been designed around a careful and deliberate philosophy, its goals are quite different.

DOOM RETRO is not, and never will be, an "everything for everybody" source port. It's minimalist design is intentional. It is not meant as a complete replacement or competitor to more full-featured source ports such as ZDoom. If modern features that bring DOOM more in line with Quake, such as OpenGL, mouselook, etc., are important to you, or you think Brutal DOOM is awesome, then perhaps DOOM RETRO isn’t for you.

Discuss.

[VGA]

If a DeHackEd file (with a .DEH extension) is present with the same name and in the same folder as the selected PWAD, it will be automatically opened as well.

Is this intended to help newbies with drag'n'dropping wads onto the exe? Sounds like a good idea but now if I remove the deh file from my ZDL list (or my batch file cmdline) it still gets loaded.

Also, it's true that your port targets a niche audience, in your statement you should focus on your goals for this project and stating who this port is made for (not the opposite)

I noticed in HacX and Batman TC a wrong icon when picking up keys. I think.

One thing this port could benefit from is 32bit color to get rid of the color banding, what do you think about that? Are you following the development in that other thread? Also, what about x3 or x4 native res?

[bradharding]

VGA said:

Is this intended to help newbies with drag'n'dropping wads onto the exe? Sounds like a good idea but now if I remove the deh file from my ZDL list (or my batch file cmdline) it still gets loaded.

Oh. Putting -NODEH on the command-line should resolve this, but this'll disable loading DEHACKED lumps as well. Maybe a -NOAUTODEH cmd-line option?
That said, is there any particular instance where you don't want to load a PWAD without its accompanying DEH file?

Also, it's true that your port targets a niche audience, in your statement you should focus on your goals for this project and stating who this port is made for (not the opposite)

Lol. You're right. I was just venting. :)

I noticed in HacX and Batman TC a wrong icon when picking up keys. I think.

I did try remedying this. I'll need to look into some more. Thanks.

One thing this port could benefit from is 32bit color to get rid of the color banding, what do you think about that? Are you following the development in that other thread? Also, what about x3 or x4 native res?

I'm interested in 32bit color as well, and have had a look at _bruce_'s code. I may look at implementing it soon. x3 and x4 native res is definitely a possibility as well. Thanks.

[fabian]

Hey Brad,

bradharding said:

Obviously these people aren't worth entering a dialog with, so I've decided to passively-aggressively work on a "philosophy" document to make my goals clearer. What do people think of the following opening paragraphs? ;)

it's surprising, but although it takes a lot more effort to rant about something than to say "good job, thank you", some people strictly seem to prefer the former.

Talking about the PHILOSOPHY document, I think you should clearly state that you broke any Vanilla-compatibility (config files, savegames) and the ability to record and playback demos on purpose -- because it was necessary to implement other features in turn. I think this is something that people still expect when they read about a fork of Chocolate Doom.

bradharding said:

I'm interested in 32bit color as well, and have had a look at _bruce_'s code. I may look at implementing it soon. x3 and x4 native res is definitely a possibility as well. Thanks.

I have a "hicol2" branch of Crispy Doom prerared that I work on occationally. It is not yet finished, it compiles and runs already, but nothing fancy yet and not to come.

https://github.com/fabiangreffrath/crispy-doom/commits/hicol2

It is currently waiting for Chocolate Doom to migrate to SDL 2 or for the gl-branch to complete, so I can benefit from hardware-based rendering. Since you have already migrated DR to SDL2, maybe it is worth a look. As a start, you may just have to look for the pixel_t type and the changes in R_InitColormaps().

- Fabian

[Linguica]

I was playing with Doom Retro a little today and something about it seemed "off." When I looked in the cfg file I finally noticed a "saturation" cvar that was defaulted to 0.75, and when I changed it to 1.0, it fixed the weirdness I was experiencing. Poking around the website I discovered that this was added "to better replicate the look of CRT monitors, which are/were not as bright as current LCD monitors". Here's a comparison for people reading this:



Now I'm not a technical expert in display technologies and color spaces and so forth, but this doesn't make sense to me. CRTs may not be as bright as modern LCD monitors, but their contrast ratio is usually far better. (Modern high-end monitors with local dimming might make this more level though.) Also, various professionally-oriented websites like http://www.displaymate.com/crts.html state that CRTs have the best color reproduction of any display technology.

So that said, it seems like purposely desaturating the game in order to make it look like a CRT is backwards - LCDs simply can't reproduce the colors and contrast of a CRT under even ideal conditions, much less when you purposely handicap the colors being displayed.

[bradharding]

fabian said:

...Talking about the PHILOSOPHY document, I think you should clearly state that you broke any Vanilla-compatibility (config files, savegames) and the ability to record and playback demos on purpose -- because it was necessary to implement other features in turn. I think this is something that people still expect when they read about a fork of Chocolate Doom.

Thanks. This is a great suggestion!

I have a "hicol2" branch of Crispy Doom prerared that I work on occationally. It is not yet finished, it compiles and runs already, but nothing fancy yet and not to come.
...
It is currently waiting for Chocolate Doom to migrate to SDL 2 or for the gl-branch to complete, so I can benefit from hardware-based rendering. Since you have already migrated DR to SDL2, maybe it is worth a look. As a start, you may just have to look for the pixel_t type and the changes in R_InitColormaps().

I've been meaning to check that out! :)
Although there's SDL2 code in there, it's not active and not used in the current binary release. There's several problems I haven't been able to iron out just yet. SDL2 is soooo different to SDL1.2...

Linguica said:

I was playing with Doom Retro a little today and something about it seemed "off." When I looked in the cfg file I finally noticed a "saturation" cvar that was defaulted to 0.75, and when I changed it to 1.0, it fixed the weirdness I was experiencing.
...
So that said, it seems like purposely desaturating the game in order to make it look like a CRT is backwards - LCDs simply can't reproduce the colors and contrast of a CRT under even ideal conditions, much less when you purposely handicap the colors being displayed.

You're right. I suppose it does give it a somewhat washed out, less vibrant look, not that anyone has mentioned that specifically. I'll look at either defaulting it to 1.0 in the next release, or maybe remove it entirely. Thanks, Linguica.

[Linguica]

Also while I'm at it, shouldn't the spectre's shadow be more translucent than the other shadows?

[fraggle]

bradharding said:

Discuss.

I think having a clear philosophy is a good thing for any project, but particularly for Doom source ports. Years ago when I did SMMU it didn't have any particular goal or direction other than "fraggle hacks random stuff into the Doom codebase that he thinks might be interesting". It turns out this doesn't make for a very compelling project: either for attracting users or - in a personal sense - for sustaining energy and continued development. I only decided to do Chocolate Doom because I had a clear conception of what I wanted to do and achieve.

For Chocolate Doom it's a philosophy that's fairly easy to explain in concrete terms in a single sentence. Most people have no difficulty in understanding it. My impression of Doom Retro from the beginning has been that you obviously have a clear vision of what you're trying to do. But it's a less "concrete" philosophy than Chocolate Doom and I don't think everyone understands that vision or necessarily "gets" what you're doing. When that's the case, people are more likely to judge it by comparing it to other source ports - "Doom Retro sucks, it doesn't have feature x or y or z".

I do think it's important not to pay too much attention to haters like this. Any moderately successful project will eventually get some negative attention. I've seen plenty of people voice negative opinions about Chocolate Doom as well, but if someone says "Chocolate Doom sucks, it doesn't have mouselook or jumping" I can just laugh and point them at the project description.

Writing a philosophy document is a good idea, but don't get too hung up on what these people say, or trying to respond to them. In the end they're just people who "don't get it", and that's sad.

But you can certainly improve how you communicate the philosophy of the port. If I can make a criticism: it would be nice if the website was a bit more "structured", in a way that newcomers can learn about the port and your vision for the project. Back when you launched the port last year, it actually did a much better job of conveying this: it was just this post and the link to the detailed release notes for v1.0. It wasn't too much effort to browse through them and get a feel for what you were doing.

Since then you've done a bunch of releases, and the original notes have dropped off the front page. You've got a long list of changes for each release, but what's changed since the last release isn't necessarily what people want to read if they're just learning about the project for the first time. The level of detail is such that it might be a bit hard to see the wood for the trees.

What I think would be a good idea is if you had a page on the website that explains what Doom Retro is and perhaps gives some kind of guided tour of the port. Go back to those original release notes because I think they did a pretty good job. Trim out a lot of the minutiae because nobody wants to read pages and pages of text, but do point out that one of Doom Retro's biggest strengths is its attention to detail, and maybe give a couple of examples (the status bar digits graphic is a really good example).

[bradharding]

Linguica said:

Also while I'm at it, shouldn't the spectre's shadow be more translucent than the other shadows?

LOL! I was actually considering exactly this when implementing the shadows. I'll give it a go! Thanks!

fraggle said:

... you can certainly improve how you communicate the philosophy of the port. If I can make a criticism: it would be nice if the website was a bit more "structured", in a way that newcomers can learn about the port and your vision for the project. Back when you launched the port last year, it actually did a much better job of conveying this: it was just this post and the link to the detailed release notes for v1.0. It wasn't too much effort to browse through them and get a feel for what you were doing.

Since then you've done a bunch of releases, and the original notes have dropped off the front page. You've got a long list of changes for each release, but what's changed since the last release isn't necessarily what people want to read if they're just learning about the project for the first time. The level of detail is such that it might be a bit hard to see the wood for the trees.

What I think would be a good idea is if you had a page on the website that explains what Doom Retro is and perhaps gives some kind of guided tour of the port. Go back to those original release notes because I think they did a pretty good job. Trim out a lot of the minutiae because nobody wants to read pages and pages of text, but do point out that one of Doom Retro's biggest strengths is its attention to detail, and maybe give a couple of examples (the status bar digits graphic is a really good example).

Thanks once again for your support Fraggle. I have kind of tried to remedy the situation by including the yellow "Are you new to DOOM or DOOM source ports?" box at the top of each post, which has eliminated the questions from newcomers who don't know they need a DOOM wad. I've also fleshed out the Wiki quite a bit recently. But, yes, this doesn't go far enough and I'll look into creating a "sticky post" of sorts with some of the explanation from the first post, so as not to greatly affect the layout. Whether I can do this concisely is another matter... :)

[fabian]

fraggle said:

I think having a clear philosophy is a good thing for any project, but particularly for Doom source ports. Years ago when I did SMMU it didn't have any particular goal or direction other than "fraggle hacks random stuff into the Doom codebase that he thinks might be interesting". It turns out this doesn't make for a very compelling project: either for attracting users or - in a personal sense - for sustaining energy and continued development.

I just found myself in the same position, adding more and more features to Crispy Doom and losing more and more my own vision of the port along the way. That's why I did a strict feature review for the recent release, removing a lot of cruft that was either not Vanilla-compatible or not drastic enough to deserve its own config switch.

[Gez]

bradharding said:

Obviously these people aren't worth entering a dialog with, so I've decided to passively-aggressively work on a "philosophy" document to make my goals clearer. What do people think of the following opening paragraphs? ;)



Discuss.

First thing I saw is one of my old grammar pet peeves: the possessive pronoun is "its", "it's" is the contraction of "it is" or sometimes "it has". :p

That text you have merely say the design is minimalist, but it doesn't say much about the actual philosophy. You should concentrate on "why was it forked from Chocolate Doom". That actually includes two parts: why fork from Chocolate Doom (instead of the original source release, or an advanced port like PrBoom+, Eternity, ZDoom, Doomsday, EDGE, Legacy...), and then why fork from it.

I don't know if it's true, but the vibe I've been having about Doom Retro was that you were trying to make Doom into what you misremembered from it: something faithful to the embellished memories of playing that game a long time ago, back when pixel didn't seem that big and you didn't have the experience of so many newer games to give you a better grasp of Doom's original limitations.

[Breezeep]

NO NO NO NO NO

NO DRAMA, BAD! BAD POSTER

[scroton]

NO NO NO NO NO

NO DRAMA, BAD! BAD POSTER

[Linguica]

No inter-forum drama, please.

[scroton]

Linguica said:

No inter-forum drama, please.

My post wasn't inter-forum drama. It had nothing to do with any other forum, and was squarely focused on Doom Retro and how it is presented by it's creators alongside solicitations for donations. It also pointed out how this differs from pretty much every single other Doom source port.

[kb1]

bradharding said:

WARNING: Vent post

Since DOOM RETRO's release almost 11 months ago, I've received a lot of positive support, which has certainly motivated me to continue its development. Unfortunately, some people haven't been so supportive, as they have expressed on Twitter and 4Chan.

If you build out of love, not to be loved, you have nothing to vent. Also, go check out their source port. Oh, wait...

[bradharding]

kb1 said:

If you build out of love, not to be loved, you have nothing to vent. Also, go check out their source port. Oh, wait...

Oh well. I've worked on something I'm proud of, promoted it through social media thinking it would be something other people would enjoy, used my name because that's my name, and because of course it is free, mention at the end of each release post that people can donate if they so choose. I may not have been clear on exactly what the source port is about on the website, and that seems to have attracted some flack, but that comes down to poor judgement on my part, and not any attempt at misrepresentation. That said, I make no apologies, and will continue to work on DOOM RETRO for myself, and those who understand, appreciate and support it.

[Coraline]

That's what counts. Your port is still very new and there's plenty of examples from Choco's children to look upon -tried and true, very stable, excellent source ports. The flak you get is nothing in comparison to what I've gotten, though! =)

I'm working to both re-popularize 3DGE and cleanse its bad reputation that it carried for a long time and it's not easy but its not my primary goal either. Admittedly the changes I've been making seem to breathe some new life into it, simply because it's what I've wanted to see out of EDGE for so long and wasn't able to do it back then. The wiki I've set up for it is also solving the biggest damn gripe I've had about the port since DosDOOM - the lack of central documentation.

It boils down to how much fun you have, and at the end of the day, knowing that you are doing it for yourself. Having people use and enjoy it is just icing in the already delicious cake you've baked. Eat it yourself, and let people have some if they want. ;)

[Brewtal_Legend]

This is a rather nice vanilla style port with some very nice and very subtle additions.

I wasn't very clear on what the port was about as some others have pointed out, but gave it a try finally and just wanted to say that I found it very nice.

I like the added gore. Not too much, and not too little.

The shadows are also a very nice little touch as well as the slightly translucent projectiles.

I like that it has gamepad support as well, only it would be nice if the controller support was more customizable. Such as being able to hange the button bindings and change the different joystick axis sensitivity.

Also, the options menu seems to be quite sparse. It would be nice to have a few more things in there like toggling the crosshair, resolution, always run, etc.

All in all, a very nice port.

[raymoohawk]

caps lock toggles always run no?