Format types for RenderTexture

[Groogy]

I am not entirely sure if this is possible. Looked at OpenGL documentation and in the source of SFML but couldn't really find it anywhere.

What I'm talking about is specifying the target texture format. Like for instance the format of a normal render texture is R8G8B8A8 unsigned normalized float(0-1 range). I think it should be that as well in OpenGL. And for a HDR texture it is R16G16B16A16 float(single precision range). And so on. There are about 20 different possible formats and they all have their unique uses and are both the only way to achieve some post processing effects to also being optimizations.

I don't feel it's out of range for SFML to implement it as fragment shading is becoming more and more used in 2D games. But since I couldn't find anything in SFML's source that actually set a format I have no idea if it is possible. But it would be very weird if you couldn't or I might just be blind or looking at something wrong. Or maybe OpenGL doesn't support it until OpenGL 3.0?

The interface wouldn't be that alien, would be much like how windows does with style I guess.

Code: [Select]


class RenderTexture
{
public:
    void Create( unsigned int aWidth, unsigned int aHeight, sf::Uint32 aFormat = sf::Format::Default, bool aCreateDepthFlag );
};

The only real difference for interface is handled in GLSL. The return value in the fragment shader is different but that's part of OpenGL and not SFML.

Use-cases for this feature would be(And yes I am thinking out of a 2D perspective):

• High-Dynamic-Range colors
• Shadow buffers
• Glow effect(Not bloom but artist controlled glow)
• GPU-based custom calculations(Like average luminance)
• Fog of war(Could count to above)

Those are the uses that I personally have used this feature for and there might be things I have missed. Some of these can be calculated using the default texture format but then we have like HDR colors and glow effect that requires a more advanced format.

Edit: Actually found where it is done:

Code: [Select]

GLCheck(glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, myTextureWidth, myTextureHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL)); So I guess for something like HDR texture it would be GL_RGBA16 and GL_FLOAT right instead?

[Laurent]

These formats are supported only by recent hardware. Other (well supported) formats are rather useless, except maybe luminance and YUV.

I've always wondered whether supporting multiple formats would be a good idea or not. Sure it would allow more powerful/optimized stuff, but it would also make the image/texture API tricky to use: what type do GetPixel/SetPixel/GetPixelsPtr/Update/... take or return? It would have to be void* or char*, and then it would be up to the caller to interpret it according to the format. Like in SDL. And I found this really ugly.

[Groogy]

Well yeah that's a problem.

But doesn't that only appear in Images? Images can always only be in the default format and when converting a texture to an image a conversion is made to fit the expected type. Then if the user really wants raw data he can use OpenGL to access the texels. If he wants that then he probably is a more advanced user and "simple" is not good enough for him

For update on texture. It already uses more or less a "raw" pointer to data. So I think doing conversion there isn't necessary. Though you could provide that as well to stay consistent.

Anyway to every solution there is a problem ^^ But the question is how simple it is. I guess you could limit the number of available of formats to make it as simple as possible. More or less only support the bare strap. For instance I think integer textures are well supported on older hardware right? You can fake floating point by baking in the data there. So supporting maybe these kind of types could be considered?

Or you could provide a way to give a "texture handle" to the render texture just as you can with windows and window handles? That would simplify a great deal for you while not removing a good feature. Though it might look little like a quick feature creep.

[Laurent]

For instance I think integer textures are well supported on older hardware right? You can fake floating point by baking in the data there. So supporting maybe these kind of types could be considered?

Float requires at least 16-bit components. Integer can provide at most 8-bit components. I can't fake floats with integers -- if it was that easy it would be supported even on old hardware.
And anyway, it would require too many tricks on user side (in fragment shaders).

Or you could provide a way to give a "texture handle" to the render texture just as you can with windows and window handles?

I'm not sure that I would be able to manage the texture if it has an unknown format. Something would probably be messed up in sf::Texture.

[Groogy]

I'm not sure that I would be able to manage the texture if it has an unknown format. Something would probably be messed up in sf::Texture.

It probably would. But you could special case this. Creating sf::Texture with a texture handle can be hidden behind sf::RenderTexture and textures that were created this way is not allowed to be used in any way other than bound(being rendered by a sprite should still work).

It might sound bad but it isn't that horrible actually. Because you can render the "alien format" to a known format like unsigned char RGBA and let OpenGL do the conversion.

Code: [Select]

sf::RenderTexture sceneTexture;
sceneTexture.Create( resolution.width, resolution.height, alienTextureId );
/* Render to sceneTexture */
sf::Sprite sceneSprite( sceneTexture.GetTexture() );
window.Draw( sceneSprite ); // <- Window being completely normal sf::RenderWindow

sf::Image emptyImage = sceneTexture.GetTexture().CopyToImage(); // Returns an empty image and prints out to sf::Err


What do you think or do you think it breaks the API too much? Writing this oneself is not that hard if you need it and it is a quite advanced feature that I am more or less trying to simplify.

[Laurent]

I think that a feature supported by only a subset of the API is even worse than not adding the feature at all. So either I add texture formats properly, or I don't allow it at all.

I'll add a tracker issue and investigate it later. With a lot of luck, maybe it could be added nicely to the current API

[Groogy]

I'll add a tracker issue and investigate it later. With a lot of luck, maybe it could be added nicely to the current API

In the mean time I'll hack something ugly together

[Groogy]

Actually an idea sprung to mind....

Could you not solve the issue with the GetPixel/etc. functions by using templates? The template argument describes how the pixels are packed more or less. Not entirely sure of how it would be implemented in all but something like this:

Code: [Select]

template< typename Type = sf::Color >
Type GetPixel( const unsigned int x, const unsigned int y )
{
int index = /* Calculate index from x and y and sizeof( Type ) */
Type pixel;
memcpy( &pixel, &memory[ index ], sizeof( Type ) );
return pixel;
}

Just putting it here for consideration to when you actually decide yes or no.

Edit: Oh damn, just saw the issue on the issue tracker. Put it there as well.

[ShqrdX]

Any updates for this request ? I need R32F format for fluid simulation in fragment shaders