Some further points to note. Anisotropic filtering can burn up video memory bandwidth due to the number of texture samples required and have an adverse effect on performance on lower end cards. Consequently, the plan is to keep the MaxAnisotropic environment variable so that the end user can restrict the maximum degree of anisotropy that the driver will allow. If the user sets this variable to 8x and the developer tries to set a higher value, the end user's value will take precedence.
Similarly, the environment variable option to force anisotropic filtering will be retained so that old applications can be made to use it in order to improve the rendering quality for older titles.
16 bits ZBuffer + native aniso?
Re: 16 bits ZBuffer + native aniso?
I agree with you on some points but, I'd like to detail more what I think is best :
1. Only applications that do not handle Anisotropic filtering will have it set with env (or from the special folder for the application if user want).
2. Application that handle Anisotropic filtering must be able to override env settings.
Why ? Simply because the end user that will for example play a game can be able to choose between quality/performance.
I remind this in an online game I play on PC : "The Lord of the Ring Online" where you can choose (in real time) to turn on/off the anisotropic filtering and, you can modify the effect value in realtime too.
Sometimes, when I get a slowest PC than I actually have, when I wanted to make nice snapshots of the game environment, I put graphics quality to maximum, get the snapshot and then restore settings to less quality/more performance. Do you understand ?
An application must always have the capability to choose on all capabilities the video card have. No ENV restrictions. They can be forgot by the user that may not understand why it don't work. When the setting is in the application, he know exactly what he changes for quality or performance or balance between both.
What does this mean in simple answer :
When Warp3D open a display, default ENV (or app default ENV) is applied.
Is the application change the anisotropic value when running, it will not modify the ENV file but it will change the displayed result with what the application defined (and no more what the ENV said).
Regards,
AmiDARK
1. Only applications that do not handle Anisotropic filtering will have it set with env (or from the special folder for the application if user want).
2. Application that handle Anisotropic filtering must be able to override env settings.
Why ? Simply because the end user that will for example play a game can be able to choose between quality/performance.
I remind this in an online game I play on PC : "The Lord of the Ring Online" where you can choose (in real time) to turn on/off the anisotropic filtering and, you can modify the effect value in realtime too.
Sometimes, when I get a slowest PC than I actually have, when I wanted to make nice snapshots of the game environment, I put graphics quality to maximum, get the snapshot and then restore settings to less quality/more performance. Do you understand ?
An application must always have the capability to choose on all capabilities the video card have. No ENV restrictions. They can be forgot by the user that may not understand why it don't work. When the setting is in the application, he know exactly what he changes for quality or performance or balance between both.
What does this mean in simple answer :
When Warp3D open a display, default ENV (or app default ENV) is applied.
Is the application change the anisotropic value when running, it will not modify the ENV file but it will change the displayed result with what the application defined (and no more what the ENV said).
Regards,
AmiDARK
Sam440EP - AmigaOS 4.1 Final Edition
- Hans
- AmigaOS Core Developer
- Posts: 703
- Joined: Tue Dec 21, 2010 9:25 pm
- Location: New Zealand
- Contact:
Re: 16 bits ZBuffer + native aniso?
I disagree. I'm a strong believer in giving the user as much control over his/her machine as possible. If a user chooses to override a program's settings, then those settings should be overridden (even if you provide warnings of any risks).AmiDARK wrote: 1. Only applications that do not handle Anisotropic filtering will have it set with env (or from the special folder for the application if user want).
2. Application that handle Anisotropic filtering must be able to override env settings.
Warp3D's ENV vars allow users to override settings. If an application already provides quality vs performance adjustments, then there is little to no incentive to use the ENV vars. However, if the user still chooses to override the application's settings using the ENV vars, then the computer should obey.
Hans
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
- Karlos
- 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?
@AmiDARK
When specified, user environment variables will take precedence. This is to ensure that the end user has final say. It's his system, after all. And as Hans points out, when an application gives the user the opportunity to control these settings directly, it isn't likely he's then going to set the corresponding environment variable as there's no need.
On the other hand, I forced 16x anisotropic sampling on just for WipeOut2097 and it looked a lot better;)
When specified, user environment variables will take precedence. This is to ensure that the end user has final say. It's his system, after all. And as Hans points out, when an application gives the user the opportunity to control these settings directly, it isn't likely he's then going to set the corresponding environment variable as there's no need.
On the other hand, I forced 16x anisotropic sampling on just for WipeOut2097 and it looked a lot better;)
Re: 16 bits ZBuffer + native aniso?
So if I'm not wrong :Warp3D's ENV vars allow users to override settings. If an application already provides quality vs performance adjustments, then there is little to no incentive to use the ENV vars. However, if the user still chooses to override the application's settings using the ENV vars, then the computer should obey.
1. When an application open a Warp3D display, default Warp 3D ENV settings are applied or Warp 3D application setting are applied if they exist overriding default Warp3D settings.
2. If this application try to override settings, application settings will be applied depending on 3. and 4.
3. Application settings can use higher values than default Warp3D ENV parameters.
4. Application settings cannot use higher values than application folder specific ENV parameters
Right ?
if these 4 statements are true, then I'm Ok.
(even if I found stupid that we have Two times the same parameters for 1 applications making user capability to be lost ununderstanding settings priorities ).
Kindest Regards,
AmiDARK
Sam440EP - AmigaOS 4.1 Final Edition
Re: 16 bits ZBuffer + native aniso?
No, If I understand correctly, application setting can't override "default" ENV vars (your 3.), not more than "app" ENV vars (your 4.). But "app" ENV vars got priority other "default" ENV var.3. Application settings can use higher values than default Warp3D ENV parameters.
It's the exact same on PC, where catalyst can override any parameters, by default settings, or by game profil (game profil override default settings), except they got an interface (and we can also make it).
It's up to user to create game profils but don't touch default parameters.
Re: 16 bits ZBuffer + native aniso?
Crisot,
It's easier for USER to leave it control how the graphic card render 3D directly in the application...
More to this, per default, these kind of parameters are set to "leave application choose". Why ?
Because on PC world Anisotropic is available from a long time so settings "leave application choose" fit for all applications.
On Amiga, we're not in the same case where NO application handle this so the user will have to force these parameters manually.
And, with the arrival of new applications that can handle this, it will fake performance results because defined in relationship with applications that does not handle this...
More to this, never forget "think like an user and not like a developer"... if User don't use an option every days .. he will forget it ... and these kinds of options are options can be easily forgotten and may lead to unexpected results in applications. That's why having them in the application (+ ENV) is I think, the best solution.
It's just my point of view to show a different way of thinking that is not BAD (too).
Regards,
AmiDARK
Honestly, do you often modify your Catalyst settings for each application ?It's up to user to create game profils but don't touch default parameters.
It's easier for USER to leave it control how the graphic card render 3D directly in the application...
More to this, per default, these kind of parameters are set to "leave application choose". Why ?
Because on PC world Anisotropic is available from a long time so settings "leave application choose" fit for all applications.
On Amiga, we're not in the same case where NO application handle this so the user will have to force these parameters manually.
And, with the arrival of new applications that can handle this, it will fake performance results because defined in relationship with applications that does not handle this...
More to this, never forget "think like an user and not like a developer"... if User don't use an option every days .. he will forget it ... and these kinds of options are options can be easily forgotten and may lead to unexpected results in applications. That's why having them in the application (+ ENV) is I think, the best solution.
It's just my point of view to show a different way of thinking that is not BAD (too).
Regards,
AmiDARK
Sam440EP - AmigaOS 4.1 Final Edition
- Karlos
- 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?
It sounds like there's some confusion over this issue. Allow me to try and clarify.
In a perfect world, the full Warp3D API would be implemented fully by every driver, every application would always query the driver capabilities and the API would be upgraded over time in a perfectly backwards compatible way.
However, in reality, the situation is that different drivers do not implement the API fully. Even worse, some drivers implemented parts of the API wrongly and applications were written (that will never be updated) that expected the wrong behaviour. When these things were fixed, those old applications started getting strange bugs, crashes etc.
Most of the environment variables are there to deal with these sorts of problems. They don't have any developer side equivalent and nor should they. When the user sets them, they are enforced and there is nothing the application code can do to override them and hopefully their application works as expected again.
The Z buffer environment was added to save video memory. My 32MB R100 board choked on a lot of titles that my 256MB (128 used) R200 would run just fine simply because of the lack of VRAM and the resulting texture swapping.
Anisotropic filtering was added as an experiment, to see if it gave any visual improvement. You have to force enable it via the environment vars for the moment since there is no other way to activate it.
When the API is updated, the behaviour will be as follows:
If the user enables anisotropic filtering via "force" through the env vars, it will be enabled and cannot be disabled by the application itself. This option is not for new software that will be anisotropic-aware, it is for everything that was written up to now that has no knowledge of it.
Regarding limits, such as the degree of anisotropy, the order of priority shall be:
Hardware Limit > app profile env limit (if any) > 3) global env limit (if any) > API request
Consider the following use cases:
1) Running an old game that has no knowledge of anisotropy but the user wants to have 8x anisotropy. He'd need to do the following:
SetEnv SAVE Warp3D/RadeonR200/<app>/Anisotropic force
SetEnv SAVE Warp3D/RadeonR200/<app>/MaxAnisotropic 8
The game will now use the closest anisotropic equivalent to whatever texture filters the game asked for, with a sample limit of 8x.
2) Running a new title that directly supports these features and gives the user control over their settings. The user will simply use whatever in-game options are available. No environment variables are required.
3) Running a new title that directly supports these features but doesn't give the user control over their settings. Suppose the game simply sets everything to the max because that's what the developer thought looked best and worked on his machine (tm).
In this case, a user might find that his card can't cope with that level of detail. He can now use the environment variables to reduce the settings to something he prefers:
SetEnv SAVE Warp3D/RadeonR200/<app>/MaxAnisotropic 8
In this case, when the game tries to set the anisotropy level for any texture to be more than 8x, it will be clamped at 8x. It can still set the anisotropy to be lower than 8x for a texture and that's OK.
Other drivers have user-defined limits too. For example, the Permedia2 chip can support textures of 2048x2048, but a 32-bit texture that size is already 2x larger than the total VRAM the card supports. The user can set an environment variable (ENV:Warp3D/Permedia2/<app>/LimitTextureSize) to restrict this size so that any applications which (properly) query the driver for the information will see whatever value they set, rather than the theoretical limit.
In a perfect world, the full Warp3D API would be implemented fully by every driver, every application would always query the driver capabilities and the API would be upgraded over time in a perfectly backwards compatible way.
However, in reality, the situation is that different drivers do not implement the API fully. Even worse, some drivers implemented parts of the API wrongly and applications were written (that will never be updated) that expected the wrong behaviour. When these things were fixed, those old applications started getting strange bugs, crashes etc.
Most of the environment variables are there to deal with these sorts of problems. They don't have any developer side equivalent and nor should they. When the user sets them, they are enforced and there is nothing the application code can do to override them and hopefully their application works as expected again.
The Z buffer environment was added to save video memory. My 32MB R100 board choked on a lot of titles that my 256MB (128 used) R200 would run just fine simply because of the lack of VRAM and the resulting texture swapping.
Anisotropic filtering was added as an experiment, to see if it gave any visual improvement. You have to force enable it via the environment vars for the moment since there is no other way to activate it.
When the API is updated, the behaviour will be as follows:
If the user enables anisotropic filtering via "force" through the env vars, it will be enabled and cannot be disabled by the application itself. This option is not for new software that will be anisotropic-aware, it is for everything that was written up to now that has no knowledge of it.
Regarding limits, such as the degree of anisotropy, the order of priority shall be:
Hardware Limit > app profile env limit (if any) > 3) global env limit (if any) > API request
Consider the following use cases:
1) Running an old game that has no knowledge of anisotropy but the user wants to have 8x anisotropy. He'd need to do the following:
SetEnv SAVE Warp3D/RadeonR200/<app>/Anisotropic force
SetEnv SAVE Warp3D/RadeonR200/<app>/MaxAnisotropic 8
The game will now use the closest anisotropic equivalent to whatever texture filters the game asked for, with a sample limit of 8x.
2) Running a new title that directly supports these features and gives the user control over their settings. The user will simply use whatever in-game options are available. No environment variables are required.
3) Running a new title that directly supports these features but doesn't give the user control over their settings. Suppose the game simply sets everything to the max because that's what the developer thought looked best and worked on his machine (tm).
In this case, a user might find that his card can't cope with that level of detail. He can now use the environment variables to reduce the settings to something he prefers:
SetEnv SAVE Warp3D/RadeonR200/<app>/MaxAnisotropic 8
In this case, when the game tries to set the anisotropy level for any texture to be more than 8x, it will be clamped at 8x. It can still set the anisotropy to be lower than 8x for a texture and that's OK.
Other drivers have user-defined limits too. For example, the Permedia2 chip can support textures of 2048x2048, but a 32-bit texture that size is already 2x larger than the total VRAM the card supports. The user can set an environment variable (ENV:Warp3D/Permedia2/<app>/LimitTextureSize) to restrict this size so that any applications which (properly) query the driver for the information will see whatever value they set, rather than the theoretical limit.
- Hans-Joerg Frieden
- AmigaOS Core Developer
- Posts: 223
- Joined: Wed Dec 08, 2010 3:52 pm
Re: 16 bits ZBuffer + native aniso?
The Catalyst drivers usually come with pre-set profiles for games, and most games I know on the PC have a setting for the texture filtering, so you can actually switch it in game and do not need to go for the control panel.AmiDARK wrote:Crisot,Honestly, do you often modify your Catalyst settings for each application ?It's up to user to create game profils but don't touch default parameters.
It's easier for USER to leave it control how the graphic card render 3D directly in the application...
Usually, it's easier for the user if the defaults are good, but once you get into performance issues, it's better the user can actually influence some parameters to make the game workable on their machine. That's better than the user not being able to use it.
NOTICE: If you want to contact me, use E-Mail. I cannot be contacted via the forum/private messages anymore
- Karlos
- 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?
This is why we have user documentation: http://wiki.amigaos.net/wiki/UserDoc:Warp3DAmiDARK wrote:if User don't use an option every days .. he will forget it ... and these kinds of options are options can be easily forgotten and may lead to unexpected results in applications. That's why having them in the application (+ ENV) is I think, the best solution.