Doom64 EX 2.0a (Feedback Build) - Updated 3-12-11

I now have a physical copy of Doom 64, if you want me to take shots just throw me the password needed to get to that level and I'll do it.

Kaiser said:

Did some research and found that the N64 is in fact using exponential fog...

Btw, the Mupen64 emulator doesn't even render the fog in Doom64. So much for that :P

I think our wires got crossed; I wasn't suggesting that Mupen64 did handle fog correctly. As can be seen from the code fragment in my earlier post, it is interpreting it as alpha rather than color. I was in fact suggesting that it might be helpful to build a patched version with that change in place. It may be that this is the only issue with the fog in that emulator.

That formula is exactly the same as the one I extracted from the Mupen64 source. Where did you find that documentation? This would seem to validate that it should be affecting the alpha rather than color. Which in turn suggests a fragment combiner that blends src alpha with dest color additively.

I can never successfully compile Mupen64 so I pretty much gave up on that. Though I did took that code mentioned and applied it in a similar fashion to D64ex and I got some positive results.

int min;
int max;
int fogfactor = (1000 - sky->fognear);

    max = 128000 / fogfactor;
    min = ((sky->fognear - 500) * 256) / fogfactor;

    dglFogi(GL_FOG_MODE, GL_EXP);
    dglFogf(GL_FOG_DENSITY, 16.0f / (max + min));

The results are now very comparable to the FPV screenshots on Ledmeister's website.

The documentation is from a missing header file that wasn't included in the SDK when I first got it. That header was probably the most important file as it has a ton of useful information as well as all the macros used to send the commands to the RSP.

Also is it even possible to affect the alpha on the fog? And you also mentioned using texture combiners which means that would involve doing the fog calculations on the texture?

New version is out:
http://dl.dropbox.com/u/18609/Kex_Engine.zip

Bug: Upon death, the red flash from the damage you took doesn't fade.

footman said:

Bug: Upon death, the red flash from the damage you took doesn't fade.

Fixed

Edit: Nevermind, fog's good enough.

Yeah, the N64 hardware has control over the alpha for the fog, which I have no idea how that can be accomplished in OpenGL.

edit: question, does the fog on the N64 get thicker the farther away it is? Or is it a consistent thickness from start of that pillar to the far end of the wall?

New comparison pic:

http://i5.photobucket.com/albums/y181/steel_ph/stuff/Compare3.png

Kaiser said:

question, does the fog on the N64 get thicker the farther away it is? Or is it a consistent thickness from start of that pillar to the far end of the wall?

Ummm, that's a good question. On the map 17 test, the farthest wall sections seem to be "foggiest", as I guess would be expected; but I'm not sure if that means the N64 is necessarily making it thicker.
In N64, I get the illusion that the player is standing in a seemingly-clear(ish) patch, with fog in the distance, kinda like being in the hole of a fog doughnut. As I approach any fog, the clear patch moves with me, so to speak, and fog effect decreases as I approach.
O'course you can get that illusion in real life fog, too, even though it's one consistent thickness...

I dunno, maybe I'm just nuts. Looking at footman's side-by-side in the post above, the distant fog in the left image, and the near fog in the right image (starting just behind/around the nearest pillar), look most like the fog effects I perceive on N64.

So, I think I'll withdraw all fog suggestions, except if the brightness could be tweaked up a tiny bit. You must be pretty darn close, if not on the nose. :)

Kaiser said:

Also is it even possible to affect the alpha on the fog?

In this situation I would be very surprised if the value stored to "alpha" is actually being interpreted as alpha. I would expect that it is merely being used as a means to get another per-vertex variable into the rasterizer in lieu of it being a fixed-function architecture. During raster it is most likely extracted and interpreted as a color delta, with the real alpha either being forced to fully opaque (or set according to per-primitive alpha (if such a thing exists) or other higher-level means).

And you also mentioned using texture combiners which means that would involve doing the fog calculations on the texture?

I deliberately avoided using OpenGL-specific terminology (like texture combiner) because we don't know how these values are being treated by the RSP and consequently, how applicable the fixed-function API in OpenGL is to replicating them.

It may well be that the same results can be achieved using fixed-function API features but until we are sure of the logic I think it would be best to tackle this problem in a fragment shader. Once the combiner logic and blend calculations are known; you can then see whether it can be replicated using fixed-function methods.

Utilizing a fragment shader you are free to experiment without the restrictions and pre-determined logic of the fixed-function API and lighting model.

DaniJ said:

It may well be that the same results can be achieved using fixed-function API features but until we are sure of the logic I think it would be best to tackle this problem in a fragment shader. Once the combiner logic and blend calculations are known; you can then see whether it can be replicated using fixed-function methods.

Utilizing a fragment shader you are free to experiment without the restrictions and pre-determined logic of the fixed-function API and lighting model.

D64ex previously had shader support so I could re-enable that and do some quick tests but the sole reason why I abandoned shaders was because of lack of support on older machines (and ATI cards).

That is certainly a noble cause. I wasn't suggesting that you abandon it *just* for the purposes of emulating fog in release builds.

Yeah I know. I only abandoned it because of lack of support. Sadly ATI still fails to support GLSL properly and in the end it wasn't really worth the effort to keep shader support around.

Odd thing occurred: I continued from a password and when my health dropped below 100, the game made me dead. When I attempted to respawn, it crashed.

Did it produce a crash log? If so, email me that log.

Kaiser said:

Sadly ATI still fails to support GLSL properly

The GLSL shaders in GZDoom do work on ATI but there were a few hoops (example) through which to jump before they did.

Kaiser said:

Yeah I know. I only abandoned it because of lack of support. Sadly ATI still fails to support GLSL properly and in the end it wasn't really worth the effort to keep shader support around.

Correction: ATI does compile GLSL but is anally strict with its syntax and features. If it isn't explicitly part of the spec ATI doesn't do it even when logic dictates that something should be implicit.

So if your shaders don't compile they are not properly written. NVidia is much less strict and accepts code that deviates from the specs.

As of the 3-06-11 build: punching enemies does not seem to play punching sounds (tested on Map01 with the Berserk pack).

New build is out
http://dl.dropbox.com/u/18609/Kex_Engine.zip

Changes:
* Map13 music plays
* Plasma buzz sound no longer affected by echo effects
* Looping sounds properly stopped when exiting levels
* Minor optimizations to renderer

WildWeasel said:

As of the 3-06-11 build: punching enemies does not seem to play punching sounds (tested on Map01 with the Berserk pack).

Just tested this but I am hearing the sound. Anything special you're doing?

Kaiser said:

Just tested this but I am hearing the sound. Anything special you're doing?

I've just tested with the build you just uploaded - still no Punch sounds. My ROM was generated from the 3-06-11 build from Doom 64 (U) (v1.1) [!].z64, verified by GoodN64. And, not sure if this matters, but Music Type is set to Internal.

My sound chip is a Realtek HD Audio, on a Dell Inspiron Mini 10 3G netbook.

Latest build:

When attempting to open a door that you do not have the key for, the beep sound that is supposed to play goes way too quickly and will play indefinitely until you close the game (changing levels or starting a new game wont stop this) In addition, whatever keys you may have, your UI will now show the yellow skull key and a red key card.

For the first moment before this all starts happening, the blue key icon will be showed, but only for about the duration of one beep. (this is when I tried to open the blue door in map01.)

I'm getting the exact same problems as Weasel and Mike.Reiner. I tried punching things with and without a berserk and in different levels but I never heard the punch sound, and I experienced the endless beeping problem after trying to open the blue door in Map 3 without the key. The sound would not go away, not even after loading.

I can confirm the key sound issue, with further info: it only happens when the Status Bar is set to Type 1.

Nice, and with that I found another interesting tid bit.

When set to type 2, if you try to open the blue door, it behaves normally.. however if you type in IDKFA, it will immediately start beeping rapidly and indefinitely.

If you start a new game from a fresh launch, type in IDKFA, then exit to main menu then start a new game again, on type 1 the graphic for the yellow skull key and red key card will be visible, while in type 2 it's the blue and red card keys.

That was fixed last night right after the update on this thread was posted. Try downloading again and give it another try.

Just confirmed that, cool.

While I was testing the punch bug on a build I downloaded this morning (still broken, by the way), I arbitrarily decided to cheat for weapons with IDFA. I triggered this crash when firing the Super Shotgun: http://pastebin.com/2KM8Y9GE

It seems the problem relating to the punch sound is similar to Doom's old bug regarding melee attacks across sectors - except even in the same sector. I've tested using the chainsaw, and the "pulling" effect does not happen, and the chainsaw does not play the "hit" sound, only the normal rev sound.

I wonder if there's some compatibility option I've missed that's not set on by default.

I noticed the chainsaw problem as well. Giving the newest build a go.

Edit:
The fist and chainsaw issue persist. Does having mouse look on and auto aim off make a difference? Those are the settings I'm using currently.

Edit 2:
I can confirm that turning off auto aim is the culprit. With auto aim off, neither the chainsaw nor the first play a sound on contact with an enemy, nor do they "pull" an enemy towards you.