Messages

1

Feature requests / Mixing straight OpenGL with SFML/Graphics

« on: September 21, 2008, 02:13:34 pm »

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.

2

Feature requests / Mixing straight OpenGL with SFML/Graphics

« on: September 21, 2008, 04:36:44 am »

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.

3

Feature requests / Mixing straight OpenGL with SFML/Graphics

« on: September 21, 2008, 01:29:50 am »

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.

4

General discussions / SFML 1.3 and OS X

« on: September 20, 2008, 02:12:18 pm »

Try calling App.Clear() before you call App.Draw().

d.