SFML community forums
Help => General => Topic started by: Tigre Pablito on January 03, 2016, 02:40:46 am
-
Hi Ladies and Guys from SFML
As i was told by exploit3r (i think i remember) i tried to make a reduced sample of my game, and i saw surprised that reduced up to very little, it ran perfectly fast ... but as that it is useless
Then perhaps the problem is the sum of 64 bit system, poor processor 2.3 GHz, and high processor demand
I think perhaps using Threading would solve my ancient problem
Could you give me some guidance about this, and/or tell me where to read or get tutorials of SFML and Threading?
Thanks in advance
Pablo
-
I think perhaps using Threading would solve my ancient problem
Could you give me some guidance about this, and/or tell me where to read or get tutorials of SFML and Threading?
It won't.
OpenGL is not made for multi-threading, so you won't gain anything there, plus multi-threading is an advanced topic. It's required that you have a very good understanding of memory access, sharing, etc. As well as you need to know how to work around all the issues of multi-threading.
In the end you might be able to parallel something, but you won't really gain any performance.
If a reduced example works fine, but your game itself doesn't, it's an indication that your game code is somewhere wasting performance. Use a profiler to figure it out.
-
Hi
Thanks for your reply, eXpl0it3r, i am working on what you told me
For though i think i have performed a bit the speed of the app (reducing to the minimum the number of screen part sprites Draw()'s), it seems the RenderWindow.Draw() method calls take a time that, being too many of them produces an important delay, i suppose
Do you know if Drawing the different object sprites to a unique Sprite and then Drawing it to the RenderWindow will speed up my Sonic app?
Thanks
Pablo
-
A lot of draw calls can lead to some performance issue. This can be mitigated by either, as you kind of suggested, rendering everything that doesn't change often/at all onto a render texture and then use that texture to draw, or by using vertex arrays and batch things, e.g. tile background.
-
What eXpl0it3r said.
2D graphics doesn't take up a whole lot of processing power, but a lot of unnecessary draw calls do. Probably one of the simplest yet very effective improvement you could begin with is to simply not draw what you cannot see.