set all graphic details to lowest settings or off, upgrade/downgrade driver. next time you post an infolog, attach as a file or use pastebin.com please.
next time you post an infolog, attach as a file or use pastebin.com please.
ok.. i'm sorry!
hoijui wrote:
set all graphic details to lowest settings or off, upgrade/downgrade driver.
the graphics details are already lowest... i already tried this solution. i play without shadow, reflection and high res cloud. without grass detail, and minimum of LOD and other option. and i play in full screen 800x600 or 1024x768 with 16 bit without AntiAliasing.
i read now in variuos gaming forum that ATI have most problem with Open GL drivers... and causes some crash with an atioglxx.dll error. Some people solved this problem using standard setting of ATI card and disabling AI catalyst option. this evening i will try to modify this ATI setting and i will write response here.
What's wrong with those shaders on HD-series Radeon? Does anybody have a clue? IIRC, they aren't doing anything anywhere near the complexity of jK's GLSL... so it's probably a syntax error that older Catalyst drivers deal with nicely (no surprise, the HD's using different OGL and it's twitchy and buggy).
If BumpWater is working, then that tells us something pretty important, as jK has a lot of experience bug-fixing for ATi at this point. Perhaps all of the water shaders should be re-written in GLSL, so that they're easier to maintain and bug-fix?
What's wrong with those shaders on HD-series Radeon? Does anybody have a clue? IIRC, they aren't doing anything anywhere near the complexity of jK's GLSL... so it's probably a syntax error that older Catalyst drivers deal with nicely (no surprise, the HD's using different OGL and it's twitchy and buggy).
If BumpWater is working, then that tells us something pretty important, as jK has a lot of experience bug-fixing for ATi at this point. Perhaps all of the water shaders should be re-written in GLSL, so that they're easier to maintain and bug-fix?
oi... it's right... the problem is the "reflective water"!!!... i ever played with "reflective water" without problem.. but in last time... i had some crash!! ( new version of spring, new ATI drivers) this evening i played with "basic" water option and spring didn't crash!! thx for solution! but i hope you will solve this problem with ATI cards!!!
argh: i don't know what exactly is the problem; i only know it started to show up in the middle of the year, around 9.6-9.7 drivers.
shorewaves bug is recoverable, as in the drivers notice they lock up and the game appears to work afterwards. i submitted about two dozens worth of automated error reports this way about 2 months ago. commenting out about 10 lines of shorewave shader fixes the crash, but also breaks the effect beyond any usefulness.
reflective water causes ati driver to leak memory, which is the reason it crashes around 15-20 min mark - it simply eats all available memory and then dies. this may or may not be related to drawing order lines or whatever. someone on mantis said that changing the stripe pattern fixed the leak. i don't have any solution here, either, apart from "don't use those options".
I fixed shorewaves (the shader was crashing my 8800GT too) in master some time ago, but it didn't make the 80.5 release. Adventurous ATI victims may try the test installer.
Hrmph, that could mean that GL_LINES are just as screwy as GL_POINTS on ATi... or that certain stripe patterns cause the driver to revert to software rendering, and it crashes at that point. IDK about you guys, but I plan on writing a very long and somewhat grumpy letter to their devrel when P.O.P.S. is done- their drivers are ridiculous atm, everybody outside their box seems to know it, but apparently doing "bug fixes" that "just happen" to mainly be for the big guys like Microsoft and EA takes priority over making them generally stable and standards-compliant.
On the water issues... IDK about you guys, but I just plain don't feel like screwing with the ARB shaders for water1 / water3, trying to figure out why / where it causes a memory leak. They never did before, but it's always been a bit flaky on some hardware, and I think we need to be working in a language that several of us are at least semi-competent at.
My vote: just remove caustic / shorewave / normalmap fresnel from water4, voila, you're back to water1. Put a hardware check into Spring, and revert people back to water0 if they cannot handle water1's shader, and keep water0 100% fixed-function, which IIRC it is... slow as hell, but no crashes.
GL_LINES is broken too, yes; using widths of more than 1px caused spring to crash. amazingly, redrawing the lines twice (thick and then 1px) stopped the crashes.
Does anybody have a clue? IIRC, they aren't doing anything anywhere near the complexity of jK's GLSL... so it's probably a syntax error that older Catalyst drivers deal with nicely
Users browsing this forum: No registered users and 2 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Home
Download
Login
Register
FAQ
Search
