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

Sorry for the late reply, guys. (Back from holiday now.)

For the jittery sprite issue, I've just committed a change which will cause the sprite offsets NOT to be changed if ANY sprite has been merged from a PWAD.

As for blue/green blood issue, I've just committed another change that will only revert to red blood for cacodemons and hell nobles if their actual sprites have been merged from a PWAD, and NOT if a DEHACKED patch is present.

I might also implement settings to allow both these features to be overridden.

bradharding said:

For the jittery sprite issue, I've just committed a change which will cause the sprite offsets NOT to be changed if ANY sprite has been merged from a PWAD.

From the source, does this still happen in the hardcoded instance of BTSX?

Linguica said:

From the source, does this still happen in the hardcoded instance of BTSX?

Yes. BTSX is the exception. Sprite offsets will still be changed.

To respond to your post before you edited it ;) I'll look at less severe alternatives...

I made a simple sprite replacement wad to replace several enemies and items in the game. I used this one http://realm667.com/index.php/en/beastiary-mainmenu-136-69621/doom-style-mainmenu-105-73113/993-forgotten-one to replace the lost soul.

For some reason, the flames for the head are no longer translucent like the stock lost soul. The sprite name is still the same and the colors appear to be the same. Is this a similar issue as the blood color? There is some dehack in the wad, though not related to the lost soul.

Brewtal_Legend said:

I made a simple sprite replacement wad to replace several enemies and items in the game. I used this one http://realm667.com/index.php/en/beastiary-mainmenu-136-69621/doom-style-mainmenu-105-73113/993-forgotten-one to replace the lost soul.

For some reason, the flames for the head are no longer translucent like the stock lost soul. The sprite name is still the same and the colors appear to be the same. Is this a similar issue as the blood color? There is some dehack in the wad, though not related to the lost soul.

Yes, this is due to the DEHACKED lump, so I'll need to make some changes here as well. Thanks. But if a sprite is replaced, the translucency for that sprite would still need to be disabled. This is for wads like BATMAN.WAD, where the sprites are completely different.

bradharding said:

Yes, this is due to the DEHACKED lump, so I'll need to make some changes here as well. Thanks. But if a sprite is replaced, the translucency for that sprite would still need to be disabled. This is for wads like BATMAN.WAD, where the sprites are completely different.

Ok. So, I replaced almost all the projectiles, explosions, and muzzle flashes as well. It wasn't until you mentioned this that I noticed that the translucency was missing from these also. Although, I replaced the barrel explosion as well but it still seems to be translucent.

Maybe you could just add an option in the config file whether or not to disable the translucency when using dehacked?

Or add a dehacked property to make things transparent...

Hi all! I've just uploaded a new version of DOOM RETRO. This is yet another small point release containing the obligatory bug fixes and performance tweaks, but also includes a new (perhaps unique?) graphic effect that may appeal to some.

http://1.bp.blogspot.com/-27GsKoNstMs/VLx6jWqi5VI/AAAAAAAAFBQ/vyyZmtluTis/s1600/liquid.gif

Many thanks go to a few people this time: Platinum Shell, Brewtal_Legend, Krazov, sneakernets, TheLonerD and jeffdoggett. Your help and support is greatly appreciated!
Visit doomretro.com to download DOOM RETRO v1.6.5 and view its release notes.

Changes have been made to how lighting is calculated.

???

edit: oh I checked on Github. You made the zlight[] table much bigger I see.

Linguica said:

???

edit: oh I checked on Github. You made the zlight[] table much bigger I see.

Yes I did! I credited you on Github but forgot to update the release notes. My bad. Your recent insights into the Doom source have been invaluable!

I really like this source port, it adds a lot of really nice touches that graphically enhance the look of the software renderer.

I noticed monster movement is bit different, at least regarding steps and drops that normally block certain monsters due to their size. Is that intentional?

While I hesitate to ask, would it be possible to add the option to bind a mouse button to the run function in a future version?

bradharding said:

[...] a new (perhaps unique?) graphic effect that may appeal to some.

Wow, very cool effect!

But, it's not that unique, though. Doom Legacy had it once, but then unfortunately the effect was dropped from the port:
https://www.youtube.com/watch?v=YTH4r6jt-ZU

Doom Legacy's effect was different. Doom Retro "merely" bobs the apparent surface up and down; Legacy's water effect was in the slight warping effect applied to what is seen through the translucent 3D water block.

A very important difference is that Legacy's effect required the maps to be made specifically for them. Doom Retro's water effect will apply automatically to already existing maps.

bradharding said:

Hi all! I've just uploaded a new version of DOOM RETRO. This is yet another small point release containing the obligatory bug fixes and performance tweaks, but also includes a new (perhaps unique?) graphic effect that may appeal to some.

http://1.bp.blogspot.com/-27GsKoNstMs/VLx6jWqi5VI/AAAAAAAAFBQ/vyyZmtluTis/s1600/liquid.gif

Many thanks go to a few people this time: Platinum Shell, Brewtal_Legend, Krazov, sneakernets, TheLonerD and jeffdoggett. Your help and support is greatly appreciated!
Visit doomretro.com to download DOOM RETRO v1.6.5 and view its release notes.

That's really cool.

Have you had to deal with any edge cases where it would behave oddly in relation to adjacent solid floors with similar heights to the liquid? The logistics are making my head spin, but maybe I'm overthinking it.

Urthar said:

...

I noticed monster movement is bit different, at least regarding steps and drops that normally block certain monsters due to their size. Is that intentional?

While I hesitate to ask, would it be possible to add the option to bind a mouse button to the run function in a future version?

Monster movement uses dropoff code taken from Boom, etc. but maybe there's an issue with the implementation. I'll look into it.

As for a mouse run action: I'll consider it. Thanks!

esselfortium said:

That's really cool.

Have you had to deal with any edge cases where it would behave oddly in relation to adjacent solid floors with similar heights to the liquid? The logistics are making my head spin, but maybe I'm overthinking it.

I have. The liquid needs to be "contained", that is, all adjacent sectors need to be higher, or the same height and also liquid. This is the case for most uses. But liquid sectors at the top of a waterfall won't be animated, for example. Moving sectors complicate things even more.

bradharding said:

The liquid needs to be "contained", that is, all adjacent sectors need to be higher, or the same height and also liquid.

I was checking that one yesterday, and I was chuffed that you considered that. I mean, things like that show that you are a right man for the job.

Looking at this, it seems like the sector is actually moving up and down, but the apparent height of the animated flat isn't moving up and down with it? Is that intentional?

Linguica said:

Looking at this, it seems like the sector is actually moving up and down, but the apparent height of the animated flat isn't moving up and down with it? Is that intentional?

My first approach to implementing this was to apply the change in height to the sector's floorheight, but it caused too many problems with player movement, especially when moving on/off the sector. So I ended up just adding the change just before rendering in R_StoreWallRange(). I'll look at improving this...

Oh, so in essence, it's dynamically clipping the bottom of the lower textures and not really doing anything to the flat rendering at all? Interesting.

I downloaded / compiled the source and made a quick hack to see how it would look to render the flat with the apparent height change.



All I did was subtract frontsector->animate from planeheight in R_MapPlane() in calculating distance and slope. Of course, a real solution would need to look up the sector->animate for the actual sector associated with each visplane, and I didn't know offhand how to find the sector associated with a given visplane, so welp.

Linguica said:

I downloaded / compiled the source and made a quick hack to see how it would look.

All I did was subtract frontsector->animate from planeheight in R_MapPlane() in calculating distance and slope. Of course, a real solution would need to look up the sector->animate for the actual sector associated with each visplane, and I didn't know offhand how to find the sector associated with a given visplane, so welp.

Thanks for this! Coincidentally, I'm actually working on this right now myself, and am looking at the same solution. The sector->animate for each sector is actually the same, based on leveltime, so not entirely necessary to grab that specific for each sector.

I was wondering if it would be possible to make the WAD produced by Blzut3's Master Levels for Doom 2 Patch? I know it's for ZDoom but since the Nerve WAD is compatible with DR it would be nice to have this added too. Is that something you'd consider?

Here's a link for your perusal:

http://maniacsvault.net/projects

:)

Also, from when I was looking at the code:

if (adjacent)
	if (sector->floorheight > adjacent->floorheight
		|| (isliquid[adjacent->floorpic]
		&& sector->floorheight == sector->ceilingheight
		&& adjacent->floorheight != adjacent->ceilingheight))
	contained = false;

This doesn't seem to account for the case when a liquid sector is at the same height as a non-liquid sector, in which case it probably shouldn't be considered as contained?

You guys totally lost me...Linguica: how does your change differ from what bradharding is doing?

Linguica said:

Also, from when I was looking at the code:

if (adjacent)
	if (sector->floorheight > adjacent->floorheight
		|| (isliquid[adjacent->floorpic]
		&& sector->floorheight == sector->ceilingheight
		&& adjacent->floorheight != adjacent->ceilingheight))
	contained = false;

This doesn't seem to account for the case when a liquid sector is at the same height as a non-liquid sector, in which case it probably shouldn't be considered as contained?

Just committed a change to animate the flat texture. Thanks for your help on this.

And you're right. This code doesn't account for that case. I'll look into it.

kb1 said:

You guys totally lost me...Linguica: how does your change differ from what bradharding is doing?

It's difficult to see because the texture is animated, but in my GIF, the apparent height level of the water flat is changing, whereas in the original, the water flat is always at the same apparent height.

Put your mouse cursor over a particular spot of the water in the GIF and you'll see how it moves up / down (or doesn't).

Average said:

I was wondering if it would be possible to make the WAD produced by Blzut3's Master Levels for Doom 2 Patch? I know it's for ZDoom but since the Nerve WAD is compatible with DR it would be nice to have this added too. Is that something you'd consider?

Here's a link for your perusal:

http://maniacsvault.net/projects

:)

Probably not. Not until id Software officially re-release the Master Levels on PC in a combined WAD, such as what was done for "Doom Classic Complete" on the PS3, I think...

The Master Levels aren't particularly good, anyway... :P

Linguica said:

It's difficult to see because the texture is animated, but in my GIF, the apparent height level of the water flat is changing, whereas in the original, the water flat is always at the same apparent height.

Put your mouse cursor over a particular spot of the water in the GIF and you'll see how it moves up / down (or doesn't).

I still don't see it - Do you mean the flat texture itself? (God, I feel like I'm missing something obvious - duh)

kb1 said:

I still don't see it - Do you mean the flat texture itself? (God, I feel like I'm missing something obvious - duh)

Exactly. In the version I released, the flat's actual texture didn't shift in height, only the bottom of the lower textures of the walls surrounding the flat.

Great job Brad - the water effect is awesome.
Overall you've created a pretty cool niche in the Doom universe.