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.

Messages - zTn

Pages: [1]
Window / Re: [Mac] Fullscreen modes not scaled to screen size
« on: August 08, 2021, 05:23:23 pm »
As it stands, I can't find a solution to this and it appears that my beloved SFML is just broken on MacOS.  Since all other apps/games are not broken by what Apple has done here, isn't this a question of what SFML is doing differently?  I must be missing something.  Can someone explain to me why SFML cannot just do what everyone else is doing?  Anyone?

Graphics / Re: sf::Texture Sizes
« on: December 08, 2018, 07:14:21 pm »
Thanks for getting back NGM88, but to clarify...

(1)  So changing which texture you are drawing with is a (relatively) expensive operation, but the size of the current and new texture has no effect on how long it takes?  (or if so, nothing significant?)

(2) Since I'm generating these textures at run-time with sf::RenderTextures, can't I just query the max supported size with sf::Texture::getMaximumSize() and use that?

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]