[SFML] ECS Architecture Efficiency

[MakaiKing0]

Hey all, I have been working on a game engine using an ECS Architecture with SFML.  I've made several engine versions and I'm hoping to get some idea of where I should be aiming goal wise as well as some ideas on how to make my code more efficient.

Specifically I'm looking at the total number of game objects that can be rendered to the game window simultaneously before rendering drops below 60 FPS.  I'm running my engine using a semi-fixed update cycle with a max of 25 UPS and a semi-fixed render cycle with a max of 60 FPS.  I'm also calculating the total maximum potential cycles as a guide, that is the total actual number of times the game-loop loops itself.

My first engine version was able to render as many as 75 objects to the screen simultaneously before dropping below 60 FPS.
My second engine version was able to render as many as 2,300 objects to the screen simultaneously before dropping below 60 FPS.
And my third engine version was able to render as many as 12,000 objects to the screen simultaneously before dropping below 60 FPS.

So if anyone is an experience C++ programer making game engines with SFML any advice and stats of your own engines to compare mine to would be awesome!

[DarkRoku12]

I´m developing a Lua game engine with SFML too, almost finished in windows and with a partial port in Android.

Targeting 16.66ms per frame ( ~0.01666 seconds ) (60 FPS) depends of several things.

Proccesor, graphics card, RAM speed, disk speed.
FPS can vary across computers so the game engine needs to be reliable running at high frame rates as a low frame rates.

"12,000 objects" its a unclear measure.

Its different to render a 72x72 sprite than a 250x250.
The window's size matter too (needs to render less pixel with lower resolutions)

Develop a good game engine its not only the performance.
The interface between the code and the programmer matters a lot too.
A good set of libraries and facilities its essential to include in the package.

If the programmers will develop in C++ will be easy to include Thor and Selba Ward , among others.

[MakaiKing0]

Hhmmm, I see your point there.  I didn't really give a good basis for my analysis comparison.  Thanks for the resource links.  I was actually aware of Thor and Selba, but I'm not interested in using any libraries or APIs, I prefer to build everything myself.  Good Practice!

[Mr_Blame]

Things for to do with SFML:
1.) reuse texture objects(do not make textured trip load data to them instead)
2.) use vertex arrays for for big stuff(e.g. tile map)
Usual things for C++ in order to optimize your code:
1.) use references(e.g. pass const std::string& instead of copying)
2.) avoid constant memory allocations using new/delete/malloc/etc.
3.) precalculate slow formulas

[MakaiKing0]

Yah.... I think everyone knows that most basic of knowledge.... play again.....

[Ricky]

Things for to do with SFML:
1.) reuse texture objects(do not make textured trip load data to them instead)
2.) use vertex arrays for for big stuff(e.g. tile map)
Usual things for C++ in order to optimize your code:
1.) use references(e.g. pass const std::string& instead of copying)
2.) avoid constant memory allocations using new/delete/malloc/etc.
3.) precalculate slow formulas

People underestimate how flattening an algorithm into one big function actually makes room for more optimizations.

[Elias Daler]

First of all, you should profile your existing code and see what is doing lots of work and try to optimize it. It's hard to predict what slows the code down and most of the predictions people make are usually wrong.

After you've run out of obvious things, you can try reducing the number of draw calls by using VertexArrays (aka sprite batching). Another optimization is trying to use CPU cache more efficiently by putting stuff close to each other in RAM. I don't think it can easily be done with rendering though.

And by the way, seeing how much stuff you can draw at once is only one of the benchmarks you can do. It only represents one side of your engine.