Render Targets

[NGen]

I'm considering a move from a DirectX-based library to SMFL, but there's one feature that I cannot find that is preventing me from using it: Lack of render targets. I'm not entirely sure if that's the universal term for it, but think of it like this:

You have a canvas. You can paint onto the canvas, and then take that canvas and put it onto another canvas. That other canvas would be the screen, and the first canvas would be the render target. You draw things onto the target, and the contents of the target could be rendered onto the screen.

Is there any structure within SMFL or any algorithm that could be used to create a rendering method similar to this?

[Laurent]

SFML 2 has render-images, which seems to be what you're looking for.

[NGen]

Alright, when can we expect SFML 2? Not any time soon, I'm guessing? Would it be possible to get at least a basic overview of how it would work? What we're currently using does something along the lines of:

Code: [Select]

// ( width, height ) rounded up to nearest power of 2
HTARGET hTarget = Target_Create ( 800, 600 );
// Begin drawing to the target
Gfx_BeginScene ( hTarget );
// Draw some stuff onto the target
Gfx_EndScene ( );
// Begin drawing to the window buffer
Gfx_BeginScene ( );
// SomeQuad would give the vertices for rendering the target, the second
//    parameter requires a texture, so we get the texture from the target
Gfx_RenderQuad ( &SomeQuad, Target_GetTexture ( hTarget ) );
Gfx_EndScene ( );

I really just need to know how we could make a switch as painless as possible. We're going to be building a high level abstraction layer on top of whatever library we use to allow us to switch from one library to another fairly easily. So I want to create a part of that layer for rendering targets that would give us an interface that would be able to work with both the rendering targets that our library gives us, as well as the render-images that SFML 2 would give us.

[Ashenwraith]

Alright, when can we expect SFML 2? Not any time soon, I'm guessing? Would it be possible to get at least a basic overview of how it would work? What we're currently using does something along the lines of:

Code: [Select]

// ( width, height ) rounded up to nearest power of 2
HTARGET hTarget = Target_Create ( 800, 600 );
// Begin drawing to the target
Gfx_BeginScene ( hTarget );
// Draw some stuff onto the target
Gfx_EndScene ( );
// Begin drawing to the window buffer
Gfx_BeginScene ( );
// SomeQuad would give the vertices for rendering the target, the second
//    parameter requires a texture, so we get the texture from the target
Gfx_RenderQuad ( &SomeQuad, Target_GetTexture ( hTarget ) );
Gfx_EndScene ( );

I really just need to know how we could make a switch as painless as possible. We're going to be building a high level abstraction layer on top of whatever library we use to allow us to switch from one library to another fairly easily. So I want to create a part of that layer for rendering targets that would give us an interface that would be able to work with both the rendering targets that our library gives us, as well as the render-images that SFML 2 would give us.

I know it supports scaling/drawing well because I used it myself. I assume you need it for transforming a texture fast? If so you would transform the sprite before drawing it to the RenderImage.

Here's the source example:

Code: [Select]

/// Usage example:
///
/// \code
/// // First of all: make sure that rendering to image is supported
/// if (!sf::RenderImage::IsAvailable())
///    return -1;
///
/// // Create a new render-window
/// sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
///
/// // Create a new render-image
/// sf::RenderImage image;
/// if (!image.Create(500, 500))
///     return -1
///
/// // The main loop
/// while (window.IsOpened())
/// {
///    // Event processing
///    // ...
///
///    // Clear the whole image with red color
///    image.Clear(sf::Color::Red);
///
///    // Draw stuff to the image
///    image.Draw(sprite);  // sprite is a sf::Sprite
///    image.Draw(shape);   // shape is a sf::Shape
///    image.Draw(text);    // text is a sf::Text
///
///    // We're done drawing to the image
///    image.Display();
///
///    // Now we start rendering to the window, clear it first
///    window.Clear();
///
///    // Draw the image
///    sf::Sprite sprite(image.GetImage());
///    window.Draw(sprite);
///
///    // End the current frame and display its contents on screen
///    window.Display();
/// }
/// \endcode
///
/// Like sf::RenderWindow, sf::RenderImage is still able to render direct
/// OpenGL stuff. It is even possible to mix together OpenGL calls
/// and regular SFML drawing commands. If you need a depth buffer for
/// 3D rendering, don't forget to request it when calling RenderImage::Create.
///
/// \see sf::RenderTarget, sf::RenderWindow, sf::View
///
////////////////////////////////////////////////////////////


[Laurent]

Here is how your code would translate in SFML 2:

Code: [Select]

// Create the render image
sf::RenderImage rimage;
rimage.Create(800, 600);

// Draw some stuff onto the target
rimage.Draw(whatever);
rimage.Display();

// Draw to the window buffer
window.Draw(sf::Sprite(rimage.GetImage()));
window.Display();

Alright, when can we expect SFML 2?

Maybe not sooner than several months. But you can already use it, many users do.

[NGen]

That's very useful, thank you. I'm planning on using it for multi-threaded rendering. Render objects of the same depth on a surface inside of a thread, and then render those surfaces in order of the depth they represent. I know that GPUs aren't generally multi-core (unless you count the shader core in NVIDIA cards), but this should leverage the overhead between all of the cores to speed things up a bit.

One more thing, while I'm here, is there any mechanism that enables editing of pixels through methods other than pixel shaders?

[Laurent]

One more thing, while I'm here, is there any mechanism that enables editing of pixels through methods other than pixel shaders?

There are such mechanisms, but they will all be more or less inefficient because they won't happen on the GPU, and thus involve transfers between the video memory and the system memory.

SFML allows you to access pixel data of images and render targets, either individually or transfering all at once.