elix_gx thinks banding comes from the gf6xxx rendering at 16-bit...he created a very ingenious test to determine this....anyways, i googled and saw many articles which mentioned Flight Simulator cloud banding and other cards defaulting to 16-bit color when actually what was requested by the engine was 24-bit.....turns out, some guy solved this issue by "forcing" 32-bit color using a registry tweak: "RenderQualityFlags" to 4

anybody know what this is/does and where it is at. anyone willing to risk hacking their registry? i am too timid and would not know where to look in my registry for this setting.

granted, the tweak was performed on a TNT card but....who knows....

found this too....make sense to anyone...could it work?

************************************************
nVidia admits 16-bit textures used by default in 32-bit modes in TNT/2 drivers
All 2 messages in topic - view as tree
Jonathan Harker Jul 16 1999, 3:00 am show options
Newsgroups: 3dfx.products.voodoo3
From: "Jonathan Harker" - Find messages by this author
Date: 1999/07/16
Subject: nVidia admits 16-bit textures used by default in 32-bit modes in TNT/2 drivers
Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse
...at least, that's the meaning I get from Nick Triantos' (nVidia's official
OpenGL guru) latest .plan update:
"Update: 16-Jul-99, 5:30 pm

FORCING TEXTURES TO BE 32-BPP
-----------------------------
I've had a bunch of people ask me this over the past few months, so I may as
well write about it here. The issue is whether textures are 16-bpp or
32-bpp. This is not the same as 32-bpp rendering, which is a term commonly
used to describe the depth of the frame buffer. There are also those who
claim to do 32-bpp rendering even though the textures are only 16-bpp, and
the frame buffer is 16-bpp. What that means is that the internal pipelines
inside the graphics chip work on 32-bpp colors, but the data is truncated as
it is written to the frame buffer. It allows for lighting and texture
application math to be performed with higher precision than would be on a
chip that only has a 16-bpp graphics pipeline.
But I digress.


Many applications do not specify what they want the texture depth to be.
They tell OpenGL that a texture is RGB or RGB+Alpha, but don't explicitly
request 32-bits per pixel. We default to choosing 16-bpp textures unless the
app requests otherwise, but if you want to change that, set the reg key:
\\HKEY_LOCAL_MACHINE\Software\NVIDIA Corporation\RIVA TNT\OpenGL
Value: "RenderQualityFlags", type DWORD, change from 0 to 4
This will set a bit that tells our OpenGL driver to default to 32-bpp
textures unless the app explicitly requests a 16-bpp texture format. With
love, from your friends at NVIDIA."
You can see where I snipped this for yourself @
http://www.rivaextreme.com/
*************************************************

end of lowboy's post....

and i found a bit more from the same post later on....

*************************************************
It sounds like Triantos begins by evading the issue initially and talking
about what "other" graphics card companies are doing...it sounds like he's
talking about 3dfx here in the first paragraph, but I am unaware of 3dfx
having claimed they were getting 32-bits out of the algorithms they
used--3dfx has only claimed 22-bit precision. I believe he is talking about
3dfx, though, in a "here's what we say they said" type of fashion....


Interesting, though, that he begins his comments with statements as to how
"other companies" are supposedly handling the 32-bit rendering issue.
Reinforcement for his own position, perhaps?


But I digress...


The second paragraph is the meat. In it, Triantos admits that the default
driver setup for rendering all textures in OpenGL on the TNT/2 is to render
them in 16-bits, unless the application requests otherwise (which he says is
rarely the case--"Many applications do not specify what they want the
texture depth to be.")


He then provides a supposed registry fix which will "force" the TNT/2 to
render 32-bit textures, unless, again, the application specifically calls
for 16-bit texture depth ( again, Triantos says that applications rarely
specify texture bit depth). We can now explain the "32-bit" performance
numbers being so close to the 16-bit numbers with this information.


My question is that I wonder if Triantos' registry fix will actually work?
If people try the fix and notice a performance hit in 32-bits substantially
greater than was apparent before the change, I'd say the fix works. If
there's no difference in performance after the fix, I'd say the switch is
broken and doesn't alter the default setting of using 16-bit texture depth
at all times. I remember the several versions of TNT/2 drivers which were
released which supposedly provided a registry switch for disabling vsync,
and I recall that the switch didn't work as advertised through more than one
driver release. I don't know yet if that particular switch has been fixed,
but that's why I question whether this one works. Hopefully it does and the
expected performance hit will reflect that it does.


Interesting as to why the drivers would not be constructed so as to force
32-bit textures automatically when the user selected a "32-bit" display
depth (since nVidia knew the applications usually didn't call for a
particular texture bit depth.) Other than the resulting hammer this would
drop on the "32-bit" framerate numbers, I can't think of any reason to do it
that way.... So that's that, I guess. I wouldn't be surprised at all to
further learn that the TNT/2's D3d drivers are built much the same way.


Last, it's just so groovy to know that my "friends at nVidia" have so much
"love" for me that they'd let me think their product was rendering in
32-bits when it wasn't.... I guess they were just worried about my
"feelings" and so forth....

*************************************************


all the above was quoted directly from


http://groups.google.com/group/3dfx.products.voodoo3


and


http://groups.google.com/group/alt.comp.periphs.videocards.matrox


please, please one of you smart computer geeks look into this mess! thanks!

I looked at my registry settings, and there is no entry "RenderQualityFlags". There is an entry "BitIndicators", though: HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\Global\NvSvc\BitIndicators. Its type is REG_DWORD and the value is currently 0. Googling it did not turn up anything immediately useful.

Considering this stuff discusses the TNT2 and is pulled off of a Voodoo3 group, it is rather ancient in video card terms. Thus, I would guess that nothing specific here will alleviate the 6x00 banding problem.

Forcing 32-bit operation is still the key, though, so the search shoudl continue.

i realize all the above stuff talks about TNT2 cards 5 years ago but perhaps a similar registry entry still exists and can be hacked. i wasn't able to find anything newer....just trying to exhaust the topic before i am forced to upgrade my card. JOE, just tell me to shut up about banding if i am becoming a pest on the topic...i will understand! i feel like i'm on a crusade for the banding fix and yet have no technical expertise myself....i keep relying on all the knowledge of my fellow simmers....

No, keep going, please.

Ditto Joe.

Applied that registry value, no change.
This setting only applies to opengl, does JF18 use opengl at all? Though there is a opengl32.dll in the game directory...

BTW: You can force opengl games to run in 32bit mode via rivatuner, but it doesn't affect JF18...

Hell I even deleted the opengl32.dll in the game directory, still runs fine...

I dont think opengl (32.dll) is used at all in JF18.
I ran the game for an hour and was monitoring its action thru FileMon at the same time. Never the opengl file was called or even accessed.

As Thrawn mention this article talks about openGL and a REALLY old card (TNT), I wouldn't hold my breath on the solution explained in this article, but Lowboy I'm sure we all really appreciate the effort! Conintue searching!

On my end, the last research I made lead me to beleive the problem resides in "Spectral Lighting".

I looked at the source code and sure there are Spectral Lighing functions, but that is as far as I can go, I'm not a 3D programmer.

Found a program that let you tweak various DirectX options and run an app with that options:
http://downloads.guru3d.com/download.php?det=1052#download

There are many options and one lets you force a z-buffer, played around a bit without success. The app has so many options this is far off my league...

Thrawn - This program is a big step forward!

You've almost found the holy grail.
I say almost because this program is only compatible with DX8 applications and JFA-18 seems to be DX7.
The good news are that I've learnt that 32bit color depth can be forced on a DX application, and that this can indeed fix our problem.

Since this program only works on DX8 applications I could only test it on a different flight sim ('strike fighters').

First, there is a newer version here:
http://www.nonatainment.de/portal/DesktopDefault.aspx?tabindex=7&tabid=19

In 'strike fighters' options I set the color depth to 16bit.
I ran the game and saw the familiar banding.


Next I used the program to force 32bit.


Ran the game again and even though the in game color depth options were still set to 16bit it actually ran in 32bit mode, with no banding!


What we need now is a similar program that works with DX7. We're getting close to solving this problem.