Author Topic: ATI Graphic Card Issue (Read 27319 times)

Megatron · « **on:** October 28, 2010, 08:45:10 am »

Hi there,

I'm having an issue with my graphics card and my SFML.NET project. I'm not sure if this is directly related to .NET or to the Graphics project as a whole, but I thought I'd try asking here first. This is for SFML 2.0

Basically, I upgraded to the newest ATI driver last night, and now my SFML project hangs. The program starts running, starts outputting to the console, but as soon as I make an SFML call (doesnt matter what, fonts, text, images, sprites all do the same thing), the program hangs waiting for the call to return. Normally, the binding to the SFML dlls are part of my project, since theres a few small things I add to the source binding, but replacing my custom binding with the included .net bindings (, , ) didnt stop the hang ups. I downloaded and compiled the latest version of SMFL and tried using that, but the same thing happens

I tried rolling back to several different version of the ATI driver, but to no effect, and I can;t remember the previous driver version I had when my project worked.

I know my project as working before I upgraded my graphics drivers, and my project still works on my other computer. I was wondering if anyone had encountered anything similar or had any ideas on how to fix this?

Thanks

DeadLeaves · « **Reply #1 on:** December 05, 2010, 09:12:11 pm »

I have the exact same issue after I upgraded my graphics drivers.
I use an AMD Radeon 5650m upgraded to 10.11 and now SFML applications hangs on startup. I use SFML with visual studio 2008 and I don't use .net or anything fancy, just regular c++ in VS08 and SFML.

Hope we'll get help, or if you solved it please post how you did it.
I know I posted in DotNet forum part, but this is the exact behaviour I encountered

rogerlevy · « **Reply #2 on:** December 23, 2010, 01:29:38 am »

Hey, same here!

On a laptop with Mobility Radeon 9700 it works fine.

But on my desktop with the latest drivers and a Radeon HD 5750, SFML hangs on startup. 0% CPU ... but totally unresponsive.

Addendum: I'm using the C dynamic linked version btw ... not sure if I should create a new Topic..

Silvah · « **Reply #3 on:** December 23, 2010, 11:35:05 am »

It's a known bug, dynamically linked SFML and ATI drivers don't like each other.

rogerlevy · « **Reply #4 on:** December 24, 2010, 04:22:57 am »

I Love SFML! If there's anything I can do to help that bug get fixed, let me know.

I just integrated SFML into my game engine for windowing and input and it works like a charm! Excellent library - much better than SDL. If this bug can get fixed that would be great - I can't link to the static library in the language I'm using - so yeah, it's kind of crucial =)

Spodi · « **Reply #5 on:** January 06, 2011, 06:48:09 pm »

I hate to be annoying, but is there really nothing .NET users can do? Not even shove SFML into some painfully-slow-yet-stable mode? I have been losing quite a few users due to this bug.

Laurent · « **Reply #6 on:** January 06, 2011, 07:11:04 pm »

Hmm the only thing I can think about is to:
1- add a kind of sf::Init() function
2- move the creation of the global OpenGL contexts (in GlContext.cpp: referenceContext and defaultContext) to this function
3- bind the Init() function in CSFML and SFML.Net
4- call it at startup

Groogy · « **Reply #7 on:** January 06, 2011, 07:21:54 pm »

I´m not using DotNet but I would't mind if you added that. As long as you don't design it like HGE... Yeww... (It's what my school forces me to use).

Anyway in the Ruby bindings I will make it so that when system is loaded that this function is automatically called. Don't know if that's possible for the DotNet bindings? Just to keep it more smooth

Spodi · « **Reply #8 on:** January 06, 2011, 11:37:55 pm »

If that is all it takes, that seems like a reasonable solution for now - at least until the bug is fixed. Cleanliness and simplicity are great, but stability is definitely more important.

In .NET, you could automatically invoke it via a static class constructor. The problem would just be determining which class to put that constructor in to make sure it is invoked in time. If there are multiple classes that must invoke it before they are used, a simple internal "helper" class could be added to ensure its only called once.

Laurent · « **Reply #9 on:** January 07, 2011, 08:56:38 am »

Quote

In .NET, you could automatically invoke it via a static class constructor. The problem would just be determining which class to put that constructor in to make sure it is invoked in time. If there are multiple classes that must invoke it before they are used, a simple internal "helper" class could be added to ensure its only called once.

Absolutely. Unless it brings back the problem, of course

Groogy · « **Reply #10 on:** January 07, 2011, 09:11:12 am »

The problem origin is the window right? Why not just call the init function in the window construction? Thus hiding the details from us.

Laurent · « **Reply #11 on:** January 07, 2011, 09:15:25 am »

Quote

The problem origin is the window right?

No, it's in the default/hidden OpenGL contexts that are created at global startup.

Quote

Why not just call the init function in the window construction? Thus hiding the details from us.

Because users may want to do graphics things before creating a window.

rogerlevy · « **Reply #12 on:** January 08, 2011, 05:27:54 am »

I'd also not complain about having to call an init function if it'll fix the issue.

Xyro · « **Reply #13 on:** January 16, 2011, 07:52:05 pm »

Any progress on fixing this, I decided to use this library for a project but if this stays I'll have to rewrite everything

WarHampster · « **Reply #14 on:** January 22, 2011, 06:53:02 pm »

Good thing that I decided to stick with SFML 1.6 for my project...

Author Topic: ATI Graphic Card Issue (Read 27319 times)

Silvah