[v1.5] Doom 64: Retribution

Hey guys.

I was able to successfully recreate the Doom 64 style intermission text screens where the text fades in line by line. I did this by using HudMessages and a dummy map where you can't do anything except press use. A camera is used which shows the normal Doom 64 background of the demon artifact.

I used this to my advantage and created a script that is on the wall you are facing that will skip the fading in (like how classic Doom skips the typing on) but the text will stay up. Then you can press use a second time to actually continue and go to the next level. Works great. There's no switch texture on the wall so it doesn't make a sound when used.

I'm about to try to replicate the finale text screen's scrolling text. I think I can do it by doing some sort of loop and incrementing the y coordinate every tic until the last one is out of view.

EDIT: ...aaaand I did it! Easy. Noice.

First trailer posted in OP!

Wow, already? March 31 is still over a month away.

This second go around of polishing the maps is going very well, I keep coming up with new ideas. I also completely re-scripted the blue key puzzle in The Terraformer as well as the crusher. It's now 100% closer to the original. The Terraformer was one of the earlier maps I did so it was the noobiest one. Still not quite happy with the colors on that one, but I can dedicate time later to that one specific task.

Some more stuff...

Originally on Hectic I had made it so you can't cheese any of the traps, however I noticed and remembered something. I believe the green armor was designed to be grabbable from that specific side. The other 3 sides have a different monitor texture, so it's almost as if they were nice enough to at least give you an armor, but you had to realize to grab it from that side.

The Soulsphere however I believe to be an unintentional bug, something the devs didn't catch and the result was you could grab it and be safe while the macro ran and you cheated the level. So I've made the Soulsphere uncheesable but the green armor is grabbable from the right side.

I'm also trying to take co-op play into account during this second go of the maps. For example, in the Terraformer, it would be possible in co-op to completely break the crusher and fuck up the sequence. So... during co-op ONLY, you will die if you try to break it. Once it's done, you can safely pass.

Another example is on Hectic actually, in co-op when a player grabs the blue armor, the camera will not change but you will still get stuck and die, then simply respawn since it's co-op. If I left it like it is in solo play, the one who gets the armor would be permanently stuck in that other camera for the remainder of the level.

Stuff like this I am on the lookout for. Another thing I realized is that older versions of GZDoom are unable to take multiple sector tags into account. This means a level with an important second tag will not have that tag's function ever execute. So this means I am putting the more important sector tag as the first tag and the less important one as the second for more compatibility.

I am still designed it using a recent-ish version, so don't worry. I just want to be able to support as many older versions as possible too with some drawbacks. Another example is pixelratio, GZDoom 2.0.05 does not recognize the property, so versions without that will simply not render 5:5 and will instead be 5:6.

Anyway, enough gabble. Have another screenie. :)


I died right after taking this shot.

What level is that?

MinerOfWorlds said:

What level is that?

Cat and Mouse (25)

Mayhem666 said:

Cat and Mouse (25)

I don't remember that part anyway thanks.

Just to let you know:

Doom64-style colors are now available in GZDoom. Check the specsa/udmf_zdoom.txt file for the property names.

SWEET! Awesome news, thanks for the hard work Graf.

Are they settable through GZDB or is that yet to be added as a setting?

This will immensely improve many maps, especially the tech base ones. I noticed going through them the second time, they are really mundane to the original counterparts due to the lack of color fading and darker top wall shadings.

Graf Zahl said:

Just to let you know:

Doom64-style colors are now available in GZDoom. Check the specsa/udmf_zdoom.txt file for the property names.

Newest update or something?

Congratulations Graf Zahl for having managed what you said as imposible, I see you did it after seeing my video ;)
About the Doom 64: Retribution, I'm really eager to see and play it but now this GZDoom version with Doom 64-style colors exists I couldn't be able to enjoy the project totally because I count on OpenGL 2.x not 3.x as this new GZDoom is requiring now and it may cause some problems with OpenGL 2.x users.
besides it will not stop me to continue with my Doom 64 in GZDoom Special Edition I'm working on using OpenGL 2.x to implement more stuff. I hope new screenshots or a new trailer about your progress, Nevander. :)

Erick194 said:

Congratulations Graf Zahl for having managed what you said as imposible, I see you did it after seeing my video ;)

I never said "impossible". This is after all just setting a few light values. The issue is that getting a proper Doom 64 lighting model with all intricacies and details may be somewhat tricky.

Here's my direct quotes:

Graf Zahl said:

Sure it's possible to add such a feature. If someone could give me the precise specs of how Doom64 does it I could easily add it.

Graf Zahl said:

Ok. This lighting model is not really compatible with the software renderer's lighting mode which GZDoom tries to approximate. I wouldn't try to implement this as Doom64 did, because that's simply too complicated and wouldn't lead anywhere, but specify the different color fields directly as RGB values. But that's still only half the solution. Adding the various color fields is not a problem, what is is to use them properly.

And nothing of that has changed. All I did was add a color value that gets factored in somewhere. It may still take some twiddling and tweaking to get it right.

Graf Zahl said:

I wouldn't try to implement this as Doom64 did

My friend, that sentence makes it imposible, but don't worry. There's no problem, I just commented about my possibilities of my GL hardware.

Guess what: I *DIDN'T* implement is as Doom64 did.

Well, as I said before, there's no problem, but the only thing we could thank you is the GZDoom port which it has given more stuff than any other ports but when I finish my GZDoom version I'm working on, I am very sure everybody can use the new functions for future GZDoom versions.

Fisk said:

The Doom 64 sector format contains 5 lighting fields: ceiling, floor, top-wall, bottom-wall, and thing color. A linedef flag signals the engine to interpolate between top-wall and bottom-wall across the entire height of all sidedefs belonging to that sector. Otherwise, the lower texture is given bottom-wall's color and the same for the upper texture. Ceiling, floor, and thing colors are used directly.

This is probably the cleanest way to do it IMO.

Sorry to bump this old post, but now that I am reading it, I got one question: You say what happens if light doesn't get interpolated for upper and lower textures - but what about the middle one, what is being done with that in the non-interpolation case? I just realized that I forgot that part. Does it just pick one of the other colors, or is there another thing that's being done?

I think Fisk is refering to this:

In middle texture don't use interpolation color.

That picture doesn't tell me much because I don't know if this actually represents how Doom 64 works. I want to reproduce the original effect as closely as I can and need precise specs for that.

I can find out really quick in a map in Builder 64, because I'm curious as well. I don't think there's any spot in vanilla Doom 64 where there's not an interpolated color for a middle texture.


EDIT: By default, middle textures automatically interpolate between top half and bottom half color.

On a per linedef basis, you can check a box to do the following: These will assume a top color of green and bottom color of red.


A. Peg Upper Wall Color - causes top to interpolate green to red on top only, middle texture still interpolates normally green to red, and bottom is completely red.

B. Peg Lower Wall Color - the opposite, causes top to be completely green, middle texture interpolates normally yet again, and the bottom now interpolates green to red on bottom only.

C. Flip Upper Pegged Color - entire top and bottom becomes red, middle texture still interpolates as normal green to red


Combine A and C and top is now red to green instead of green to red, middle texture stays the same, bottom is completely red

Combine A and B and both bottom and top fade green to red as well as middle

Combine B and C and top is completely red and bottom fades green to red, middle texture still normal

Combine A B and C and top interpolates red to green, middle texture green to red, and bottom green to red


In all cases, the middle texture is never not interpolated.

One more question for clarification:

When you say 'interpolates between', does this mean that full red/green are at the top/bottom of the respective texture or the top/bottom of the entire sector?

Let's say flag A was set (Peg Upper Wall Color), the middle texture for example will be green to red but only within the middle texture. The interpolation does not span from top all the way to bottom. The middle texture seems to be getting its own interpolation from the top and bottom colors and does not "join in" the interpolation from top to bottom.

I hope that makes sense, perhaps I can take a quick screenshot.

On the ones where I said completely one color it's probably full red and full green because of how tall the sector I made was, it only appears to be completely red because of the height. The part which is completely red is only full red because it doesn't reach enough height to start reaching the orange/yellow in the middle.

EDIT: Here's a comparative shot of all possible flags:


Imgur converted it to a JPG, so I apologize for that.

As Nevander said, here is an example on video:

Holy crap dude you've got like every D64 feature integrated into GZDB. Are you a wizard? lol

No hehe, I'm not a wizard but I like to do things well.

Thanks for the images.

This looks like you can interpolate an upper and lower linedef both with the gradient going from top to bottom of the texture and top to bottom of the sector.

This will require a bit of added work to the code, because right now it only interpolates from top to bottom of the sector.

I think what I do is the following:

There's 3 color pairs for linedefs per sector: one for upper, one for middle and one for lower - and duplicate all 3 on the sidedef as well - if the sidedef has a valid setting it will override the sector's - and 3 flags on the sidedef that specify which type of interpolation is to be used for the respective tier. If you do not want any interpolation both values must be the same.

A couple folks over on the ZDoom thread suggested keeping the original weapon animation behavior and including it as a toggle option.

I've added the framework and got it all set up, I just need to write the DECORATE states to reflect the cvar. The smoother animations from Cage will be default, but can be changed to "classic" via the D64 Feature Menu that I've added. Luckily the only states that are any different is the fire states (but unfortunately the hardest state to write).

Will there be smooth monsters?

MinerOfWorlds said:

Will there be smooth monsters?

Not unless someone wants to make Smooth Doom 64. I'm a terrible sprite artist so the most likely answer is no (as of now, like I said someone else might try it).

Nevander said:

Not unless someone wants to make Smooth Doom 64. I'm a terrible sprite artist so the most likely answer is no (as of now, like I said someone else might try it).

I think brutal doom 64 has smooth monsters (or at least smoother monsters) you may be able to ask whoever made the sprites if you could use them.

Just a heads up if the maps don't have the right lighting when this first comes out don't worry, the correct lighting and colors will be fixed and updated in due time. With the current situation of Doom 64 lighting in GZDoom, it's not perfect yet and not fully integrated into GZDB. I plan to properly address this and properly apply the correct exact color lighting in the near future when it permits. I may consider it to be the 2.0 version update. Obviously it releases as 1.0 and any bugs or small fixes will make it 1.1, 1.2 and so on. 2.0 will be the first major update which I plan and hope to contain the right lighting effects.