SFML community forums
Bindings - other languages => DotNet => Topic started by: 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
-
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
-
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..
-
It's a known bug, dynamically linked SFML and ATI drivers don't like each other.
-
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 =)
-
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.
-
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
-
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 :P
-
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.
-
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 ;)
-
The problem origin is the window right? Why not just call the init function in the window construction? Thus hiding the details from us.
-
The problem origin is the window right?
No, it's in the default/hidden OpenGL contexts that are created at global startup.
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.
-
I'd also not complain about having to call an init function if it'll fix the issue.
-
Any progress on fixing this, I decided to use this library for a project but if this stays I'll have to rewrite everything :(
-
Good thing that I decided to stick with SFML 1.6 for my project...
-
@WarHampster - is the ATI issue resolved in sfml 1.6? I'm using sfml 1.5 and my users with ATI cards (radeon 4xxx-7xxx) are reporting my program isn't running.
-
is the ATI issue resolved in sfml 1.6?
Nop.
-
I could also do with knowing whether/when there is likely to be a fix to this, as it has the potential to be a deal breaker with using SFML.
-
There will of course be a fix, probably soon.
-
is the ATI issue resolved in sfml 1.6?
Nop.
Gah, I thought that the issue was only in SFML 2.0. In that case, add me to the list of people asking for a quick and dirty fix.
-
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
Any updates on whether or not this approach will be implemented for a temporary fix?
-
Any updates on whether or not this approach will be implemented for a temporary fix?
No it won't, I'm already working on the clean solution ;)
-
Whats the eta on the fix ?
-
Progressing very slowly, I have very little time to spend on SFML at the moment.
-
So when is this issue going to be fixed? I'm participating in a game development competition and I wanted to choose SFML.NET as game engine... but it's freezing every time I want to test my game! Is there any way to get around this? If this doesn't get fixed soon I'm afraid I'm going to have to switch to another game engine :cry:
-
You can try this:
http://www.sfml-dev.org/forum/viewtopic.php?p=27975#27975
-
You can try this:
http://www.sfml-dev.org/forum/viewtopic.php?p=27975#27975
Yeah, I found that link already, it fixed the problem :D
-
so any progress on that ???
-
so any progress on that ???
It's been fixed for over a month now.
-
so any progress on that ???
It's been fixed for over a month now.
great thx :)
-
so any progress on that ???
It's been fixed for over a month now.
Not for me. Still have the same problem. None of my SFML projects run any more, all hang on the first SFML graphics call.
The 10.4 driver DLL work-around is OK but it's not really 'fixed'.
-
so any progress on that ???
It's been fixed for over a month now.
Not for me. Still have the same problem. None of my SFML projects run any more, all hang on the first SFML graphics call.
The 10.4 driver DLL work-around is OK but it's not really 'fixed'.
You just bumped a thread that is almost a year old. :shock:
Anyways, this has been fixed in the SFML 2.0 repo for a long time. Try downloading and compiling the latest version. 8)
-
I'm using the current source from GitHub, so unless that's not the latest...
Maybe it's not the same issue then, but the symptoms are the same. I don't get any errors/exceptions, I just get the process hanging on any SFML graphics call. Issue is fixed using DLL from 10.4 drivers in the bin directory.