3dfxzone.it ~ SFFT Drivers ~ MesaFX ~ 3D-Analyze ~ 3dfx Headlines ~ 3dfx Cards ~
Home | Profile | Register | Active Topics | Members | Search | GoogleSearch | FAQ | 3dfxzone.it
Username:
Password:
Save Password
Forgot your Password?

 Index
 3dfx Hardware & Software
 General Discussions
 HELP: grTextureBufferEXT, a Glide3's extension
 New Topic  Reply to Topic
 Print topic

Author Previous Topic Topic Next Topic  

ggab
Average

Argentina


294 Posts

Posted - 04/01/2005 :  21:43:24  Show Profile  Visit ggab's Homepage  Send ggab an ICQ Message  Click to see ggab's MSN Messenger address  Reply with Quote
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 :-)

Edited by - ggab on 04/01/2005 21:47:01

ggab
Average

Argentina


294 Posts

Posted - 04/01/2005 :  21:57:02  Show Profile  Visit ggab's Homepage  Send ggab an ICQ Message  Click to see ggab's MSN Messenger address  Reply with Quote
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
Go to Top of Page

ggab
Average

Argentina


294 Posts

Posted - 05/01/2005 :  04:40:34  Show Profile  Visit ggab's Homepage  Send ggab an ICQ Message  Click to see ggab's MSN Messenger address  Reply with Quote
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 :)
Go to Top of Page

koolsmoky
Moderator

101 Posts

Posted - 06/01/2005 :  06:02:08  Show Profile  Visit koolsmoky's Homepage  Reply with Quote
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
Go to Top of Page

ggab
Average

Argentina


294 Posts

Posted - 06/01/2005 :  06:35:31  Show Profile  Visit ggab's Homepage  Send ggab an ICQ Message  Click to see ggab's MSN Messenger address  Reply with Quote
thanks KoolSmoky , i've just given your tips to Zeckensack

PS: maybe he'll be posting here soon

bye
Go to Top of Page

zeckensack
Novice

Germany
4 Posts

Posted - 10/01/2005 :  07:03:32  Show Profile  Visit zeckensack's Homepage  Reply with Quote
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

My Glide wrapper
Go to Top of Page

koolsmoky
Moderator

101 Posts

Posted - 10/01/2005 :  14:00:49  Show Profile  Visit koolsmoky's Homepage  Reply with Quote
quote:
Originally 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
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Print topic
Jump To:

 

Forum Rules

Legal Info

Privacy

Contact Us

3dfxzone.it

HWSetup.it

ForumZone.it

 

All trademarks used are properties of their respective owners - Forum Graphics and Contents 2001 - 2014 3dfxzone.it - Forum Engine Snitz Forums