Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - zTn

Pages: [1]
Graphics / sf::Texture Sizes
« on: December 07, 2018, 11:46:31 pm »
I often find myself creating sf::RenderTextures that are optimized to only contain the minimally complete set of images that I need, and then compose/sort them to reduce the number of times I have to switch between them when drawing each frame.

Question:  What size should I make these optimized sf::RenderTextures?

Should I use the largest power-of-2 size supported by the hardware, or will that be slower since it will take longer to switch between them?  Would it be better to have 3 at 4096x4096 because that means fewer transitions, or is it faster to use 12 at 1024x1024 because now switching will take less time?  Or are they the same because the total amount of pixels transferred per frame is the same?

(I'm not getting a clear answer from tests on the machines I have access to.)

I noticed early on that drawing a default constructed sprite doesn't end up drawing anything.  I've found myself depending on this often.  I make sf::Drawable classes that always { target.draw(m_sprite); }, even when there is nothing to draw. In these cases I simply leave m_sprite in it's default constructed state.  I assumed that this was faster than wrapping all of these draw calls in an if, such as { if (m_willDraw) target.draw(m_sprite); }, because I assumed that somewhere inside SFML there is already such an if that skips drawing the default sprite.  My instinct was to reduce branch instructions in my draw code.  Am I wrong?

Given what you experts know about SFML's inner workings and assuming typical desktop graphics cards and processors (branch prediction especially) -is there a definitive answer, or is it too close to call and I will need to test?

Thanks for any help!

Pages: [1]