How does the Draw() work?

[shiroaisu]

Hi

I wanted to know in what circumstances does Draw() actualy draws something on screen.

For example, i made a test with 600 sprites (all with the same image) and when i drawned them all in one location:

Code: [Select]

for (unsigned int i = 0; i < 600; ++i) ship[i].SetPosition(100, 100);

I had better framerate (arround 700 fps) than when i tried to draw them in diferent locations:

Code: [Select]

for (unsigned int i = 0; i < 600; ++i) ship[i].SetPosition(i, 100);

Does that mean that Draw() skips some sprites when they are in the same positions?


And also, if i have a sprite that is offscreen and i call Draw() on it will the Draw() try to draw the sprite or will it recognize that the sprite is not inside the window and skip the drawing process??
Should i then use x and y checks before i try to draw something to see if it actualy is on screen to avoid any unnecessary processing?

thanks for the attention[/quote]

[Laurent]

SFML doesn't optimize anything, each call to Draw draws something. How many FPS do you get with your second code?

[shiroaisu]

SFML doesn't optimize anything, each call to Draw draws something. How many FPS do you get with your second code?

oh sory i forgot to include that, when i drawned them in diferent positions i had... 550 fps average, so i found that a little strange, i really cant find an explanation for it, but if you want i can post here the full code (its just a small test i made so...).

[Laurent]

It's not very surprising, the graphics card has many mystic behaviours, and you often get different results with no apparent reason.

So don't bother too much about that.

[shiroaisu]

I see. oh well...

anyway, thanks for the help

[julen26]

And also, if i have a sprite that is offscreen and i call Draw() on it will the Draw() try to draw the sprite or will it recognize that the sprite is not inside the window and skip the drawing process??
Should i then use x and y checks before i try to draw something to see if it actualy is on screen to avoid any unnecessary processing?

I think it does it automatically. In fact, I proved and FPS gets down when sprites are out of view.

[Laurent]

I think it does it automatically

There's no pixel written for objects that are out of screen, so yes they are skipped at some moment in the rendering pipeline
But it happens very late, and eliminating them before even sending them to the graphics card can still be a huge improvement.

[P@u1]

Why sfml then doesen't do it?
You just need to test for intersection with the view rect for every sprite before making the actual draw calls.

[Haze]

Why sfml then doesen't do it?
You just need to test for intersection with the view rect for every sprite before making the actual draw calls.

I guess this would be an unnecessary (and time-consuming) operation if your application doesn't draw objects outside the screen.

[Laurent]

I guess this would be an unnecessary (and time-consuming) operation if your application doesn't draw objects outside the screen.

Indeed.

And an intersection test would be more expensive than you think, because both the view and the objects can be rotated. It's not trivial.