DOOM Retro v5.2.1 (updated January 12, 2024)

Always interesting to see the source code of other ports. I maintain one of the RiscOS source ports, and was rather surprised that in p_switch.c you're still using a hard coded table of switch textures. Below is some code from my port that simply searches through the textures looking for SW1xxxxx, SW2xxxxx pairs.
I've increased the MAXSWITCHES to 100 as the Trisen wad has 98 switch pairs!
Hope that someone finds it useful.

/* ----------------------------------------------------------------------- */
//
// P_InitSwitchList
// Only called at game initialization.
//
// For each SW1xxxxx texture we look for a corresponding SW2xxxxx texture. (JAD 27/09/11)

void P_InitSwitchList (void)
{
  int i,j;
  int count;
  int *ptr_B;
  texture_t** ptr_1;
  texture_t* ptr_2;
  char sw2name [9];

  sw2name [8] = 0;

  i = 0;
  count = 0;
  numswitches = 0;
  ptr_1 = textures;
  ptr_B = switchlist;

  do
  {
    ptr_2 = *ptr_1++;
    if (strncasecmp (ptr_2->name, "SW1", 3) == 0)
    {
      strncpy (sw2name, ptr_2->name, 8);
      sw2name [2] = '2';
      j = R_CheckTextureNumForName (sw2name);
      if (j != -1)
      {
        if (count < MAXSWITCHES)
        {
          *ptr_B++ = i;
          *ptr_B++ = j;
          numswitches++;
        }
        count++;
      }
    }
  } while (++i < numtextures);

  *ptr_B = -1;

  if ((M_CheckParm ("-showswitchcount"))
   || (count > MAXSWITCHES))
    printf ("Found %u switch pairs of %u\n", count, MAXSWITCHES);
}

/* ----------------------------------------------------------------------- */

jeff-d said:

Always interesting to see the source code of other ports. I maintain one of the RiscOS source ports, and was rather surprised that in p_switch.c you're still using a hard coded table of switch textures. Below is some code from my port that simply searches through the textures looking for SW1xxxxx, SW2xxxxx pairs.
I've increased the MAXSWITCHES to 100 as the Trisen wad has 98 switch pairs!
Hope that someone finds it useful.

Thanks jeff-d, this code will definitely come in handy! It will most certainly find its way into the next version. A quick Google and I found the source code for your port at https://sites.google.com/site/jeffreyadoggett/. I'll check it out...
Thanks again!

Hi,

Just looking through your code seeing what I can pinch!

in p_setup.c you have:

  // [BH] change all wolfenstein ss' into zombiemen when using
  //  BFG Edition DOOM2.WAD as censorship broke them
  if (mt->type == WolfensteinSS && bfgedition)
    mt->type = FormerHuman;

This looks wrong to me as you've already copied mt->type to spawnthing.type earlier.
(Also mt->type is in little endian format so needs the SHORT(mt->type) otherwise it will fail on big endian machines)
I think that you actually want:

if (spawnthing.type == WolfensteinSS && bfgedition)
    spawnthing.type = FormerHuman;

(And I've also spotted that mine also has a bug in the same function!)

Jeff

How about using the Boom SWITCHES and ANIMATED lumps? It'd be more generally useful than turning the SW1/SW2 convention into a rule.

Great work Brad - some great features!
I prefer the original resolution but the fixed 640x400 approach seems like
a kind of high def. Classic mode.


Btw, saving a game on Map22 with invulnerability, reloading and disabling
It resulted in a crash.
On the same map approaching the center octagon from
The north during a firefight may result in random red,
Blue pixels or multicolored stripes located on the first scanline.
No screens since I do not have net access on the PC and I'm
Typing this on a mobile... This dwarf keyboard sucks!

Gez said:

How about using the Boom SWITCHES and ANIMATED lumps? It'd be more generally useful than turning the SW1/SW2 convention into a rule.

Careful. Starting off with a chocolate or linuxdoom base and adding Boom features as you go -selectively, if you wish- is a slippery slope. If I had to start over Mocha Doom, I'd base it on Boom, instead.

It would be nice to have a sort of archetypical limit removing port that sits exactly between vanilla and Boom, one that's not just the v1.10 source code release in a form that compile, and is not so advanced as to practically equate a sort of "Chocolate Boom". It pities me to say, but Doom Retro is not that, for it has already lost vanilla compatibility, unless there's some version which undoes the breaking changes.

The problem seems that in Doom development's there were really few -if any- ports that were just limit removing without also being derived of Boom. Was there any other major pre-Boom development branch with a different approach to limit removal?

Gez said:

How about using the Boom SWITCHES and ANIMATED lumps? It'd be more generally useful than turning the SW1/SW2 convention into a rule.

The SWITCHES lump may offer more room for expansion, but if one doesn't add those features it's just a needless extra step over an SW1/SW2 naming convention.

For reference, Doomsday's XG also has a SW1/SW2 naming convention that automatically turns all SW1/SW2 texture pairs into switches; simply stick your SW1XYZ (or SW2XYZ) texture on the linedef and XG will animate it for you.

jeff-d said:

Hi,

Just looking through your code seeing what I can pinch!

in p_setup.c you have:

  // [BH] change all wolfenstein ss' into zombiemen when using
  //  BFG Edition DOOM2.WAD as censorship broke them
  if (mt->type == WolfensteinSS && bfgedition)
    mt->type = FormerHuman;

This looks wrong to me as you've already copied mt->type to spawnthing.type earlier.

...

Jeff

Thanks for spotting! Looks like the next release will be just bugfixes...

_bruce_ said:

Great work Brad - some great features!
I prefer the original resolution but the fixed 640x400 approach seems like
a kind of high def. Classic mode.


Btw, saving a game on Map22 with invulnerability, reloading and disabling
It resulted in a crash.
On the same map approaching the center octagon from
The north during a firefight may result in random red,
Blue pixels or multicolored stripes located on the first scanline.
No screens since I do not have net access on the PC and I'm
Typing this on a mobile... This dwarf keyboard sucks!

Thanks _bruce_. Will add this to my list(!) Will look into the invulnerability/savegame thing later, but just tried MAP22 myself and wasn't able to replicate the issue. My guess was that a Spectre was at the top of the screen and my custom fuzz effect was trying to copy pixels off the screen, but that doesn't seem to be the case when I tried. If you could please test again when convenient and grab a screenshot, that'd be great! Thanks again! :)

Something I found out rather by accident:
I wanted to check my cleanup fixes for HELP2 when I realized that -file doesn't work with Doom Shareware, at least neither in Chocolate Doom nor ZDoom (which I tried). However, I found that it works with Doom Retro. This is intended or you are going to remove it?

bradharding said:

Yes, I've checked out _bruce_'s great work, and at one point I was contemplating implementing 32-bit color but... I like the idiosyncrasies of the 256-color palette too much (especially after implementing the darker gamma levels).

Idea: you could potentially compromise between the two by increasing the number of colormaps. That would give smooth(er) lighting while keeping the 256-color idiosyncrasies.

fraggle said:

Idea: you could potentially compromise between the two by increasing the number of colormaps. That would give smooth(er) lighting while keeping the 256-color idiosyncrasies.

I tried this approach in Mocha Doom (actually, id themselves tried it in Alpha v0.4) and with 15-bit HiColor and 32 colormaps it still looks "idiosyncratic" enough.

My "true color" mode is actually a 256 (true color) colormap mode but still using 256-color indexed graphic resources, quite different than _bruce_'s sprite and frame real-time colorization approach. My method is faster, but doesn't allow as full control or easy implementation of certain effects as _bruce_'s.

I had posted some test screenshots here, though I didn't experiment extensively with intermediate colormap values (e.g. 64 or 128).

http://www.doomworld.com/vb/source-ports/61570-mocha-doom-truecolor-teaser/

I remember however than anything beyond 128 colormaps looks almost OpenGL-like, while 32 is still quite gritty. Maybe the "sweet spot" is somewhere in the middle, e.g. 64 colormaps.

And of course there's the fugly 12-bit RGB mode that was probably only used on the NeXTstep machines of the devs...

At this point however, I admit I still do not understand the "niche" of Doom Retro: it has so many departures from the vanilla codebase that it almost feels like a recreation of Doom on another engine (maybe that was the actual intention?)

Maes said:

I remember however than anything beyond 128 colormaps looks almost OpenGL-like, while 32 is still quite gritty. Maybe the "sweet spot" is somewhere in the middle, e.g. 64 colormaps.

Even in 256 color mode? That sounds difficult to believe. With the 256 color palette you still only get typically 16 "steps" per color, so the improvement is always going to be limited. But I would have thought that extra colormaps might still provide some subtle improvement.

Certainly a lot of the screenshots in your thread look "too far" from the classic look (I'm not sure you've got the lighting balance right with the new colormap). But a lot of them are in true-color mode so it's difficult to judge.

fraggle said:

Even in 256 color mode? That sounds difficult to believe.

Nono, I meant in truecolor mode (which is also the only one where going beyond 32 colormaps makes any sense whatsoever). The reason is simple: even with HiColor 15-bit mode, with just 5 bits per color, after 32 colormaps even the brightest color will go completely dark, so there's no sense having more gradations.

Sure, you can force-generate 64 colormaps with the same old 256-color palette, but at most you will get a lot of intermediate stuffing colormaps that will look very identical to the one before and the one after them. Unless you're Sodaholic, you won't see much difference.

In that old thread I linked I also discussed how hard it is to get a high number of distinct colors on-screen anyway, even with 256 colormaps in true color. In HiColor mode you might get 600 or so colors on the screen at once, in most situations, with true color I've seen values between 2000-6000 depending on the scene. The maximum possible theoretically is number of colormaps * 2^(bit depth), so even with true color you only get 65K colors tops, with 15-bit HiColor you get 8K etc.

16-bit hicolor might be an interesting situation, as that extra bit might allow a few more colormaps, but no more than 40 or 48 total, I believe. On the plus side, it will definitively look "gritty", if that's what one's after.

NightFright said:

Something I found out rather by accident:
I wanted to check my cleanup fixes for HELP2 when I realized that -file doesn't work with Doom Shareware, at least neither in Chocolate Doom nor ZDoom (which I tried). However, I found that it works with Doom Retro. This is intended or you are going to remove it?

Thanks NightFright. The -FILE command-line parameter is not meant to work using DOOM Shareware. I wanted to respect that limitation of Vanilla DOOM, but in the process of making -FILE behave more like Chocolate DOOM's -MERGE I see where I left out the check for this.

Good work on tweaking the help screens, by the way... With DOOM RETRO, an idea I have is to completely redo the help screens with the updated controls.

fraggle said:

Idea: you could potentially compromise between the two by increasing the number of colormaps. That would give smooth(er) lighting while keeping the 256-color idiosyncrasies.

But then the lighting is one of those idiosyncrasies I think I'd rather keep. I like the constraints of the 256-color palette.

BTW, I've been playing around with additive translucency as previously suggested, and translucent objects are looking a lot better...

Maes said:

At this point however, I admit I still do not understand the "niche" of Doom Retro: it has so many departures from the vanilla codebase that it almost feels like a recreation of Doom on another engine (maybe that was the actual intention?)

To be honest, I guess I've never been too interested in mods. You could say that DOOM RETRO's "niche" is for those people who want to play the original WADs, and that's it. And yes, I have deviated quite a bit from vanilla so that it does come across as a "recreation" of sorts. That being said, however, DOOM RETRO will continue to evolve, and I will try to make it more compatible.

Most Vanilla maps do work fine though.

bradharding said:

[...]
Good work on tweaking the help screens, by the way... With DOOM RETRO, an idea I have is to completely redo the help screens with the updated controls.

If you need help with those screens, I have turned into some kinda specialist for that recently. In my obsession, I am trying to create my full German translation for Doom and Doom II - including those HELP screens. Therefore I had to create templates and stuff, everything is ready to be used again for whatever purpose.

Check out my German HELP1 screen here.

If I can help you out somehow, just tell me what you need. I can also make those screens for you, provided you tell me which info you want to be shown there (in English, I presume :P). ^^

NightFright said:

If you need help with those screens, I have turned into some kinda specialist for that recently. In my obsession, I am trying to create my full German translation for Doom and Doom II - including those HELP screens. Therefore I had to create templates and stuff, everything is ready to be used again for whatever purpose.

Check out my German HELP1 screen here.

If I can help you out somehow, just tell me what you need. I can also make those screens for you, provided you tell me which info you want to be shown there (in English, I presume :P). ^^

Thanks, NightFright. I would very much appreciate your help! In the long term what I intend to do is have a fully dynamic help system based on what the player has connected and is using, and what's been set in default.cfg. (BTW fully customisable gamepad controls coming in next release.)

In the short term, would you please be able to create 3 screens for DOOM, DOOM Shareware and DOOM II that resemble the originals as close as possible with the following [anally retentive] changes:

* remove F5=DETAIL
* add G=GRID
* change 5=ROCKET to 5=ROCKET LAUNCHER
* remove 6=PLASMA RIFLE and 7=BFG 9000 in Shareware
* change MOUSE BTN 1 to LEFT MOUSE BUTTON
* change MOUSE BTN 2 to RIGHT MOUSE BUTTON
* add W, A, S, D and CAPSLOCK
* remove JOY BUTTON 1 and JOY BUTTON 2
* add GAMEPAD controls

Thanks again NightFright! I'm very glad you've taken an interest!

No problem. Do you have the default gamepad key layout by any chance?

About the shareware screen: I guess we can forget about the original HELP2 completely and instead use HELP1, just with the missing Plasma Gun and BFG 9000 listings. This way, HELP2 will be almost identical to HELP1, but you can make it so that HELP2 is displayed instead of HELP1 if you play the shareware version. If you agree, that is. ^^

The default controls for gamepads are:

Left Trigger     = Run
Right Trigger    = Fire
Left Thumbstick  = Move Forward/Back + Strafe Left/Right
Right Thumbstick = Turn Left/Right
Back Button      = Automap
Start Button     = Menu
A Button         = Use
B Button         = Next Weapon
Y Button         = Previous Weapon

Don't worry about HELP2 at all. I don't let it display in DOOM RETRO because the info is so dated. Focusing just on HELP1 will be fine.

Thanks again! :)

Here is a first suggestion for HELP.



You will notice several things:
1) Alignment of original lines could not be maintained. Too much info had to be added.
2) In "movement" section, I had to add dots to keep it from getting confusing (was done also on HELP1, so it's not that bad).
3) Some words had to be abbreviated, not enough space otherwise.
4) There was no room to add "Next/prev. weapon" for gamepad.

If you can live with these restrictions, I will continue with HELP1 (which won't exactly be easier, but well...). ^^

[And don't bother with the uploaded image, you will get the BMPs once I am done.]

That's looking great! You're going to hate me though, because I have a few suggestions:

- change "FORWARD/BACKWARD" to "FORWARD/BACK", which will give you room to...
- change "GAMEP" to "GAMEPAD"
- change "THMB" to "THUMB"
- change "TRG" to "TRIGGER"
- change "FIRING" to "FIRE" (will give you some room)
- change "OPEN" to "USE" (since you can't "open" a switch)
- change "MARK PLACE" to "MARK SPOT" (consistent with msg in automap)
- change "GAMMA FIX" to "GAMMA CORRECTION" (can wrap below it, consistent with HELP1)
- and you could fit an extra line under weapons if you maybe reduced the 3 gaps above it by a couple of pixels each, so you can put in next/prev weapon control.

Thank you again for your help! :)

You have a keen eye, that's for sure. With a bit of squeezing, I was able to come up with this:



HELP1 will be more difficult since there is even less space, but I'll see what I can do.

NightFright said:

You have a keen eye, that's for sure.

LOL! I was thinking of calling this source port OCD-DOOM...!

Thanks for your awesome work on this! It looks great!
But I just remembered something: the mouse wheel... Could you please change the new next/prev weapon line to:
"MOUSEWHEEL UP/DOWN, GAMEPAD Y/B = PREVIOUS/NEXT WEAPON"
(also reversed the order so previous is before next).

So here are all of them.



Download the BMPs (zipped, 81 KB)

Variations with "MOUSEWHEEL UP/DN" instead of "MWHEEL UP/DOWN" (zipped, 81 KB)

Final notes:
1) Adding the additional weapons controls wasn't possible without abbreviations, but I think it's not a problem.
2) HELP2 is the same like HELP1, just without Plasma Rifle and BFG 9000. That should be good to use for the shareware version.
3) If you prefer a different abbreviation, I have provided alternate versions which print "MOUSEWHEEL UP/DN" instead of "MWHEEL UP/DOWN".

If you're going to be doing sprite mirroring, have you given any consideration to altering the revenant sprites? The fact that they visibly fire both shoulder launchers, but only let one rocket go, was always a nitpick for me. So maybe you could replace the launching sprites with altered ones where only one launcher is firing, and code the attack animation sprites to randomly mirror themselves so the revenant randomly "chooses" which launcher to fire a missile from. Obviously, this would cause compatibility issues with mods that use altered revenant sprites, but I don't think broad compatibility with mods is a priority of this engine anyway.

Hey, just butting my head in here to say this is beautiful looking port. Like, really sexy!

One thing I've noticed, and hopefully this hasn't already been mentioned, is that the client hangs for a significant split-second when the music loops (doom.wad).

You should also consider implementing the stuff from the Doom Sprite Fixing Project btw, if that is possible. ^^

Thank you very, very much NightFright! These look absolutely incredible! Exactly what I want! They will definitely be part of DOOM RETRO's next release (which I'm looking at late January at this stage). I really appreciate all your help with this. Under what name and email address/link do you want to be credited in the release notes?

You should also consider implementing the stuff from the Doom Sprite Fixing Project btw, if that is possible. ^^

They are already in there! All the changes to the sprite offsets from that project (and then further tweaked by me) have been hardcoded into DOOM RETRO. Have a look at the sproffsets[] struct in info.c in the source: most sprites are tweaked in some way. As for alterations to the sprites themselves (such as removing transparent pixels), and the extra frames: they are not in there.

Thanks again!