Author Topic: sf::Image -> sf::Texture, sf::Image (Read 6939 times)

Tank · « **on:** June 24, 2011, 01:50:51 pm »

Hey,

is it planned to separate sf::Image into image data and OpenGL texture? I'm currently having a big issue loading images in a separate thread randomly killing my application due to parallel access to the OpenGL context.

Splitting up loading images and creating textures wouldn't just avoid that problem, but also increase the separation between data and view. Or is there any way I missed to prevent sf::Image creating the texture directly after loading the image data from file?

Nexus · « **Reply #1 on:** June 24, 2011, 01:58:34 pm »

I think so

Tank · « **Reply #2 on:** June 24, 2011, 01:59:24 pm »

That it's planned or that I missed something?

EDIT: ahhh, disregard, didn't recognize it's a link. thanks.

Laurent · « **Reply #3 on:** June 24, 2011, 02:00:54 pm »

Quote

is it planned to separate sf::Image into image data and OpenGL texture?

https://github.com/SFML/SFML/issues/18

Quote

I'm currently having a big issue loading images in a separate thread randomly killing my application due to parallel access to the OpenGL context.

Can you show how you do this? Each thread works on a separate context, so unless you use their shared resources (textures) concurrently there should be no problem.

Quote

Splitting up loading images and creating textures wouldn't just avoid that problem, but also increase the separation between data and view

It's not exactly true, because the texture copies the data in its own storage. So the image cannot be used to store the texture's data. In fact, after I split the classes, sf::Image will be nearly useless (only useful for manipulating pixels before uploading them to the texture, or for keeping them in central memory for pixel perfect collisions).

Quote

Or is there any way I missed to prevent sf::Image creating the texture directly after loading the image data from file?

Nop.

Tank · « **Reply #4 on:** June 24, 2011, 03:32:03 pm »

Quote

Each thread works on a separate context, so unless you use their shared resources (textures) concurrently there should be no problem.

Interesting. What I do is loadings an image (if it hasn't been loaded before) to get the image's dimensions for some UV stuff calculations in a separate thread (in which geometry is being prepared for a VBO, so that the game doesn't freeze). Therefore either I access GetWidth() and GetHeight() of an existing sf::Image or create a new one. Regarding your explanation, this shouldn't be a problem at all, then (good news for you, bad news for me

). I'll check if there are any other side-effects I'm not aware of.

Quote

It's not exactly true, because the texture copies the data in its own storage. So the image cannot be used to store the texture's data. In fact, after I split the classes, sf::Image will be nearly useless (only useful for manipulating pixels before uploading them to the texture, or for keeping them in central memory for pixel perfect collisions).

Does that mean you're still thinking about a good design?

Groogy · « **Reply #5 on:** June 24, 2011, 04:10:52 pm »

Erhm you sound more like you are having trouble with your thread synchronisation as I am doing similar(not as many threads though) and are not having any problem like that.

But you might wanna look at before continuing: http://www.sfml-dev.org/forum/viewtopic.php?p=32906&highlight=#32906

I had a problem with the texture to opengl was not properly loaded when I wanted to use it until I created a temporary image. Though getting the width and height should be available without having to do that as they are set inside SFML.

Also I'm wondering why are you trying to stream the graphics? Are you trying to implement a LOD hierarchy?

Tank · « **Reply #6 on:** June 24, 2011, 04:39:42 pm »

Quote

Erhm you sound more like you are having trouble with your thread synchronisation

Like said above, I have to see if there're any sync issues.

Quote

Also I'm wondering why are you trying to stream the graphics?

Never talked about streaming here.

I just load the images on demand. My game can't preload images because what images are used is unknown (it's a multiplayer game where resources are used on demand).

However I might have tracked down one sync issue that produces side-effects for the call to the image stuff. Need to sort it out before I can blame SFML.

Laurent · « **Reply #7 on:** June 24, 2011, 05:44:49 pm »

Quote

Therefore either I access GetWidth() and GetHeight() of an existing sf::Image or create a new one

Be careful, sf::Image itself is not thread-safe (so as almost all SFML classes).

Quote

Does that mean you're still thinking about a good design?

No, I think I have it

There's only thing that I still need to solve: from a sprite you can get its texture, but from the texture you won't be able to get the pixels anymore (there will only be a slow "download" from the graphics card, into a sf::Image), so I don't know how people will do for pixel perfect collision detection. They'll probably be forced to store the collision data themselves, but this is really annoying.

Tank · « **Reply #8 on:** June 25, 2011, 04:03:15 pm »

Solved my problem, which is not SFML-related. Lucky one.

Quote

from a sprite you can get its texture, but from the texture you won't be able to get the pixels anymore

Is sf::Texture constructed using sf::Image? (I guess so) In that case you can still use the original sf::Image for pixel data. That's of course only valid if you store pixel data (i.e. sf::Image), but if you're using pixel perfect collisions for example, you have to. sf::Texture is, what it says, a texture and not suitable for pixel operations, but for making 3D faces fancy.

Groogy · « **Reply #9 on:** June 26, 2011, 10:11:04 pm »

Just realized that a sf::Texture class could also be used to let users access the OpenGL ID for the texture in an abstracted manner.

For example I have implemented a complete abstraction/wrap of the Shader functionality in my game engine except for one thing. Samples, I have no way to get a hold of my textures ID's(which are sf::Images) with the current API. I think it is those that are needed in order to add a sample variable right? Since you are supposed to use the integer version of the function.

Though would be nice to be able to just do: image.GetTextureID();

Tank · « **Reply #10 on:** June 28, 2011, 01:05:15 pm »

Hopefully you mean "texture.GetId()"

By having an sf::Texture class, I think it's really okay this time to provide some accessors for internal OpenGL stuff like Groogy mentioned. Don't know what Laurent has in his mind about it.

Seems like SFML 2 is going to be more of the OpenGL wrapper kind-of library than the 1.x branch. *fondles his crystal ball*

MorleyDev · « **Reply #11 on:** June 28, 2011, 08:38:21 pm »

Quote from: "Laurent"

There's only thing that I still need to solve: from a sprite you can get its texture, but from the texture you won't be able to get the pixels anymore (there will only be a slow "download" from the graphics card, into a sf::Image), so I don't know how people will do for pixel perfect collision detection. They'll probably be forced to store the collision data themselves, but this is really annoying.

Even if not doing pixel-perfect they'll still need to be keeping track of the collision data anyway (rectangles, circles, ellipses and the like) so it does seem to me as a problem that exists largely on the users end of things anyway ^^

The only difference if doing pixel-perfect here is they need to keep track of the original image or an optimized version of it (such as a bit-field)...

Plus being able to drop the image from RAM but keeping the texture in VRAM is definitely a plus.