Lots of Objects in Game and SFML2

[scorch]

So, I'me building a 2D game engine and the main purpose is to create a top-down open-world shooter. Of course, open-world means lots of objects. So, I've searched in the foruns the best way to do this without decreasing performance a lot, however most of the topics were about SFML1 and Laurent stated that he wanted to change this stuff in SFML2. I've came to this conclusions, but I would like your opinion about them and more solutions, if you know any.

First, when loading the game the engine will compose a huge image with the objects that won't change during gameplay, like roads, buildings, etc... This can't be done when compiling because the maps will be dynamic.

Second, I'll try to render only stuff onscreen. I mean, if some object isn't visible, the engine won't even call the SFML draw function. I don't know if SFML handles this internally, so I'm not sure if this will make a big diference. The only problem about this is that I'm planning to use lights, and I'm not sure how to get over this problem. For example, if a light source is outside the screen, but close enough to get its light seen, it won't get rendered and that can be kind of akward. The only solution I see is to have a function for each kind of object that with it's given size and position determines if it is rendered or not.

Third, for not having to go through all the objects, I'll probably build some structure like a quad tree to make searching faster.

Fourth, I'll load objects as the player get's closer to them.

Thanks in advance,
Scorch

[Laurent]

First, when loading the game the engine will compose a huge image with the objects that won't change during gameplay, like roads, buildings, etc... This can't be done when compiling because the maps will be dynamic.

I'd rather recommend to build a huge vertex array. This way you don't depend on the graphics card limit for texture size, and you keep a geometric definition of your world (you can move things, change colors, texture coordinates).

Second, I'll try to render only stuff onscreen.

Good thing, but it mustn't break optimization #1 (grouping stuff into large batches). You must find a good balance between these two optimizations.

The only problem about this is that I'm planning to use lights, and I'm not sure how to get over this problem.

The "logical size" of a light must be its total lighting area, not the size of the object that emits the light.

Third, for not having to go through all the objects, I'll probably build some structure like a quad tree to make searching faster.

Using a paritioning structure is a must for good performances, both in rendering and in logic (for computing collisions, searching entities, ...).

[Jove]

Using a paritioning structure is a must for good performances, both in rendering and in logic (for computing collisions, searching entities, ...).

Indeed. I made one recently and was staggered by the performance gain in collision tests.

[scorch]

I've built a Quad Tree, bu now I have a question: What's the best way for making it possible for the user to push objects forward and back? Perhaps a z-index property in the object class, or a list with references for all of them?

[Jove]

Personally, I create a std::multimap of all objects that need to be drawn to the screen. The key value is the priority level of the object (0-255). Since the multimap is auto-sorted on that key, all objects are in the correct z-order for drawing and their place in the order can be changed dynamically from frame to frame.

[Celtic Minstrel]

Interesting... I had a drawing queue that I set up using a custom struct, a fixed number of layers, and an unordered_map with the tile location as the key (and actual screen location among the attributes), but now I'm wondering if I should think about switching over to a multimap... it sounds like it could be a lot simpler, provided I can make it work for what I need.

(The aforementioned system was written before I switched from SDL to SFML, so it may have been flavoured by that somewhat; I didn't really have an equivalent of the Sprite object to work with.)