sf::Window::draw

[Skorpion]

Hi all,

I'm making a game with quiet big rooms with many NPCs and other stuff in them that need to be displayed while playing. This makes a huge number of calling sf::Window::draw() method. To be able to handle such vast spaces I also use sf::View and show only a small piece of that room. And here is my question: how much does it cost to call sf::Window::draw() and would checking every sprite if is it in my view's range be reasonable (won't costs of checking it be bigger than just drawing sprites invisible at the moment)? Or maybe it's already done in SFML, that if something isn't visible it isn't drawn? I try to make my code less expensive.

Thank you in advance for all answers and discussion!

[ka0s420]

hmm, well to cheapen the drawing of say, floor/map tiles, you can use something called a vertex array: http://www.sfml-dev.org/tutorials/2.0/graphics-vertex-array.php, also do a google search for something called, quadtrees, they make it so you have to check less of your entites etc, by having your world subdivided into smaller areas, meaning less checks.

[Skorpion]

Thank you for fast reply.

For the background we use one big image, like 2000x3000 pixels but I'll think about dividing it into smaller parts, if it would help. I'll also use quadtrees for checking collision in more efficient way, because now I am able to check up to 600 collisions in one loop transition and I need like 1700.

[ka0s420]

hmm, well yeah quadtrees will definitley help with collisions checking, and for rendering. dividing the map will definitely help, if only to reduce the size of the one big image at any given time. if you have all your enemies/bullets/etc on one spritesheet then you can also use vertex arrays for them, taking it down to effectively one draw call. So that would help too. Good luck with your implementations!

[eXpl0it3r]

Keep in mind that GPUs have texture size limits, so your big background may not load on slightly older cards.