Automatic batching in sfml2 branch

[Laurent]

Ok, thanks for your feedback

[Dominator]

- RenderImage must now call Display() like RenderWindow

How does RenderImage work in .NET? It's lacking a Display() method.

[Laurent]

I probably forgot to add it in SFML.Net, thanks for reporting it

[Laurent]

It's fixed.

[Dominator]

Thanks! But I still can't seem to get it to work properly.

The RenderImage won't show on the screen after calling Display().
Are there any usage examples?

I've worked around this by loading RenderImage.Image in a Sprite and displaying that instead, but I have to redraw all the contents of the RenderImage every frame or else it turns black.
Is this behavior intended?

Example main loop:

Code: [Select]


...
RenderImage ri = new RenderImage(200, 100);
Sprite spr = new Sprite();
Shape rect = Shape.Rectangle(new Vector2(1, 1), new Vector2(199, 99), Color.White, 1, Color.Black);

while(app.IsOpened())
{
  app.Clear(Color.Blue);

  //has to be done every frame or else it turns black
  ri.Draw(rect);
  ri.Flush();

  //Display() won't work - wrong place to call it?
  //ri.Display();

  //workaround with a sprite
  spr.Image = ri.Image;
  app.Draw(spr);

  app.Display();
 
  app.DispatchEvents();
}
...


[Laurent]

Is this behavior intended?

Yes
Render-to-image really means rendering to an image, not on screen. So you then have to use a sprite to display it, like any other image.

[Dominator]

Oh, I see. So what's the .Display() method needed for and why turn RenderImages black each frame? It would be nice to be able to keep some pre-rendered images in memory. I tried to copy the RenderImage.Image to a new Image, but then it's just black.

Also the Sprite resulting from an RenderImage is upside down and I have to call Sprite.FlipY() before drawing the Sprite on the screen.

[Laurent]

So what's the .Display() method needed for

Do you know about double-buffering? This techniques uses two buffers: the front buffer (what you see) and the back buffer (where the data gets rendered). When you call Draw(), everything gets rendered into the back-buffer, so that the front-buffer can be displayed on screen without being modified. Then, when you call Display(), these two buffers are switched so that the back-buffer becomes the front-buffer and everything that you rendered during the current frame gets displayed on screen. Then the back-buffer, which contains data from 2 frames ago, can be overwritten with new data and so on...

Well, this is the same for RenderImage: everything gets rendered to a temporary buffer, and calling Display() updates the target image with this temporary buffer (well, this isn't always exactly true, but this is an internal detail).

why turn RenderImages black each frame?

The contents of a render image are not supposed to change if you don't call Clear() or Draw(). Can you show a complete and minimal example that reproduces this problem?

Also the Sprite resulting from an RenderImage is upside down and I have to call Sprite.FlipY() before drawing the Sprite on the screen

Same as above
This is not supposed to happen, and I'd like to see an example.

[Dominator]

Nevermind, I found the problem.  :wink:

First I used Flush() because of the lack of the Display() method.
Then I added Display() right after Flush(), but it still didn't seem to work correctly.
Now by replacing Flush() with Display() everything works - no more black images and sprites aren't flipped.  

Thanks for your effort and keep up the good work!

[Laurent]

That's right, Flush() is needed only if you want to insert custom OpenGL rendering between SFML drawables. But... it shouldn't make any difference, that's still weird. I'll have to look into this.

Thanks for your feedback

[Svenstaro]

What's the status on this? Did you go back or has this actually been implemented? Sorry, I don't feel like reading through the svn log right now.

[Laurent]

There's no more automatic batching in SFML 2. The only optimization left is a cache that avoids setting redundant OpenGL states.

[Svenstaro]

So basically to "simulate" batching manually, groups of lots of sprites (like particles) should be drawn to a RenderImage and then to RenderWindow to save on draw calls?

Also, any chance for automatic batching to make a return or is excluding them a rather final decision?

[Laurent]

No, I'm currently working on a totally different approach. I'll try to provide a lower level API for drawables. Basically, you will be able to define your own geometry, you won't be limited to shapes, sprites or text anymore.

[Svenstaro]

Sounds good, however, as it currently stands, does my approach above sound good for particles?

Also, will your new idea be contained in the first release of sfml2 or is that for some time beyond that?