Performance questions

[Felheart]

Hello,

1) should I reuse "Shape.Line" objects?

2) Does it impact the performance negatively when I create a new Line object every frame?

3) Are Shape.Line, Shape.Circle, ... only proxys that are drawn with a shader?

4) Are "Shapes" drawn in a batch?

5) I've read that batching is not yet implemented.
When will it be ready? Will it be like batching in XNA or something like that?

(using C# if it matters)

[Laurent]

1) should I reuse "Shape.Line" objects?
2) Does it impact the performance negatively when I create a new Line object every frame?

Nop, there's nothing precomputed inside shapes objects.

3) Are Shape.Line, Shape.Circle, ... only proxys that are drawn with a shader?

No, they are simple geometric shapes, decomposed in triangles.

4) Are "Shapes" drawn in a batch?

Nothing is batched in SFML.

5) I've read that batching is not yet implemented.
When will it be ready? Will it be like batching in XNA or something like that?

It's not officially planned. If I implement it, it will most likely be an internal optimization and not appear in the public API.

[Felheart]

1) should I reuse "Shape.Line" objects?
2) Does it impact the performance negatively when I create a new Line object every frame?

Nop, there's nothing precomputed inside shapes objects.

3) Are Shape.Line, Shape.Circle, ... only proxys that are drawn with a shader?

No, they are simple geometric shapes, decomposed in triangles.

4) Are "Shapes" drawn in a batch?

Nothing is batched in SFML.

5) I've read that batching is not yet implemented.
When will it be ready? Will it be like batching in XNA or something like that?

It's not officially planned. If I implement it, it will most likely be an internal optimization and not appear in the public API.

So we will have no control about the batching process?
Why not something simple like the XNA spritebatch ?
We already have the "Drawable" class as base, so it shouldn't be a big problem?
Or is there a good reason why you want to implement batching without public access ?

Also, what are major performance pitfalls with SFML?
I use one soundbuffer per soundfile and assign it to multiple "Sound" instances already, the same with Texture and Sprite.
I also have reduced allocations per frame to a minimum already.
But are there any other things I should be aware of ?

My game draws (every frame) the map, consisting of ~2000 Sprites(already culling offscreen tiles with a grid, so its extremely efficient), the interface consisting of ~100 Rectangles/Sprites, and enemys + player.
The particle system adds another 2000-3000 particles(not culling offscreen particles)
With this setup the game runs with ~15-20fps
My computer: Q6600, nv8800gts, 4gb ram.

I think this should be faster.

Is there anything I can do to improve performance ?

edit: I made a small test.
I can draw 10000 Shape rectangles when I initialize them once.
When I'm using Sprite, 2800 is already the maximum. (until the game gets unplayable)
When I create new Sprites or Rectangles every frame, I can only draw one fifth!!

[Laurent]

Or is there a good reason why you want to implement batching without public access ?

Yes, a very good one: I hope that the internal optimizations will be enough so that I won't have to pollute the global API with explicit batching. And the new graphics API in SFML 2.0 will allow to create your own geometry, so for example you'll be able to create a tiled map as a single graphics object (which is a kind of batching).

Because my particle engine can't draw more than 3000 particles before it starts to lag...

SFML 1.6 is definitely too slow for this.
SFML 2.0 (current) is better if you draw multiples sprites that use the same texture.
SFML 2.0 (future) will be much better, just wait a little bit

[omeg]

Creating many objects every frame is a bad idea. Not because of SFML internals, but because .NET's garbage collector will need to collect them very often. Hence your performance drops.

[luiscubal]

Creating many objects every frame is a bad idea. Not because of SFML internals, but because .NET's garbage collector will need to collect them very often. Hence your performance drops.

.NET garbage collector is very efficient when collecting short-lived objects, though.
If this is a concern, you could always use structs instead of classes, but be aware of the implications this has.

[Felheart]

Creating many objects every frame is a bad idea. Not because of SFML internals, but because .NET's garbage collector will need to collect them very often. Hence your performance drops.

I also have reduced allocations per frame to a minimum already.

The problem is simply the drawing a large amount of sprites.
But Laurent said it should get better when internal batching is ready.
I hope this will be finished soon