sf::Texture crashes when used in a static object

[Nexus]

Tank, I have already used multiple windows. And I also plan to use resource loading in a separate thread, exactly because of the smooth continuation of the main thread Laurent mentioned.

And I don't consider it a good idea to remove useful SFML features to make a questionable design (singletons) in your own project working. Are you sure you find no other way? You already mentioned init() and cleanup() should work, what about a RAII object encapsulating them? I think a central SFGUI object instantiated once in main() is acceptable, especially if it covers more functionality like the core of your GUI hierarchy or whatever. And it's definitely better than an ever-present bug at program exit.

[Tank]

I have already used multiple windows

Mind telling us for what?

And I also plan to use resource loading in a separate thread, exactly because of the smooth continuation of the main thread Laurent mentioned.

I really feel like talking with walls here. ;-) You can still load your resources in a separate thread, I already gave an example how to do it. And finally, like stated a million times already: You do not benefit from creating the textures in a separate thread. It's only loading and decompressing image data that do freezes/FPS drops.

Just answer the following question: If creating textures in a separate thread means that your game crashes at 1% of your user's computers, would you consider choosing another option or "just keep it that way"?

Please read the articles I linked in a previous post, or even do a Google search on OpenGL multi-threading and shared contexts. It's everything but recommended for good reasons.

And I don't consider it a good idea to remove useful SFML features to make a questionable design (singletons) in your own project working.

I already stated that "removing multiple windows" is not what I planned to achieve, but rather removing shared contexts. You can use as much windows as you like and you won't run into any problems when they all have separate contexts. But when they're shared, you have to pay attention in many regards that you better do with a single context in your application. In my opinion there's no advantage of using shared contexts.

Did you take a look at SFGUI's renderer to see why it's a singleton? It's a singleton because it's a global interface to OpenGL. You could also write free functions for most of the features the renderer provides. However it also manages some resources like texture caches and OGL handles, that's why it's an object primarily.

I really don't think having a singleton like that is an issue at all. The problem is that resources are not managed by SFML's contexts, so we can run into unpredicted behaviour quite easily. It can and should be avoided in my eyes.

And as you're talking about RAII: The one for SFML's resources doesn't pay attention at the context's scope. So when you argue that SFGUI should carry an init()/cleanup() pair, then SFML must have that too, because it's possible to keep resources alive when the parent object gets destroyed.

And it's definitely better than an ever-present bug at program exit.

Yeah, but now SFGUI users have to do an ugly

Code: [Select]

sfg::SFGUI foobar;

to workaround crashes – but not all, the GetDefaultFont() crash is still there and you can't do anything against it (except linking statically which seems to "fix" it, but I call that a fix that randomly works).

[Nexus]

I have used a window as a splash screen while a game was loading. When the actual game window is opened, the splash screen remains for a short time to show the loading success. I know it's rather a specific use case, but you wanted people to scream if they have already used it

You say we can load resources in other threads, but we shouldn't create textures there. But then you would have to split and complicate logic (other thread loads pixels, main thread checks if already loaded, and creates texture if ready). Are you sure the time needed to load textures isn't remarkable?

And I agree that the RAII object isn't very beautiful, I just mentioned it because you said technically it would work with cleanup()/init() -- that is, it's still more beautiful than the C way

[eXpl0it3r]

I've found a potential issue with this code in SFML, the fix is easy but I need to check something first. After that I'll create a new topic to make people test

Is that already somewhere available?
I'm the one with the crappy GPU and have thus experienced the problem in creating textures in a seperate thread. Also I've helped Tank figure it out over a 1-2h 'remote debug sessions'. :lol:

Also consider this about 'crappy' drivers: HP and other vendors do not let you use the native graphics driver but instead provide their own tweaked one. So if AMD puts out a new shiny driver on which every thinkable problem would be solved many many many users won't be able to use it (until the ones with the upper hand do push out their own driver).
Had to learn that the hard way (= had to reinstall the whole Windows).

Btw I find this post interessting and amusing at once, keep it up!
No seriously I like that such problems are being adressed and discussed openly. I know it's already enough time consuming to maintain and advance a complete crossplatform multimedia library next to a (full time) job (respect for that!) but since I guess we have some really smart guys on SFML board it would be also nice to see some other indepth topics on SFML and the stuff that is coming/that is worked on at the moment, rather than keeping everything to oneself and reveale it at the end. :wink:


Too tired to spellcheck my English... :wink:

[Laurent]

Is that already somewhere available?

It's more complicated than I thought

You can test this code: http://pastebin.com/axEarezn

(both in debug and release -- I've seen differences between them)
(you must link to OpenLG library)