What's new

How to implement "emulate clear". Answer and Question

Gonetz

Plugin Developer (GlideN64)
AFAIK, nobody but Jabo knows how to implement low level framebuffer clears for special effects like flame's corona or the lens flare from the sun in Zelda. Now I will open this little secret for you (be sure you are sitting safe)

In rdp_fillrect
if (rdp.colorimg_addr == rdp.depthimg_addr)
{
fill depthimage area in RDRAM with rdp.fillcolor
return;
}

Thats all! Easy, eh? I was speechless when I found it. It's too obvious. :D

But one problem remains. Depth compare is set off for flame's corona. Corona uses the same texture as for fairy. For fairy depth compare must be set off and it is so, but for corona depth compare must be enabled, otherwise it will be drawn over all objects. I have implemented this clear for Icepir8's plugin to be sure it's not the Glide64 only problem. As you can see on the screenshot, TR64Ogl has the same depth problem. I haven't VC.net to check it with newest plugins, so I ask other plugins authors to check it. May be you haven't this depth problem or you will be able to find good solution. Currently I have added a hack to solve this.

Good luck!

Sceen shot: TR64 OGL 0.7.8 + GF4mx
 

Clements

Active member
Moderator
Excellent work, Gonetz! This is one of those features that Jabo's plugin had that all others did not. It's especially good that this is known now because Emulate Clear solves the camera jumping in Donkey Kong 64, and with the new 1964 on the horizon, we'll have a choice of plugins each equipped with their own emulate clear ready for it. Also, with Zelda being my favourite game, I won't have to rely on Jabo's plugin for good accuracy with the game! :)
 

Tagrineth

Dragony thingy
IIRC the coronas are in fact visible behind walls for a few seconds before disappearing. At least, they were when I was playing Master Quest on my friend's GC the other week.
 

nephalim

Psychic Vampire
Great Gonetz...your plugin is definetely one of, if not the, best. It really needs framebuffer emulation, though. Any plans to implement it?
 

Shin_Gouki

New member
it´s nice to see that you share such ideas with other emu/plugin authors!!
*Gonetzgetsbigcreditsforthisone* :satisfied
wbr Shin Gouki
 

Orkin

d1R3c764 & g1|\|64 m4|<3R
Thanks for sharing Gonetz! You da man! :D

So, if clearing the RDRAM depth buffer is what it takes, then it would appear that the ROM is doing some kind of occlusion culling. It's probably trying to do something like this:

If the corona's center is visible (determined by checking the value in the depth buffer at the corona's location), draw the corona over everthing. If the corona's center isn't visible, don't draw the corona.

If this is the case, the only way to completely emulate it would be to either copy the depth buffer out of video ram (extremely slow), or render polygons to the depth buffer in RDRAM (faster, but not easy to implement)...
 
Last edited:
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
Orkin, may be you are right. But if you are right, it will be hard to emulate. However, the problem with corona can be solved by forcing depth compare for it. The only difficulty is fast detection of corona using. Jabo solved this somehow.
 

decription

New member
Jabo's skill is becoming even more apparent. Have you guys tried to contact him for the answer? Either way it is great to see this problem solved.
 

Orkin

d1R3c764 & g1|\|64 m4|<3R
I was right! The Zelda games do check the depth buffer before drawing coronas and lens flares. How do I know this? I implemented a software depth buffer renderer that draws the depth buffer to RDRAM, and it works properly now! :w00t:

Orkin
 
OP
Gonetz

Gonetz

Plugin Developer (GlideN64)
Orkin said:
I was right! The Zelda games do check the depth buffer before drawing coronas and lens flares. How do I know this? I implemented a software depth buffer renderer that draws the depth buffer to RDRAM, and it works properly now! :w00t:
Orkin
software depth buffer renderer? is it fast enough to be playable? may be it is - you need to do calculations only for 320x240 area, and depth calculation is much simpler then color one. please tell me, which format you have used for RDRAM depth buffer values?
 

Orkin

d1R3c764 & g1|\|64 m4|<3R
Gonetz said:
software depth buffer renderer? is it fast enough to be playable? may be it is - you need to do calculations only for 320x240 area, and depth calculation is much simpler then color one. please tell me, which format you have used for RDRAM depth buffer values?

It does cause a significant slowdown, but not enough to bring it below 60 VI/s on my system. My current renderer also has room for optimization...

The Z format used in RDRAM is described in the N64 Programming Manual in section "15.5 Blender", near the bottom under the heading "Z Image Format". It took reading over it a few times, but I finally got it worked out. The RDP takes 18-bit depth values from the RSP, interpolates them, and then encodes them before writing them to RDRAM. The format it encodes to is sort of a floating point format. Here's the code I wrote to encode the depth value from a float (clamped from 0.0f to 1.0f) to the encoding used in RDRAM:

Code:
    u32 steppedZ = z * 0x3ffff; // Convert to 18-bit

    // Calculate the exponent
    u32 exponent = 0;
    u32 testbit = 1 << 17;
    while ((steppedZ & testbit) && (exp < 7))
    {
        exponent++;
        testbit = 1 << (17 - exp);
    }

    // Calculate the 11-bit mantissa
    u16 mantissa = (steppedZ >> (6 - min( 6, exp ))) & 0x7ff;

    // Encoded Z
    u16 encodedZ = (exp << 11) | mantissa;

I actually ended up making a look-up table for speed, but this is the algorithm I used.

Orkin
 
Last edited:

Cyberman

Moderator
Moderator
So the values are stored in a 32 bit value 64bit size in RDRAM

There might be a more efficient way of converting them especially if you have support for MMX on your machine (most people do). You might be able to convert 2 values at a time (very useful).

Are your FP values single or double precision?
What's the format that's stored in RDRAM?
How often does the depth buffer creation have to happen, onces per frame?

Cyb
 

Top