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

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

Recommended Posts

I have a Logitech F310 gamepad and I already mapped my desired controls to keyboard and mouse with an external program. Is there a way to disable joystick on this port? I'm having a lot of conflicting issues when I try to play with my game pad.

just wanna say I was a little skeptical of this port at first when all the changes like 3/4 gamma correction, desaturated pallete, brightmaps, and blood splatters were on by default. I think in time I'll grow to like it though :)

Share this post


Link to post

Hey Brad, I actually do have it set to leftshoulder and rightshoulder. I'm not sure where the conflict lies... I'll try a new cfg file and see if that helps.

I'm glad I'm not irritating you with all my requests. I can imagine how it could get annoying with all the "can I, can I, can I..." posts that I've made! Regardless, of what you've implemented (or not!) it's still my go-to 'vanilla' port. I can't tell you how much I love the controller and rumble support. My poor wrist injury is very thankful for your work! :)

EDIT: Possible bug. If I load DR with the -nosound flag the game crashes at the title screen. Does DR even use such a flag and I'm just being stupid?!

Share this post


Link to post
40oz said:

I have a Logitech F310 gamepad and I already mapped my desired controls to keyboard and mouse with an external program. Is there a way to disable joystick on this port? I'm having a lot of conflicting issues when I try to play with my game pad.

Actually, no. There's no option to disable gamepads. I didn't consider this situation. I'll implement a "-nogamepad" cmdline option then.

just wanna say I was a little skeptical of this port at first when all the changes like 3/4 gamma correction, desaturated pallete, brightmaps, and blood splatters were on by default. I think in time I'll grow to like it though :)

If all those features were off by default, then DR would be just like every other source port! :P

Average said:

Hey Brad, I actually do have it set to leftshoulder and rightshoulder. I'm not sure where the conflict lies... I'll try a new cfg file and see if that helps.

Hmm... I'll look into it more at this end as well. Thanks.

I'm glad I'm not irritating you with all my requests. I can imagine how it could get annoying with all the "can I, can I, can I..." posts that I've made! Regardless, of what you've implemented (or not!) it's still my go-to 'vanilla' port. I can't tell you how much I love the controller and rumble support. My poor wrist injury is very thankful for your work! :)

I'm glad you like it. I'm very happy with how it's turned out.

EDIT: Possible bug. If I load DR with the -nosound flag the game crashes at the title screen. Does DR even use such a flag and I'm just being stupid?!

Thanks for this. There is such a cmdline option, and it certainly shouldn't cause a crash.

Share this post


Link to post

That map uses ZDBSP extended nodes, which probably aren't supported in Doom Retro. (Nor Crispy Doom.)

There are also some other weird things in this wad that mean it probably won't work properly outside of PrBoom+ or ZDoom. (Non power-of-two texture widths, spaces in lump names?, ogg music, etc.)

Share this post


Link to post
VGA said:

Can you please try this wad out?
http://www.doomworld.com/vb/wads-mods/60775-5till-l1-complex/

It stops with a blockmap error for me.


Looks like a nice wad to play, but yes, as plums said... it uses ZDBSP extended nodes, which are beyond Doom Retro's level of support (I'll be getting BOOM compatibility in before I consider supporting ZDoom's stuff - if at all). I guess the statement that this one requires a "limit removing" source port is wrong.

Share this post


Link to post

Well, PrBoom+ and Eternity support ZDBSP extended nodes, and I think 3DGE can handle maps like that because it rebuilds its own nodes anyhow. So it's not exactly a ZDoom-specific feature/mapset. But it's definitely not a wad that's meant to play in any limit-removing port, and I can see not wanting to support such large maps as a priority, if at all.

Share this post


Link to post

Hey Brad, I'm not sure if this is a bug in DR itself or if it's just a by-product of some of your changes but I thought I'd mention it here first before reporting it in the BTSX Episode 2 thread.

I've noticed that in that WAD some of the torches kind of jitter a pixel or two left and right. It's really noticeable at the very beginning of map 2. I'm not sure but I think some of the Cacodaemons were jittery too. That might just be me though as it was late and I was very tired! Anyway, thought I'd mention it. :)

PS: I'm using the latest release of DR.

Share this post


Link to post
Average said:

Hey Brad, I'm not sure if this is a bug in DR itself or if it's just a by-product of some of your changes but I thought I'd mention it here first before reporting it in the BTSX Episode 2 thread.

I've noticed that in that WAD some of the torches kind of jitter a pixel or two left and right. It's really noticeable at the very beginning of map 2. I'm not sure but I think some of the Cacodaemons were jittery too. That might just be me though as it was late and I was very tired! Anyway, thought I'd mention it. :)

PS: I'm using the latest release of DR.


Hi. Thanks for the report! DOOM RETRO's at fault, not BTSX.It's because DOOM RETRO uses custom sprite offsets to make animations smoother, and position things better. If a sprite is present in a PWAD, it checks its size, and if its different to the size of the one in the IWAD, the offsets won't be applied. Seems that in this case the offsets are applied to one frame of the torch but not the other. I've noticed this in E1 of BTSX as well and have fixed the issue, which you'll see in the next release.

Share this post


Link to post

Sorry for the double post but I've another request though I may have asked for it in the past (sorry if I have!).

Is it remotely possible to add fullbrights to the monsters' eyes? I use the sbrightmaps.pk3 with GZDoom and the coolest thing from that whole pack is the glowing eyes coming out of the dark. I'd love to see that effect in DR too. :)

Share this post


Link to post
Average said:

Sorry for the double post but I've another request though I may have asked for it in the past (sorry if I have!).

Is it remotely possible to add fullbrights to the monsters' eyes? I use the sbrightmaps.pk3 with GZDoom and the coolest thing from that whole pack is the glowing eyes coming out of the dark. I'd love to see that effect in DR too. :)


It has been suggested before, but I don't think it was you (fraggle, if I recall). I have quickly experimented with this, and I'm not quite sure it looks any good. I had imp eyes fullbright, and it looked a bit crap. I'll have to get around to checking sbrightmaps.pk3 with GZDoom, as you mentioned, to see how it looks with that. Thanks.

Share this post


Link to post

Maybe their eyes could go fullbright only for a couple of seconds when they "wake up" and their angry sound plays. Could be a nice surprise in a dark room.

Or maybe their eyes could be a little brighter than normal when in a low-light sector.

Share this post


Link to post

Hi all!
Just a quick message to let you all know that the next version of DOOM RETRO, v1.6, is progressing nicely, and should see the light of day before the end of this month.

That said, I'm wondering if someone can please help me, because for the life of me, I can't work out how to do this, and it's driving me crazy!! All I'm trying to do is effectively "squash" (vertically scale) a sprite to a portion of its original size. Should be simple, a bit of math in R_ProjectSprite() or R_DrawVisSprite() in r_things.c...

Share this post


Link to post

A basic algorithm for minification of a R8G8B8(A8) sequence of pixel data in one dimension is as follows (taken from Doomsday). Parameters should be fairly self-explanatory:

static void scaleLine(uint8_t const *in, int inStride, uint8_t *out,
int outStride, int outLen, int inLen, int comps)
{
    float inToOutScale = outLen / (float) inLen;
    int i, c;

    // Minification needs to calculate the average of each of
    // the pixels contained by the out pixel.
    uint cumul[4] = { 0, 0, 0, 0 }, count = 0;
    int outpos = 0;

    for(i = 0; i < inLen; ++i, in += inStride)
    {
        if((int) (i * inToOutScale) != outpos)
        {
            outpos = (int) (i * inToOutScale);

            for(c = 0; c < comps; ++c)
            {
                out[c] = (uint8_t)(cumul[c] / count);
                cumul[c] = 0;
            }
            count = 0;
            out += outStride;
        }
        for(c = 0; c < comps; ++c)
            cumul[c] += in[c];
        count++;
    }
    // Fill in the last pixel, too.
    if(count)
    {
        for(c = 0; c < comps; ++c)
            out[c] = (uint8_t)(cumul[c] / count);
    }
}
Naturally because you are working within the DOOM palette you'll need to convert the paletted data, scale and then re-palettize. Obviously this will be quite a hit on performance so you'll want to do it offline rather than at draw time.

Edit: Alternatively, you could use a nearest-neighbour algorithm and continue to work within the DOOM palette. That approach should be fast enough to do at draw time in a software renderer (though I can't say whether it will look any good).

Share this post


Link to post
DaniJ said:

A basic algorithm for minification of a R8G8B8(A8) sequence of pixel data in one dimension is as follows (taken from Doomsday). Parameters should be fairly self-explanatory:
....


Wasn't quite what I was after, but thank you! To be more specific with what I'm trying to do is squash a sprite to 10% of its original height to use as a shadow. It would be a simple "pixel resize", so no blending of pixels since it will all be black, effectively just skip 90% of the sprite. I was thinking simply playing with one of the scale values or projectiony in r_things.c would help, but I'm stumped.

Share this post


Link to post

Ah, I see. For that specific case then its most certainly efficient enough to do it at draw time, given you don't need to worry about blending color values (all you care about is whether its masked or not and thus whether its shadow or not). I have zero experience with the software renderer so, I can't offer any help with that. Good luck!

Share this post


Link to post

Glad to hear the next release is fairly imminent. Gutted that the glowing eyes had to be cut though. :(

Still, can't wait to see the shadow effects. :)

Share this post


Link to post

I've played it a little bit, and I have a few things to say.

Additive transparency doesn't work very well with stock muzzle flashes. Many guns look weird, plasmagun is abysmal.

Not sure I like new weapon bobbing.

I think you should expand options. Especially with contols. Preferably with the ability to set mouse wheel.

Share this post


Link to post
Da Werecat said:

Additive transparency doesn't work very well with stock muzzle flashes. Many guns look weird, plasmagun is abysmal.

Yeah, unfortunately working with only a 256 color palette can give less than ideal results in some instances. I'm continuing to work on how I can improve this.

Not sure I like new weapon bobbing.

The bobbing now appears as it does in the XBLA and BFG edition of DOOM/DOOM II. It can be changed back to what it was by changing the "playerbob" setting in doomretro.cfg from "75%" to "100%".

I think you should expand options. Especially with contols. Preferably with the ability to set mouse wheel.

One of the goals of DOOM RETRO is to keep the interface as clean and as similar to Vanilla DOOM as possible, so all additional options are in doomretro.cfg. What options would you like present? Also, what would you bind to the mouse wheel?

Share this post


Link to post
bradharding said:

Yeah, unfortunately working with only a 256 color palette can give less than ideal results in some instances. I'm continuing to work on how I can improve this.

Palette is unrelated. The problem is in the way additive transparency works. Actually, the plasmagun's muzzle flash would look bad even with regular transparency, because it animates the whole weapon (while the idle sprite is still underneath it).

The bobbing now appears as it does in the XBLA and BFG edition of DOOM/DOOM II. It can be changed back to what it was by changing the "playerbob" setting in doomretro.cfg from "75%" to "100%".

Tried that. It appears that the weapon moves differently in some way. But it's not a big deal.

What options would you like present?

Key bindings. Maybe resolution.

Also, what would you bind to the mouse wheel?

Weapon switching, just like it is now. But it would be nice to have the ability to invert it, at the very least.

Share this post


Link to post

In anticipation of New Hallows’ Eve, I’m proud to finally announce the release of version 1.6 of DOOM RETRO. This iteration sees many, many new features, including dynamic shadows, the clipping of sprites in liquid, and DeHacked support. You may download it doomretro.com]here.

Share this post


Link to post

The dynamic shadows are pretty cool, I also dig the way the background behavior when you open the menu, that looks pretty awesome.

The inverted sprites for dead enemies is also a nice touch.

I know it has been discussed a bit already, but I echo the sentiments that 100% bobbing is not the same as the standard bobbing found in most other engines and vanilla.

Neat engine, I'll play the next couple compatible wads I want to run through with it.

Share this post


Link to post

Haha, nice, when I have more time I'll play more so I can see how the shadows of the bigger enemies look like :-)

Share this post


Link to post
VGA said:

Haha, nice, when I have more time I'll play more so I can see how the shadows of the bigger enemies look like :-)

Mike.Reiner said:

The dynamic shadows are pretty cool, I also dig the way the background behavior when you open the menu, that looks pretty awesome.

The inverted sprites for dead enemies is also a nice touch.

I know it has been discussed a bit already, but I echo the sentiments that 100% bobbing is not the same as the standard bobbing found in most other engines and vanilla.

Neat engine, I'll play the next couple compatible wads I want to run through with it.


Glad you both like it!

With the bobbing, I can't personally tell the difference, but I'll definitely look into it...

Share this post


Link to post

The amount of kills is now correctly capped at 100% on the intermission screen in all instances.

Here's a suggestion: remove the MF_COUNTKILL flag from monsters that are spawned by A_A_PainShootSkull, A_VileChase, P_NightmareRespawn, and A_SpawnFly

E.g. for A_PainShootSkull at the end:

    newmobj = P_SpawnMobj (x , y, z, MT_SKULL);

    // Check for movements.
    if (!P_TryMove (newmobj, newmobj->x, newmobj->y))
    {
	// kill it immediately
	P_DamageMobj (newmobj,actor,actor,10000);	
	return;
    }
		
    newmobj->target = actor->target;
    newmobj->flags &= ~MF_COUNTKILL;
    A_SkullAttack (newmobj);
}
For P_NightmareRespawn:
    // inherit attributes from deceased one
    mo = P_SpawnMobj (x,y,z, mobj->type);
    mo->spawnpoint = mobj->spawnpoint;	
    mo->angle = ANG45 * (mthing->angle/45);
    mo->flags &= ~MF_COUNTKILL;

    if (mthing->options & MTF_AMBUSH)
	mo->flags |= MF_AMBUSH;
A_SpawnFly:
    newmobj	= P_SpawnMobj (targ->x, targ->y, targ->z, type);
    newmobj->flags &= ~MF_COUNTKILL;
    if (P_LookForPlayers (newmobj, true) )
	P_SetMobjState (newmobj, newmobj->info->seestate);

And in VileChase:
		    corpsehit->flags = info->flags & ~MF_COUNTKILL;
		    corpsehit->health = info->spawnhealth;
		    corpsehit->target = NULL;
Why do that? This way, all monsters placed on the map directly will count as monsters, but those added during the game by spawning or respawning will not. If you want to prevent going over 100%, this is the best approach IMO. You can even give the lost souls their COUNTKILL flag back safely.

Share this post


Link to post
Gez said:

Here's a suggestion: remove the MF_COUNTKILL flag from monsters that are spawned by A_A_PainShootSkull, A_VileChase, P_NightmareRespawn, and A_SpawnFly
...


Thanks Gez. You're right: this would be easier. I think I originally cobbled together this change very early on in DR's development, and then tweaked it recently without giving it any further thought. I'll look at implementing your suggestion shortly.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×