Questions and problems with sf::thread

[FRex]

Do you have only one huge texture for tileset? Maybe try making a class that takes window reference and then draws chunks of map(each chunk being class object containing small vertex array) that fall in view, it's substantially easier when there is only one texture.

[Brodal]

Nay, I draw  bunch of tiles to several larger textures, 1 texture is x = (1920/2), y = (1088/2) in size. So instead of calling draw for a couple of thousand tiles, I call draw 4 times. One for each of the larger textures containing tiles drawn onto them.

[FRex]

I mean if the things you draw are all from one texture/no texture? And how many tiles do you draw per call?

[Brodal]

I don't fully understand what you mean so I will clarify how I do things. All tiles are their own objects, they do however use references to textures as not to waste memory. These tiles are then drawn onto larger textures. These larger textures are then drawn onto the screen. So the wast amount of small tiles are not iterated often and they do not take long time to draw onto the textures themselves, It's the creation of the textures that is taking to long. The reason that drawing onto the textures doesn't take long is because the tiles are grouped into different std::vectors depending on where on the screen they are, each large texture has a vector associated to it. The reason for this is so I dont waste alot of cpu time iterating through every tile on the screen, I just iterate through the relevent ones. So to the problem is creation of the textures, not the drawing onto them. I have checked this several times with timers and know for a fact that the RenderTexture.create() function is one of the things that is causing the slowdown.

[FRex]

Would it be feasible to merge your tiles into vertex arrays of quads?
(ie : you don't ever move, rotate, scale them, they use one or very few sf::textures for their graphics)

[Brodal]

I have never before used vertex arrays, so it might be possible.  Do you know any site that explains how to use them?. I dont move rotate or scale these, they are static. I do however need to be able to remove and add new ones during runtime. But I'm guessing that wouldnt be a problem when using vertex arrays.

You gave me a very good idea with the usage of very few sf::textures. I can just hold a few textures and change which vector of tiles is associated to which of the textures depending on where the camera is, or something like that. Should take care of all the lag. Thanks alot for the idea!

[FRex]

I mean your tiles, the ones from which the graphics come, not rendertextures, textures, if there is one it's perfect to use vertex array there.
Vertex arrays hold vertices(a 'better point' that is point on texture and point in sfml space, optionally colored) and the form they are supposed to take(the interesting one for tiles is quads, it means that each 4(0-3,4-7,8-11,ect..) vertices will form a 4 sided shape). You have to pass texture pointer as state in the draw call if you want it textured.
The removal and adding(but mostly removal) with arrays might be problematic but class that'd take care of that could probably be written with a bit of trouble.

[Brodal]

I will definitely look into  vertex arrays, as of now I don't really need them i think as I'm running 3 million tiles at 2000 fps. But I will try to implement them anyway, just to learn .

Lag issue fixed, using 1 rendertexture that I pass a pointer to when rendering my tiles. Works like a charm!

[FRex]

That is quite a lot of tiles, arrays won't do probably.

[Brodal]

Vectors work just fine at the moment, as I'm splitting them into several vectors. Don't know how those vertex arrays work though.

[FRex]

Almost everything is in documentation, what isn't is primitives explanation(but that can be googles/guessed) and how to texture them(by passing &texture as second parameter to draw).