16 bits ZBuffer + native aniso?

This forum is for general developer support questions.
Crisot
Posts: 17
Joined: Fri Jan 04, 2013 12:43 pm

16 bits ZBuffer + native aniso?

Post by Crisot »

Hi!

I've seen in last Warp3D update there is a support for 16 bits ZBuffering with R200 driver. But I don't know how to enable it. I tryed with W3D_Hint(), but the precision is allways the same. Looks like I allways have 32 bits ZBuffer, but I'd like to try 16 bits to gain some speed where excellent precision isn't needed.

I've found nothing in the autodoc or in warp3D.h about this.

Little help please? ^^

Thanks.
Last edited by Crisot on Sun Jan 06, 2013 1:06 am, edited 1 time in total.
User avatar
ssolie
Beta Tester
Beta Tester
Posts: 1010
Joined: Mon Dec 20, 2010 8:51 pm
Location: Canada
Contact:

Re: 16 bits ZBuffer?

Post by ssolie »

Crisot wrote:Little help please?
Your first stop should be the AmigaOS Documentation Wiki. Look in the Warp3D section.

I know it is really strange actually having Amiga documentation available in one place so this new wiki will take some getting used to... ;)
ExecSG Team Lead
Crisot
Posts: 17
Joined: Fri Jan 04, 2013 12:43 pm

Re: 16 bits ZBuffer?

Post by Crisot »

O.M.G!!!

Yes, shame on me, certainly, but I just discover this wiki. So many thanks! There are so much features in this wiki not documented in autodoc. You've changed my life!

It's just a bit strange to have to change some parameters wih env-variables and no library specific functions, but well, it's so good to discover new features!

Time to code! Thanks! :)
Crisot
Posts: 17
Joined: Fri Jan 04, 2013 12:43 pm

Native anisotropic filtering

Post by Crisot »

Hummm... I got a last question, the wiki talk about native support of anisotropic filtering.

I found in the SDK that minigl support this extension, and accept parameters like GL_TEXTURE_MAX_ANISOTROPY_EXT and GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT to enable native anisotropy.

But nothing about this in warp3d.h, I found no way to have hardware support for it with Warp3D, and since minigl uses Warp3D to render, this is nonsense. Is the file warp3d.h not up to date? Or does minigl fake anisotropic filtering another way?

Thanks! ;)
User avatar
Karlos
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 84
Joined: Sun Jun 19, 2011 11:42 am
Location: United Kingdom of England and anybody else that wishes to remain.

Re: 16 bits ZBuffer + native aniso?

Post by Karlos »

Just to be clear, support for 16-bit Z buffers are a end-user option for now, not a developer feature. There is no way (yet) select which buffer format to use from your application.

The reason for this is that the work on Warp3D has been focused on improving what already exists and not about adding new features to what is basically a deprecated system. Secondly, even exposing these features through the Warp3D API wouldn't make any difference to existing applications and without propagating that exposure through MiniGL would leave it beyond the use of most people that are currently doing 3D in OS4.

The 16-bit Z buffer option was added as a user controllable variable to help reduce VRAM waste. That it makes certain things faster is just a bonus.

Anisotropic filtering should work OK and is exposed as a W3D state flag*. Most old applications were written before we had access to hardware that supported it, and for those, the end user can force enable it through the documented environment variables.

*This means that for now, you can turn it on or off under software control, but the degree of anisotropy is controlled by the environment variables. I don't believe there's any way to control that through the API.
Crisot
Posts: 17
Joined: Fri Jan 04, 2013 12:43 pm

Re: 16 bits ZBuffer + native aniso?

Post by Crisot »

Karlos wrote:Anisotropic filtering should work OK and is exposed as a W3D state flag*.

*This means that for now, you can turn it on or off under software control, but the degree of anisotropy is controlled by the environment variables. I don't believe there's any way to control that through the API.
Okay for maxanisotropic, but actually I can't found any state allowing me to turn anisotropic "on".

Code: Select all

/* possible mode values for W3D_SetState/W3D_GetState and for 'state' in the
   context structure */

#define W3D_AUTOTEXMANAGEMENT   (1<<1)  /* automatic texture management */
#define W3D_SYNCHRON            (1<<2)  /* wait, until HW is idle */
#define W3D_INDIRECT            (1<<3)  /* drawing is queued until flushed */
#define W3D_GLOBALTEXENV        (1<<4)  /* SetTexEnv is global */
#define W3D_DOUBLEHEIGHT        (1<<5)  /* Drawing area is double height */
#define W3D_FAST                (1<<6)  /* Allow Warp3D to modify passed Triangles/Points/Lines */
#define W3D_AUTOCLIP            (1<<7)  /* clip to screen region */
#define W3D_TEXMAPPING          (1<<8)  /* texmapping state */
#define W3D_PERSPECTIVE         (1<<9)  /* perspective correction state */
#define W3D_GOURAUD             (1<<10)         /* gouraud/flat shading */
#define W3D_ZBUFFER             (1<<11)         /* Z-Buffer state */
#define W3D_ZBUFFERUPDATE       (1<<12)         /* Z-Buffer update state */
#define W3D_BLENDING            (1<<13)         /* Alpha blending state */
#define W3D_FOGGING             (1<<14)         /* Fogging state */
#define W3D_ANTI_POINT          (1<<15)         /* Point antialiasing state */
#define W3D_ANTI_LINE           (1<<16)         /* Line antialiasing state */
#define W3D_ANTI_POLYGON        (1<<17)         /* Polygon antialiasing state */
#define W3D_ANTI_FULLSCREEN     (1<<18)         /* Fullscreen antialiasing state */
#define W3D_DITHERING           (1<<19)         /* dithering state */
#define W3D_LOGICOP             (1<<20)         /* logic operations */
#define W3D_STENCILBUFFER       (1<<21)         /* stencil buffer/stencil test */
#define W3D_ALPHATEST           (1<<22)         /* alpha test */
#define W3D_SPECULAR            (1<<23)         /* Specular lighting */
#define W3D_TEXMAPPING3D        (1<<24)         /* 3d textures */
#define W3D_SCISSOR             (1<<25)         /* Scissor test enable */
#define W3D_CHROMATEST          (1<<26)         /* Chroma test enable */
#define W3D_CULLFACE            (1<<27)         /* Backface culling enable */
/* New states for V5 */
#define W3D_MULTITEXTURE		(1<<28)			/* Enable multitexturing and separate blend functions */
#define W3D_FOG_COORD			(1<<29)			/* Use separate fog coord array instead of first texture's w coordinates */
#define W3D_LINE_STIPPLE		(1<<30)
#define W3D_POLYGON_STIPPLE		(1<<31)
And I'd like to avoid the "force" envarc, because this disable trilinear filtering.

I found nothing in texenv parameters too (which is much more appropriate IMHO)
Maybe I missed something?
User avatar
Karlos
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 84
Joined: Sun Jun 19, 2011 11:42 am
Location: United Kingdom of England and anybody else that wishes to remain.

Re: 16 bits ZBuffer + native aniso?

Post by Karlos »

Crisot wrote:
Karlos wrote:Anisotropic filtering should work OK and is exposed as a W3D state flag*.

*This means that for now, you can turn it on or off under software control, but the degree of anisotropy is controlled by the environment variables. I don't believe there's any way to control that through the API.
Okay for maxanisotropic, but actually I can't found any state allowing me to turn anisotropic "on".
Sorry, it seems I lied. It was a flag I reused experimentally, It's not official. I've reverted my Warp3D.h file now.

The problem is, there are no free state flags left.
And I'd like to avoid the "force" envarc, because this disable trilinear filtering.
It shouldn't. Anisotropic filtering is an extension of trilinear filtering; the key difference is that it doesn't just have square mip maps for each level, it has rectangular ones too. Also, there's no way to provide them programatically (unlike regular mip maps in Warp3D).

I will look into the W3D_HINT suggestion for the Z buffer format selection. Remember, however, that selecting a 16-bit Z buffer will kill all stencil buffer operations (they will return W3D_NOSTENCILBUFFER / W3D_UNSUPPORTED as appropriate). The stencil buffer and Z buffer are stored together as 8-bits of stencil and 24-bits of Z. The only possible solution is to make AllocStencilBuffer() override the setting if it is called and reallocate the Z buffer.
Crisot
Posts: 17
Joined: Fri Jan 04, 2013 12:43 pm

Re: 16 bits ZBuffer + native aniso?

Post by Crisot »

Hummm... Actually with aniso forced, I can clearly see a "hard line" between 2 differents texture "depth", just as if I set the magnification filter to W3D_NEAREST, even if set to W3D_LINEAR. I can't explain it correctly because I got a very lame english, but I'm sure you know what I mean ^^. Thoses "hard line" does not exist with aniso set to off.

BTW, A friend achieved to get aniso with MiniGL without setting manually envarc params. If Warp3D got no SetState() for it, I think MiniGL is setting temporary env variable?

Well, all this is not really really important. I'll set env params from my code, that's it. :-)
Last edited by Crisot on Sun Jan 06, 2013 6:18 pm, edited 1 time in total.
User avatar
Karlos
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 84
Joined: Sun Jun 19, 2011 11:42 am
Location: United Kingdom of England and anybody else that wishes to remain.

Re: 16 bits ZBuffer + native aniso?

Post by Karlos »

Crisot wrote:Hummm... Actually with aniso forced, I can clearly see a "hard line" between 2 differents texture "depth", just as if I set the magnification filter to W3D_NEAREST, even if set to W3D_LINEAR. I can't explain it correctly because I got a very lame english, but I'm sure you know what I mean ^^. Thoses "hard line" does not exist with aniso set to off.
That does sound like a bug, I agree.
BTW, A friend achieved to get aniso with MiniGL without setting manually envarc params. If Warp3D got no SetState() for it, I think MiniGL is setting temporary env variable?

Well, all this is not really really important. I'll set env params from my code, that's it. :-)
Once some of the newly reported bugs are ironed out, I will look into updating the API. I don't want to do too much there because Warp3D is basically deprecated.

Be careful setting environment variables from your code. To do it properly, you'll need to consider two things:

1) You at least need to know the name of the driver in use (ie RadeonR200, Radeon etc) and the current DOS process name or Task name (just the file part) which is used by the application profile mechanism. Then you can set the variable as ENV:Warp3D/<driver name>/<application name>/<variable name>, and you won't risk upsetting other applications. However, the problem is that you still only have control per application, not per running instance of the application.

2) The environment variables are only inspected when creating a new context and *only* if the Task which is creating the context is a DOS Process (since IO is required). Otherwise, you get whatever variables were set when the driver was first opened.
Crisot
Posts: 17
Joined: Fri Jan 04, 2013 12:43 pm

Re: 16 bits ZBuffer + native aniso?

Post by Crisot »

Karlos wrote: Once some of the newly reported bugs are ironed out, I will look into updating the API. I don't want to do too much there because Warp3D is basically deprecated.
Things like aniso are considered as OpenGL "Extensions". Maybe it should be faster for you to create something like SetEXTParams() and have 32 new flags. (?) Simple idea.

I know W3D is deprecated. But I like it because we actually have it, and it does it's job quite fast. You'll be surprised to see how complex rendering we can achieve with Warp3D when called from a fast engine.
Be careful setting environment variables from your code. To do it properly, you'll need to consider two things:

1) You at least need to know the name of the driver in use (ie RadeonR200, Radeon etc) and the current DOS process name or Task name (just the file part) which is used by the application profile mechanism. Then you can set the variable as ENV:Warp3D/<driver name>/<application name>/<variable name>, and you won't risk upsetting other applications. However, the problem is that you still only have control per application, not per running instance of the application.

2) The environment variables are only inspected when creating a new context and *only* if the Task which is creating the context is a DOS Process (since IO is required). Otherwise, you get whatever variables were set when the driver was first opened.
Thanks, I'll take care about this.

EDIT: BTW, with the latest version, I experience some texture corruption, specially with higher resolution. With my own engine, or with some games. Unfortunately I can't give you a special way to reproduce it. Sometime it works, sometime it doesn't. With my engine, at 1920x1080, the textures looks 95% of time corrupted. Looks like it only affect the biggest mipmap level, not the smaller ones. If this can help...
Post Reply