Mixing straight OpenGL with SFML/Graphics

[crawshaw]

Hi all, I am writing a 3D engine and I'm trying out SFML for cross platform abstraction (mainly generating an OGL Context). Along the way I thought it might be nice to use some of the features in the graphics library, but I find the GL is abstracted away.

E.g. I was considering using sf::Image to load textures, but I find that Image, more than just decoding the jpg/png/dds, actually encodes the image to DXT (that must be slow!) and binds it to an OpenGL texture. There is then no way of getting to the GLuint texture identified (Image::myTexture).

Is this kind of usage a goal of SFML? If so, could I suggest either:

1. Exposing the GL identifiers, or
2. Expose sf::ImageLoader, separating image decode and DXT encode, or
3. Make sf::Sprite do the texture binding, leaving an unsued sf::Image as just a 'bag of pixels'

Would a patch for either of these be accepted? I'm more for the second or third options, but I'm very new around here.

[eleinvisible]

I believe DXT compression actually makes rendering faster, but if you want image loading capabilities use SOIL (distributed with SFML). Thus you can use the same library just in an uglier method.

Code: [Select]


GLuint Texture = SOIL_load_OGL_texture(
"filename.ext",
SOIL_LOAD_AUTO,
SOIL_CREATE_NEW_ID,
SOIL_FLAGS);

See SOIL.h for all SOIL_FLAGs... As for exposing the identifier, couldn't you just make an GetOGLTexture() function? I do think this is a good idea though, as sf::Image is a well designed and capable class (ie loading from memory properly).

[crawshaw]

Thanks, I probably will use SOIL directly. I thought a getOGLTexture() function would be unwelcome as it looks like SFML is aiming to be GL-independent (maybe someone will write a directx backend).

And yes, dxt is the way to go, but most encoders are slow, going for quality over speed. I haven't tested SOIL yet, but for my purposes I intend to load a JPEG and encode parts as they are needed. For now i'm just using dds files.

[eleinvisible]

If I remember correctly lonesock claimed to have a really fast encoding method (never checked  :wink: ). And a DirectX backed would interesting to see.

[Laurent]

There's no need to expose ImageLoader, as you can get the pixels of an image with the sf::Image::GetPixelsPtr() function. An example of direct OpenGL texture creation is shown in the OpenGL sample in the SDK.

Regarding DXT compression, I don't know where you saw it but it's not used at all in SFML. Textures are using 32 bits RGBA format.

Finally, getting an image's internal texture identifier is not clean. If you want to use the image directly as a texture you'drather use its Bind() function, which makes a call to glBindTexture. If you want to create a new teture from the image's pixels you can retrieve them with GetPixelsPtr() ,as I said previously.

[crawshaw]

Ah, I was completely misreading a step in the ImageLoader, and somehow got into my head that sf::Image kept two copies around, one in RGBA_8_8_8_8 and the other in DXT. Not to worry then.