New HDR demo
- Thread starter Humus
- Start date
Ok, I updated drivers to the latest ones on NV's site, now instead of throwing up an empty window and complaining about no cable TV available ( 
), it simply doesn't do anything other than make a button on the taskbar and occupy one of the hardware threads of my CPU to 100%. No window, and NO GRAPHICS.
I don't want to ridicule people of l33ter sk1llz than myself, but if windows games were as dodgy as Humus' demo coding, everybody would be up in arms! It's becoming sort of a tradition of the new great demo that never runs properly on NV hardware... Of course, it might all be NV's fault though, I've no real clue.
), it simply doesn't do anything other than make a button on the taskbar and occupy one of the hardware threads of my CPU to 100%. No window, and NO GRAPHICS.I don't want to ridicule people of l33ter sk1llz than myself, but if windows games were as dodgy as Humus' demo coding, everybody would be up in arms!
It's becoming sort of a tradition of the new great demo that never runs properly on NV hardware... Of course, it might all be NV's fault though, I've no real clue.Guden Oden said:I don't want to ridicule people of l33ter sk1llz than myself, but if windows games were as dodgy as Humus' demo coding, everybody would be up in arms!
Well, that's life if you insist on using the latest and greatest features and only have one platform to test on. It's bound to cause issues. It's a good way to make people update their drivers though.
Im just unsure why forced breaks it since I've never had that problem with far cry or the new splinter cell.Humus said:
I used to assume AF worked in every app untill I played richard burns really (not really related to your demo since you enable it in the app tho).
Now I'm unsure
For what it's worth, I face the same problem Humus does, but on the other end of the spectrum. I primarily develop and test on Nvidia hardware. It seems more often than not, when I implement new effects and features using the latest and greatest today's hardware has to offer, It'll "just work" on my Nvidia systems but fall flat on it's face on my only ATI system. Humus, for the love of god tell me ATI has fixed the glGenerateMipmapEXT bug and it'll be in the coming driver releases
Shouldn't a man of your salary be able to buy a second PC with a NV card in it to test things on?Humus said:
Anyway, isn't it WEIRD that things aren't just automagically working in the 3D realm if you follow the rules and do stuff the way you're supposed to? Standard windows API function calls don't suddenly start to freak out if they run on AMD or VIA or Transmeta CPUs, but hop from ATi to NV and DX goes absolutely bananas...
Hey... Now that you mention it, that IS true! Last two times I updated my drivers was because I was trying one of your new demos.It's a good way to make people update their drivers though.
The blur render targets are getting converted to 8 bit (see RGBA16 in http://developer.nvidia.com/object/nv_ogl_texture_formats.html), try using RGBA16F.Humus said:
Humus said:
For the most part it looks good. Perhaps not everyone will notice this is in the auto fly mode, but there are brief instances when rendering still fails. It can be easily spotted when you go into "free fly" mode. Picture included (6800 Ultra FW 77.77).
Furthermore, is there a good reason why it is so slow on the 6800 Ultra? I see people using X800XT getting 120+ fps at 1280*960 with 4x AA and I am getting ~50fps at 1280x960 with no AA. Surely the 6800 isn't that inferior.
If humus is using FP16 textures for the blur on the 6800 ( which he is since the NV was converting INT16 requests to a INT8 texture ) then the reason this is most likely happening is in that case you have a infinity value in a texture. Generally +/-Inf is rather annoying for simple graphical rendering. We really need some special clamp options to clamp the textures at Max rather then infinite.wireframe said:
Any idea whats causing the problems with ATI users? with the graphics corruption? Since I get it with a fresh latest driver install.
Last edited by a moderator:
ChronoReverse
Newcomer
Yeah, getting the same artifact here on my 6800LE.
40ish FPS at 1280x960 =(
The black screen is fixed by disabling FSAA/anisotropic (didn't check which, just disabled both...probably anisotropic).
On my 6600 GT it usually looks good, but sometimes the high exposure scenes show some pretty bad banding around the sun. Might be nice to produce a FP16 version for comparison.
On my 6600 GT it usually looks good, but sometimes the high exposure scenes show some pretty bad banding around the sun. Might be nice to produce a FP16 version for comparison.
bloodbob said:
Good point, that's probably it. The skybox has a maximum value of 78600, while MAX_FLOAT16 is 65504 I think. Try changing the last line in skybox.shd to this and see if it goes away:
gl_FragColor.rgb = min(sky.rgb, vec3(60000.0));
bloodbob said:
I was just able to reproduce it myself. It seems to be resolution dependent, but couldn't figure out the exact pattern. Also, it seems to be fixed in recent driver builds, but not yet gone public.
