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

[v1.5] Doom 64: Retribution

Recommended Posts

That's weird, I remember how the Absolution mod would do that, there would be random popping sounds. I've encountered this while video editing as well, but not in every instance. I think there may be a software problem causing this?

Share this post


Link to post
Graf Zahl said:

I can't say more without having seen the sound file, but such 'popping' effects normally happen when a sound doesn't start or end with 0-amplitude.

The sounds start and end at 0 or close but the problem is if it's currently playing the sound at let's say 3 amplitude, another starts at 0 which causes a sudden shift from 3 down to 0. That causes an audible pop. Could this be resolved via limiting the sound effect via SNDINFO? I say this because I have set the limit to 0. Perhaps this is the problem? I will do some tests.

EDIT: Limiting to 1 like the default SNDINFO didn't change anything. How do Doom format sounds differ from FLAC? Is there a way to convert FLAC to Doom format and keep them sounding as they do prior to conversion?

GoatLord said:

That's weird, I remember how the Absolution mod would do that, there would be random popping sounds. I've encountered this while video editing as well, but not in every instance. I think there may be a software problem causing this?

I doubt that there's any sort of software related problem, since EX doesn't have the problem. All the sounds are in MIDI format, which means there are no wavelengths.

Share this post


Link to post
Nevander said:

The sounds start and end at 0 or close but the problem is if it's currently playing the sound at let's say 3 amplitude, another starts at 0 which causes a sudden shift from 3 down to 0. That causes an audible pop. Could this be resolved via limiting the sound effect via SNDINFO? I say this because I have set the limit to 0. Perhaps this is the problem? I will do some tests.


Normally a well written sound engine won't let that happen or you'd get pops all over the place. Are you using FMod or OpenAL?

Share this post


Link to post

FMod, all default settings. Just now I tried Ancient Aliens and spawned a ton of health bonuses in a row and could still hear some form of popping although it was MUCH less pronounced. Classic Doom with no mods I felt like was also doing it, but could hardly tell.

It seems that the sounds themselves are at fault because I can't replicate it nearly as good as the Doom 64 sounds do.

Try this example WAD, it has only the Doom 64 item pickup sound (in FLAC format). Go to the room in MAP01 of Doom 2 where the health bonuses are, you can hear the pops clear as day (or at least I can). This is with no other mods or files loaded. SNDINFO is unmodified.

http://www.mediafire.com/file/rb3lc5z34edk33z/soundtest.wad

I'm curious to see if you can hear it too, or maybe I'm going nuts. I could stand it at first, but now I hear the pops every time I pick up two items within a second of one another. I'm pretty sure this problem is because of sudden wavelength shifts. The MIDI sound effects that EX uses has 0 popping. That at least tells me it's not my sound that's screwing up.

EDIT: Fiddled around with all the sound settings and tried them all one at a time, no good. Nothing changed it. Tried both FMod and OpenAL backends, they both did it. FMod had clearer sound though.

Share this post


Link to post

Out of curiosity, I know there was a Doom 64 TC that required a different engine. Why is it that the Doom64 wads can't be used out of the box in GZDOOM currently?

Share this post


Link to post
enderandrew said:

Out of curiosity, I know there was a Doom 64 TC that required a different engine. Why is it that the Doom64 wads can't be used out of the box in GZDOOM currently?

Well, Kaiser made two PC ports of Doom 64.

The first one, the Absolution TC, used a modified version of something called the Doomsday Engine, that uses its own features and implementations that GZDoom is not compatible with. Not to mention, it wasn't very accurate, it was just a loose approximation of Doom 64's content. The second one was called Doom 64 EX, and instead of being a TC, it was an actual port of the game, with 100% accuracy. This one uses a totally custom engine that is even less compatible with GZDoom than the Absolution TC is.

The TC generally used PC formats for stuff like maps, EX uses its own map format and even stores sound effects and music in a completely different format. Scripting also uses a unique format. GZDoom is perfectly capable of replicating Doom 64 with near 100% accuracy (especially if Graf implements gradient lighting in UDMF), but for the reasons mentioned above, it has to be converted first by hand.

Share this post


Link to post
Blastfrog said:

Well, Kaiser made two PC ports of Doom 64.

The first one, the Absolution TC, used a modified version of something called the Doomsday Engine, that uses its own features and implementations that GZDoom is not compatible with. Not to mention, it wasn't very accurate, it was just a loose approximation of Doom 64's content. The second one was called Doom 64 EX, and instead of being a TC, it was an actual port of the game, with 100% accuracy. This one uses a totally custom engine that is even less compatible with GZDoom than the Absolution TC is.

The TC generally used PC formats for stuff like maps, EX uses its own map format and even stores sound effects and music in a completely different format. Scripting also uses a unique format. GZDoom is perfectly capable of replicating Doom 64 with near 100% accuracy (especially if Graf implements gradient lighting in UDMF), but for the reasons mentioned above, it has to be converted first by hand.

Given that Doom 64 is an official Doom Classic game and a direct continuation, wouldn't it make sense to an extent to add support to GZDoom to read those formats? I presume that is what EX did.

Share this post


Link to post
enderandrew said:

Given that Doom 64 is an official Doom Classic game and a direct continuation, wouldn't it make sense to an extent to add support to GZDoom to read those formats? I presume that is what EX did.

There's a lot more to it than just reading different formats, there's a lot of differences in how the engine actually worked. One such example being how the false 3D areas worked, it relied on a rendering quirk that GZDoom does not have.

That being said, I suppose actual support for the EX IWAD would be interesting and I would welcome it, though it would definitely not be trivial to do.

Share this post


Link to post
Blastfrog said:

GZDoom is perfectly capable of replicating Doom 64 with near 100% accuracy (especially if Graf implements gradient lighting in UDMF), but for the reasons mentioned above, it has to be converted first by hand.

I would love to see gradient colored lighting in GZDoom. I have to wonder if such a feat is possible. There's already a perfect place to implement the options. The sidedefs tab could control the color of the top and bottom of the sidedefs, and the floor/ceiling would control those colors. The sector properties color setting would control the color of things present inside the sector.

Really, this is the only thing GZDoom needs to be able to accurately reproduce Doom 64's lighting. Glowing flats is possible, and it produces the effect we need. All we need now is to be able to apply a glow anywhere in a map directly using UDMF.

enderandrew said:

add support to GZDoom to read those formats?

You can't simply read formats that were designed for an entirely different engine. The only way to expect newer formats to be readable in older engines is through conversion, which unfortunately must be done manually by hand. This is what must be done to even make a map loadable.

Trying to run a Doom 64 map by dragging the WAD onto GZDoom results in the engine exploding. It's like trying to put a disc into a Nintendo 64. It can't be done. You'd have to convert ALL the disc's resources into formats readable by the Nintendo 64 and then put them into a cartridge. Possible, but the end product won't be pretty. The only thing you can do is convert everything into a readable format that still looks decent, which means modifying a lot of stuff to recreate the original's presentation in the best way that the older engine will allow.

Even though GZDoom is a modern source port of classic Doom, the engine is still older than Doom 64's and thus the formats are entirely different. I don't believe that GZDoom will ever be capable of directly reading and running DOOM64.WAD. That's why EX was made. A custom engine made to read those formats.

Blastfrog said:

One such example being how the false 3D areas worked, it relied on a rendering quirk that GZDoom does not have.

The guys at Midway basically got smart and realized they could create some cool looking geometry if they changed the way the engine rendered the map and instead made it so anything behind walls that have a sky flat as the ceiling gets rendered through it. The actual geometry is no different than original Doom format. The only thing is, to recreate this effect, you MUST use 3D floors. There's just no other way.

Unfortunately not every area in the original maps are set up to easily replace these spots with a 3D floor. Some require additional modification so that the sky can show up where needed but also allow a 3D floor to be placed. This has even meant changing entire areas into 3D floors, one such example being the outer walkway on Altar of Pain.

Share this post


Link to post
Nevander said:

You can't simply read formats that were designed for an entirely different engine. The only way to expect newer formats to be readable in older engines is through conversion, which unfortunately must be done manually by hand. This is what must be done to even make a map loadable.

That isn't entirely true. It is possible to add code to an engine to read new file formats that it didn't support before. Heck, 3D model support in GZDoom is one such example.

Support for additional IWADs games that didn't exist before is another such example.

Devs could decide that the work isn't worth the effort, but the existing EX engine does provide a framework how to import the Doom64.wad. That work could be adapted to other engines.

Share this post


Link to post
Guest DILDOMASTER666
Nevander said:

I would love to see gradient colored lighting in GZDoom. I have to wonder if such a feat is possible. There's already a perfect place to implement the options. The sidedefs tab could control the color of the top and bottom of the sidedefs, and the floor/ceiling would control those colors. The sector properties color setting would control the color of things present inside the sector.


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.

Share this post


Link to post

EDIT: Nevermind, found them here.

-----------

Has anyone already decompiled all the Doom 64 macros? I'm having trouble with Pitfalls, trying to figure out exactly which sectors move when and by how much and I've just now decompiled the macros for that level so I can see which sectors tagged what move and when.

I may need the decompiled macros for other levels if something is wrong or just to ensure accuracy in general. It would save me some time if I didn't have to extract all the MACROS lumps for each map and decompile them one at a time.

Share this post


Link to post

Ask Kaiser, he has them all decompiled already. In fact, talk to Kaiser in general for any questions you may have, he knows Doom 64 inside and out.

Share this post


Link to post
Nevander said:

I would love to see gradient colored lighting in GZDoom. I have to wonder if such a feat is possible. There's already a perfect place to implement the options. The sidedefs tab could control the color of the top and bottom of the sidedefs, and the floor/ceiling would control those colors. The sector properties color setting would control the color of things present inside the sector.


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.

Share this post


Link to post

For me, the ability to do the same thing GLDEFS Glows currently do, but using UDMF properties would do (this would require 4 additional properties: glow color and height for floor and ceiling).
Also it would be nice to have "Modulate" style glows, so things like deep pits with wall brightness gradually fading to black would be easy to make (IIRC, GLOOME did this with "fullblack" GLDEFS glow texture definition flag).

Share this post


Link to post

The only thing about glows is that I noticed they don't appear very well or at all when a sector's brightness is 255, whereas sector colors will be green/red/blue whatever no matter the light level. They will only get lighter/darker.

EDIT: And unrelated to glows, the way middle sidedef textures move with the ceiling is super annoying. Doom 64 can move sectors without affecting sidedef movement... so I have to draw really thin sectors against the walls that move to stop the textures from moving. Would it be possible for a "Don't move textures with sector movements" flag in UDMF? Or is that not possible with the engine?

Share this post


Link to post

Using the existing glow feature is a bad idea. It would be far more accurate to Doom 64 if you could blend between two colors, instead of adding/subtracting from just one color.

Share this post


Link to post

Correct. So, what light information does Doom64's map format contain? Doomwiki's pages about sectors and lines do not contain any Doom64 info, unfortunately.

Share this post


Link to post

The only information I can find is from the tech bible that Kaiser wrote on Doom 64's engine, section 12.5 on page 39.

Lighting is the biggest stand-out feature in Doom 64. The lighting system is what gives off horrific atmosphere and ambiance and can be used in all sorts of ways. The lighting data is edited through the level editing tool and is implemented by the level designer. The RGB data is then stored in a table in the level's LIGHTS lump. The table has 255 pre-set RGB values, all gray scaled. These values range from 0, 0, 0 to 255, 255, 255. Following that is the actual RGB data set by the level designer.

In the rendering engine, the colored lighting is computed in this following timeline:
• Compile table of light RGB values
• Set the overall light factor (game brightness setting + player's infrared powerup)
- Compute the H, S, V values
- Clamp the luminosity
- Compute the R, G, B values
• Update light table from light factor

Each sector can store up to 5 different RGB values which are used to determine the color for the ceiling, floor, thing and walls. Walls can have two RGB values which affects the top and lower portions of the wall.


The LIGHTS lump says it's an "RGB table containing colored lighting data."

Even then, this doesn't explain much. Basically just tells us what we already know. The best bet is to ask Kaiser about this, maybe find a way to get the source code to it out there since I can't seem to find it. I don't think he's released it yet.

EDIT: I found this. https://github.com/svkaiser/Doom64EX
Dotfloat is working on EX now, and this looks like the source

Some helpful stuff might be here
https://github.com/svkaiser/Doom64EX/blob/master/src/engine/renderer/r_lights.cc

Like I've said before, engines aren't my specialty so I wouldn't know the first thing to look for but this is all I can find on the subject. Probably won't help. :(

Share this post


Link to post

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.

Share this post


Link to post

Hey there! This is a modified GZDoom version 1.8.10 , not finished, though (prototype). I'm currently working on with the new GZDoom version 2.2.0 to see if it is posiible to add everything you will see in this video. This is for our future planned Doom 64 EX conversion for GZDoom using UDMF format.

Share this post


Link to post

What and how? I see pure gold potential in that video.

But I have to also ask...

"This is for our future planned Doom 64 EX conversion for GZDoom using UDMF format."

Who is our?

Share this post


Link to post
Impboy4 said:

Erick194 and his brother Gerardo194

So they are doing the same thing I am, but have a custom GZDoom capable of doing Doom 64's lighting system?

These changes to GZDoom's engine need to be made public so they can be used in GZDoom by default! Like I said, I see stuff in that video that can lead to really cool stuff, not just for a Doom 64 remake but for future maps and projects that want to reproduce Doom 64's style and lighting system.

Share this post


Link to post

Just a question: Why the need to convert the Doom 64 levels to GZDoom? In the case of the PlayStation Doom TC, I understand the conversion provided the possibility of playing the PS version on PC with high resolution and mouse/keyboard support. But in the case of Doom 64, aren't those features already present in Doom64 EX? From what I gather, the Doom 64 engine is different enough from the Doom engine. Is there a real necessity to convert the maps and "adapt" the Doom 64 engine features into GZDoom? Doom 93 and Doom 64 are, after all, different games. Wouldn't it be better to just use Doom 64 EX, or add "true" Doom64 support to GZDoom?

This is not to criticize your project (hope it goes well), just legitimately curious.

Share this post


Link to post
mattjoes said:

Just a question: Why the need to convert the Doom 64 levels to GZDoom? In the case of the PlayStation Doom TC, I understand the conversion provided the possibility of playing the PS version on PC with high resolution and mouse/keyboard support. But in the case of Doom 64, aren't those features already present in Doom64 EX? From what I gather, the Doom 64 engine is different enough from the Doom engine. Is there a real necessity to convert the maps and "adapt" the Doom 64 engine features into GZDoom? Doom 93 and Doom 64 are, after all, different games. Wouldn't it be better to just use Doom 64 EX, or add "true" Doom64 support to GZDoom?

This is not to criticize your project (hope it goes well), just legitimately curious.

This is just my two cents:

1. Doom64EX has limited Linux support and no Mac builds.
2. GZDoom has a slew of other features.
3. GZDoom has tons of other gameplay mods you could in theory combine with Doom 64.
4. Trying to make new mods from scratch in Doom 64 EX requires learning Angel Script.
5. GZDoom is dead sexy.

Just as some people prefer to run Chocolate Doom to have the most accurate experience of vanilla, I'm sure there is an audience who will always prefer a dedicated Doom 64 engine that aims to be 100% accurate, but I'd personally prefer one engine that allows me to easily and quickly play all the games as possible (and better yet, make them look good while I do it).

Choice is a good thing.

Share this post


Link to post

Basically what enderandrew said, but one more and very important point is that all previous attempts at bringing Doom 64 to GZDoom have been quite messy and poorly made. No offense to the creators, but they are.

Brutal Doom 64 so far has done the best job. The other one (which BD64 was based off of) called GZDoom64 was basically ripped straight from the Absolution TC since it was already made to run on a classic Doom type engine, that being Doomsday.

This project is a fresh remake of Doom 64 for GZDoom, with no prior base being used apart from the monsters and weapons and stuff. Even then, it's been heavily modified so far to be closer to Doom 64 and also better in general. The base for this was Doom 64 WMI. You can find it by googling that exact name and the first YouTube video result is it.

This was the most accurate base I could have started with, most of the hard work already being done.

The maps are all being done fresh from the source, Doom 64's map WADs.

Share this post


Link to post

So, there's different people working on different Doom64 ports?
Wouldn't it make sense to join forces and also see the necessary engine adjustments being made public?

It looks like a lot of energy is being wasted here by doing some redundant work.

Share this post


Link to post
Graf Zahl said:

and also see the necessary engine adjustments being made public?

I hope it does, because that will make any and all project that wishes to use gradient lighting look infinitely better. Keeping something like that closed source will anger many, especially since there's a video now clearly showing it as a reality.

I also see additive glowing strobe lights, which my project is also lacking.

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
×