Advice on Background Coding.

[Laurent]

Each sf::Sprite is one vertex array and requires a draw call. So 10,000 sprites are 10,000 vertex arrays and require 10,000 draw calls. That's the reason why it's slow.

But if you create a single vertex array that contains the contents of your 10,000 sprites (which is possible only under certain conditions, don't imagine that vertex arrays are the magic solution to everything), then you end up with a single draw call for your 10,000 quads and it's very fast.

Basically, the overall performance can be measured to the number of draw calls. The number of primitives drawn by each call doesn't make a significant difference (unless there are millions, of course). So, a single vertex array = maximum performances.

sf::Points is not another class, it's just an attribute of vertex arrays that tells the graphics card how to connect/interpret the vertices of your vertex array: either as individual points, as lines, as triangles or as quads.

[Roose Bolton of the Dreadfort]

Each sf::Sprite is one vertex array and requires a draw call. So 10,000 sprites are 10,000 vertex arrays and require 10,000 draw calls. That's the reason why it's slow.

But if you create a single vertex array that contains the contents of your 10,000 sprites (which is possible only under certain conditions, don't imagine that vertex arrays are the magic solution to everything), then you end up with a single draw call for your 10,000 quads and it's very fast.

Basically, the overall performance can be measured to the number of draw calls. The number of primitives drawn by each call doesn't make a significant difference (unless there are millions, of course). So, a single vertex array = maximum performances.

sf::Points is not another class, it's just an attribute of vertex arrays that tells the graphics card how to connect/interpret the vertices of your vertex array: either as individual points, as lines, as triangles or as quads.

Right and so each VertexArray in a sprite contains 4 vertices to make the sprite? So if I wanted to make say a 1024x1024 screen filled with 2 512x512 background textures, I would make a vertexarray with 8 vertex's? so 2 quads and then apply a texture as done in the renderstate?

Cheers for help so far

[Laurent]

So if I wanted to make say a 1024x1024 screen filled with 2 512x512 background textures, I would make a vertexarray with 8 vertex's? so 2 quads and then apply a texture as done in the renderstate?

Yes, but you can only apply a single texture to a vertex array. So you need at least as many vertex arrays as textures.

[Roose Bolton of the Dreadfort]

So if I wanted to make say a 1024x1024 screen filled with 2 512x512 background textures, I would make a vertexarray with 8 vertex's? so 2 quads and then apply a texture as done in the renderstate?

Yes, but you can only apply a single texture to a vertex array. So you need at least as many vertex arrays as textures.

So I dont need to have multiple quad's for the same texture?

EG. I have 1024x1024 area I want filled with 4 256x256 images, but I want the top left to be a brick texture where the others are sky texture.

so; 1 = brick, 2 = sky

12
22

so here I would presume you make a quad for each one, so 4 quads; and apply the texture in the renderstate as required for the drawing of the type?

[Laurent]

But we were talking about vertex arrays in case you want to draw 10,000 point stars. If you have a few big images to display, just use sf::Sprite.

[masskiller]

An openGL orthographic movement (or many) is a rather easy way to simulate background 2D movement, all you need is a texture that can be repeated without looking bad and you move it only when your player sprite moves. You can actually use a relatively small texture and still get nice effects via blending and  the moving of other textures on top of it.

The way the texture is mapped doesn't change unless you make a glRotate call. glOrtho is quite bad at handling real world representations, but it turns out to be very good for stuff like these. If done correctly there'd be no need for using views and a large texture because you are only simulating movement through repetitiveness.

If used plainly it will look dull and boring (it's a repeated texture after all), but you just add another texture on top of it to either mask it or have it "move" together with the base one while playing with the alpha of both it can get to very interesting results.

Edit: This might be an alternate solution if you want it. I had not seen Laurent's post so I wrote this, but I think his solution is better and more natural. I'll leave the post here just in case you want to go through it, but that's up to you.