Messages

1

Graphics / why does setActive() return false

« on: September 28, 2015, 09:41:53 am »

Hi everyone

i have a problem rendering in a separate thread. Before i start digging everything upside down i hope i just missed something :-) maybe its an easy issue but i'm unable to find an answer in the docs, so for short:

1.
in a separate thread i
- construct a sf::Text, load a font file into it
- construct a sf::RenderTexture and create it to be able to draw stuff on it
- call setActive(false) on the RenderTexture as i read in the docs that i should do that before handing it over to another thread.

after that is done(!), in another thread (main thread actually) i
- call setActive(true) on the RenderTexture
- draw the sf::Text object on it.
- throw the RenderTexture on main window, main-window is constructed in main thread _before_ the separate thread starts.

result:
setActive(true) returns false.
the RenderTexture appears on main window, but without the Text, only its background-color.
There is no error message.

When i do the same stuff in a single thread the little text appears as it should, and even the setActive's i wouldn't need here return true.

what do i fail here? Do i need to deactivate something in the Sf::Text also?


before you ask: I want render stuff in a separate thread because here and there i do intesive calculations (generating animations etc), which otherwise would freeze the displaying thread.


cheers
breakfaster

2

Graphics / Re: about performance ...

« on: June 04, 2015, 10:36:59 pm »

ahm ...

... forgot to mention that the article is indeed very good - just recognized that it is just 2 weeks old - all important points to thing through - remembering my own intense lesson in over-engineering 5 years ago.

What i actually do is a lot of evaluating. I evaluate my possibilities and limitations before i write an application. I think everyone should do that, just to start implementing something into the blue without asking other people how to do it right, thats what i call pre-mature.

So this is my actual approach here
 - i think ahead a lot.
 - i hack in and test all kinds off stuff looking at results/speed/stability
 - understand other people's code before making myself think that i use it right
 - thus i ask a lot of questions not bothering if people may get annoyed by that

maybe i'm just too enthusiastic. I don't care, i like to be like that. ok the way i ask questions may be a little relentless here and there - but sometimes its hard to find answering people.

btw.
graphic-cards with maximum Texturesize of 512x512 are almost not existent anymore. 1024 is save. 2048 is still good to go.
http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_TEXTURE_SIZE

3

Graphics / Re: about performance ...

« on: June 03, 2015, 06:26:35 pm »

Allrighti

thanks for the clear words @arcade - exactly what i needed to know. You know, i have plenty of experience with C++, but i'm a newbie on openGL and how to handle graphic-cards correctly.

Will go the sprite sheet way. Already have a plan how i will organize and group all my stuff - VertexArrays are great -

@eXp: sorry i can't find anything about openGL and graphics in your linked article maybe you meant another one? - or i have bananas on my eyes.

one question about the maximum size of textures - are they any serious graphic-cards in use out there today with a maximum of 512x512 ? I plan to pre-render rooms that may get bigger than that ... and i don't think i will need to support such exotic things and just require 2048x2048, otherwise throw a Messagebox and exit.

4

Graphics / Re: about performance ...

« on: June 03, 2015, 12:59:33 pm »

hey

my concept / direction of product already stands. Next step for me is to find the right way to get most performance out of SFML - to assure that i will find my swarms of minions walk, act and fight smoothly, even when there are 100s of them _visible_. Bethink of all the AI calculations behind them - i simply can't afford wasting CPU time for unnecessary draw calls.

so ...

i looked through the AltSpriteHolder class - not bad - found that it must be faster than the original. However, in the end it still hikes through the RenderTarget::draw for _every_ single Texture displayed - not really what i am looking for.

Looking through the original sf::Sprite source, i ended up going through RenderTarget::draw. Seeing how it works and how Texture::bind works almost gives me the answer that it _is_ advantageous to have the GPU find all textures gathered in one big texture. The SFML sources actually telling me that. But is it really that way?

So i went looking for a place where Textures are changed fast and efficient - and got stuck in Texture:bind() - what's the point about m_pixelsFlipped ? Is it a graphics-card thing that it flips pixels vertically so we are forced to check this flag at _every_ Texture::bind call, which is called in every RenderTarget::draw call? Otherwise this could be done earlier in the loadFrom* functions.

Same with the GLfloat matrix - it could be precalculated outside of Texture::bind and only changed when m_actualSize changes. The whole check for (coordinateType == Pixels) could probably be moved outside bind().

However - Texture::bind should only be used in precalculation/pre-render phase. Pre-render as much as possible !

oh, in the Texture::bind - Texture.cpp Line 487 - i found this
    if (texture && texture->m_texture)
when texture is NULL this will crash anyway. Would change it to
    if(texture) if(texture->m_texture)
or even better just go
   if(texture->m_texture)
   
maybe i'll find more later. Possible conclusion: Better answer my questions to stop me looking through your code 

NO! I don't want to consider rewriting RenderTarget::draw() - that goes too far - i would like to skip caring about openGL issues and just enjoy SFML.

Or should i  ?

i think i will now write my own TileMap class for big Textures full of small ones and see how fast it can become. Or are any suggestions left for me out there ?

regards
Breakfaster

5

Graphics / Re: about performance ...

« on: June 02, 2015, 05:45:30 pm »

Looking at a benchmark test written 8 years ago, do you really expect it to be representative in any way today?

of course not, but it was a funny strange thing to encounter. 

ok, 5000 sprites are unrealistic of course, took it only as a theoretical worst case scenario. But i may hit the 1000 mark - my game will be tower-defense-ish - and i don't want to find it creeping when it gets close to that mark, so ... regarding C++ : i know what i'm doing - and if i wouldn't worry about performance, i could go java or unity. I just want to make sure that i go in the right direction and will finish what i started. My concept is finished - and i will implement it - one or another way.

... in the end you'll have to find a balance between CPU and GPU utilization. Also note that having a few (hundred) draw calls has not that big of an impact on performance.

As usual when it comes to performance, all I can say is: Only start worrying about performance when you actually have a performance issue.
Also see this article.

Thx a lot

but i'm aware of this stuff already. My question is still: Do i have to put my stuff into BIG textures, or is there a faster Sprite way out there?

6

Graphics / about performance ...

« on: June 02, 2015, 05:05:28 pm »

Hey Guys

first a big praise to the dev's. Great work. In the beginning i got fuzzheaded reading through all the stuff that is written about SFML, especially the "SFML is very slow"-alike rants. Finally this benchmark (http://en.sfml-dev.org/forums/index.php?topic=43.0) test is incredibly ridiculous and cheap, made me almost trash SFML and start over with SDL, but i got over that. I am confident that SFML will fit my needs, i just have to use it the right way and expect that you guys did something the right way here.

 

So im actually trying and measuring out a lot of things to find the way to get most performance out of SFML. Started a quick performance test with 5000 sprites per frame at first, realizing that sf::Sprites aren't made up for that. So what now? I will need to throw _hell_a_lot_of_ small textures/tiles and animations on screen ...

The only solution i found until now is using the VertexArray - to set up something like the TileMap class from the tutorial (www.sfml-dev.org/tutorials/2.3/graphics-vertex-array.php#example-tile-map) and put all my tiles, objects and animation-images into one big texture and have it all thrown on display by one single sf::VertexArray::draw call every frame.

But before i go on i wanna make sure - i'm asking myself: "is this really the only useful way to do this?!"  it feels like a weird approach to me. And it is quite a lot stuff to prog for this quite simple task of displaying texture-rectangles.

I need as much CPU as possible for all the other stuff i'm going to calculate in parallel to the graphics rendering. Having called such a big virtual function like RenderTarget::draw for every single tile/object i need on screen is no option for me.

So my question to you guys: Is it really helpful for GPUs to find all their stuff in one single BIG texture - is it worth the effort constructing my own TileMap for everything? Or is there something like a lightweight fastSprite class somewhere out there, which - for instance - lacks for a chubby draw function, but has something like show() and hide() to add/remove it from a batch-list, which draws 1000 small sf::Textures quickly in one draw-call?

which way to go?

thanks in advance for any guidepost :-)