about: emulating "Hardware Frabe Buffers (Effects) Emulation" in a Glide3 Wrapper.


Zeckensack is the author of a well known Glide wrapper:

http://www.zeckensack.de/glide/


this is related to Nintendo64 emulators (especially video pluging):
HWFBE allows plugin to use video memory for auxiliary frame buffers. This greatly speed ups frame buffer emulation and improves image quality. Frame buffer effects like motion blur now work as smooth as on real console and in high resolution. This feature also allowed me to emulate many things which are hardly possible to emulate with usual frame buffer emulation, e.g. dynamic shadows. HWFBE is fully supported only by Voodoo4/5 and partially by Voodoo3 and Banshee.


Zeckensack's post (asking for help):

The readme just says that HWFBE requires an extension. It doesn't say which one. Likely candidates (grabbed from a Voodoo 3's extension list) are TEXTUREBUFFER, SURFACE and TEXUMA.
Unfortunately none of these is described in the Glide3 SDK docs I have lying around. SURFACE is mentioned briefly, to the extent that I know I won't be able to implement it (it deals with DirectDraw surfaces).
I have full docs for CHROMARANGE, TEXCHROMA, TEXMIRROR, FOGCOORD and PALETTE6666. What the others are supposed to do, I can only guess.

edit:
Found it in the Glide64 sources. It's TEXTUREBUFFER. However, I still don't understand exactly what this extension is supposed to do.

Theory as follows:
grTextureBufferEXT specifies a region in texture memory (w the usual small_lod, large_lod, aspect_ratio and format arguments) as the current render target. Rendering commands now write into this space instead of the frame buffer.
To "turn it off" one calls grRenderBuffer.
Correct?


ggab says: does anybody know something about this? i'll apreciate it a lot :-)

a Hacktarux's tip

(from official thread http://forums.emuxhaven.net/showthread.php?t=5275&page=2)

GrRenderBuffer selects the render buffer and one of the possible options when TEXTUREBUFFER extension is available is to select a texture. The caracteristics and location in texture memory of this texture are defined by grTextureBufferEXT.

more tips are welcome

this story goes on......

this is a Zeckensack's post (again, from the original topic):

Next theory about the TEXTUREBUFFER extension:

grRenderBuffer(GR_BUFFER_TEXTUREBUFFER_EXT) selects texture memory as the render target.
grTextureBufferExt selects where in texture memory this render target is, and its dimensions and format.

I've seen that there's also a #define GR_BUFFER_TEXTUREAUXBUFFER_EXT. What's that?

And I'm curious about what I'm supposed to do with the smaller mipmap levels of the texture buffer. Fortunately Glide64 doesn't use them (large_lod==small_lod, always). Should I assume that only the largest mipmap level can be rendered to? Should the others stay black, or do I have to generate mipmaps by downfiltering?


indeed, thanks for the help you can add

Hmm, you've got most of the things correct. Only the part about the small_lod is incorrect. It's the lod_to_use_as_render_buffer. Detail as follows.

grTextureBufferExt( tmu, start_address, lod_to_use_as_render_buffer, large_lod, aspect_ratio, format, even_odd)

You specify one mipmap level as the render buffer with grTextureBufferExt() and then turn it on with grRenderBuffer(GR_BUFFER_TEXTUREBUFFER_EXT). Turn it off by specifying something other than GR_BUFFER_TEXTUREBUFFER_EXT. By default, rendering will be clipped to the specified mipmap level width*height. With the current version of glide, mipmap must be in the same format as the frame buffer.

grTextureAuxBufferExt() is basically the same except it's for the aux buffer. Use grAuxBufferExt() to toggle it on/off. GR_BUFFER_TEXTUREAUXBUFFER_EXT turns it on.

The TEXTUREBUFFER extension implies that the above are supported. The 3dfx hardware that supports the extension are banshee/V3/V4/V5.

-KoolSmoky

thanks KoolSmoky , i've just given your tips to Zeckensack

PS: maybe he'll be posting here soon

bye

Hi there

I, um, have some issues with the information. I don't want to be ungrateful, because I appreciate that you want to help out, but I think it's not quite the way you think it is

As I've said over on Emuxhaven, I have very good reason to believe that grRenderBuffer(GR_TEXTUREBUFFER_EXT) never does anything at all, under no circumstances. I think this is a bug in the original 3dfx drivers, i.e. they intended to implement the extension like you described, but they made a mistake, or didn't have enough time to complete the feature. On second thought, it appears to be the latter.

... because if grRenderBuffer(GR_TEXTUREBUFFER_EXT) does nothing and grTextureBufferExt only sets the dimensions and storage location, there would be no way to activate r2t. But there is. grTextureBufferExt does more than just setting params. It also, simultaneously turns on r2t. And it's the only way to turn it on (or back on, after calling e.g. grRenderBuffer(GR_BUFFER_BACKBUFFER)).

It's pretty obvious that this extension was never finished. As it stands, there is no need to reserve the GR_TEXTUREBUFFER_EXT token, but it exists. That means the 3dfx driver department had some plans to use it but didn't get it done. I'm convinced they would have wanted the feature to be exactly like you described. But as my goal is emulation of original behaviour, I feel that I must implement the extension in this unfinished and broken way.

This makes absolutely no difference to Glide64 compatibility btw.

Any further feedback is appreciated. And obviously feel free to disagree with me. If it turns out I'm wrong, I won't have a problem with that.

In any case, thanks for coming forward with the information in the first place

QuoteOriginally posted by zeckensack

Hi there

hey there

Quote
I, um, have some issues with the information. I don't want to be ungrateful, because I appreciate that you want to help out, but I think it's not quite the way you think it is

As I've said over on Emuxhaven, I have very good reason to believe that grRenderBuffer(GR_TEXTUREBUFFER_EXT) never does anything at all, under no circumstances. I think this is a bug in the original 3dfx drivers, i.e. they intended to implement the extension like you described, but they made a mistake, or didn't have enough time to complete the feature. On second thought, it appears to be the latter.

Yep, the texture buffer extention is unfinnished business mostly because it's broken in certain SLI modes for V5, hence undocumented in the glide3 programing docs. It's still a work in progress at SF, as we really haven't had the time to fix it.

Quote
... because if grRenderBuffer(GR_TEXTUREBUFFER_EXT) does nothing and grTextureBufferExt only sets the dimensions and storage location, there would be no way to activate r2t. But there is. grTextureBufferExt does more than just setting params. It also, simultaneously turns on r2t. And it's the only way to turn it on (or back on, after calling e.g. grRenderBuffer(GR_BUFFER_BACKBUFFER)).

grRenderBuffer(GR_TEXTUREBUFFER_EXT) does exactly what I wrote in my previous post. It toggles on/off rendering to texture i.e. "r2t". grRenderBuffer(GR_TEXTUREBUFFER_EXT) is the only way to turn r2t on or back on and it must be called after gTextureBufferExt(). There's something I forgot to explain in my previous post, though. You can freely change the target mipmap and/or level that glide will render to with gTextureBufferExt() without calling grRenderBuffer() provided r2t is on. The clipping will also be changed to the width*height of the specified mipmap level.

Quote
It's pretty obvious that this extension was never finished. As it stands, there is no need to reserve the GR_TEXTUREBUFFER_EXT token, but it exists. That means the 3dfx driver department had some plans to use it but didn't get it done. I'm convinced they would have wanted the feature to be exactly like you described. But as my goal is emulation of original behaviour, I feel that I must implement the extension in this unfinished and broken way.

This makes absolutely no difference to Glide64 compatibility btw.

I don't see any reason to implement the extention broken as you have described. At least it should work the way I explained and Glide64 will be able to use it.

Quote
Any further feedback is appreciated. And obviously feel free to disagree with me. If it turns out I'm wrong, I won't have a problem with that.

In any case, thanks for coming forward with the information in the first place

No problem. Good luck with your excellent wrapper.

-KoolSmoky