Messages

1

Graphics / Re: Regarding the VertexBuffer implementation in Renderables..

« on: March 23, 2019, 12:19:00 am »

I really don't see why, from a technical perspective, what you are trying to achieve is only doable by creating a temporary sprite every frame...

I have a commercial game that has used SFML for 8 years now -- I'm only trying to update to the next minor version of SFML. I'm not sure the SFML team wants it's users to have to re-architect parts of their code for this minor version update. In any case, at least please consider this as a preliminary negative report for this change, instead of dismissing it as an outlier or a worst case usage.

2

Graphics / Re: Regarding the VertexBuffer implementation in Renderables..

« on: March 19, 2019, 02:34:13 am »

And here's some real-world data: after manually disabling vertex buffers in sf::Sprite, my application went from 30-50fps to 60-70fps. Most of my use cases are of the form above, where I construct a sf::Sprite during my render pass.

Additionally, when I turn on debugging in OpenGL, I get many performance warnings regarding the vertex buffers, as I think they are eating up all the memory.

3

Graphics / Regarding the VertexBuffer implementation in Renderables..

« on: March 19, 2019, 12:55:52 am »

This commit has made all the renderables use a vertex buffer if available. Which is great; however, before this change drawables were quite lightweight, and we could create one of these drawables at the last moment. For instance...

loop {

   // construct sprite
   sf::Sprite sprite {...};
   target.draw(sprite);  
}
 

But now, afaict, this will call glGenBuffers and then glDeleteBuffers every frame. If this change is to be preserved I think the docs should not call sf::Sprite lightweight anymore.

4

General discussions / Re: SFML 3: Goodbye OpenGL?

« on: August 25, 2018, 05:34:29 am »

Thanks. In a way there are already multiple backends for opengles and platform specific code.

With the right architecture we may find members of the community creating and maintaining different backends. I know at least one dev at Sony has a Vulcan backend for sfml.

5

General discussions / Re: Game stuttering? It could be Nvidia Threaded Optimisation.

« on: August 25, 2018, 05:29:06 am »

Glad to hear it!

6

General discussions / SFML 3: Goodbye OpenGL?

« on: August 19, 2018, 05:02:12 am »

Is the world moving on from OpenGL, and should SFML 3 follow?

I think at this point an independent graphics backend is the simplest choice for SFML. One which will support webgl, opengl, metal, etc. It needn't implement all these, and could just incorporate a library like bgfx to do all the platform dependent stuff.

I know it might be hard to let go of all the OpenGL code in the library.

7

SFML projects / Re: MoonQuest (OUT NOW!)

« on: July 15, 2018, 08:24:50 am »

Thanks everyone

8

SFML projects / MoonQuest (OUT NOW!)

« on: July 14, 2018, 04:16:29 am »

After 6 years of work my game MoonQuest is now out. I used SFML!

The game is a procedurally-generated adventure game. Here is the website, and the game is available for Windows on Steam. It also has a gameplay trailer:



My experience with SFML has been great. I encountered some issues (google my posts on this forum) but I got there in the end! Thanks again for the great library!

9

General discussions / Re: Game stuttering? It could be Nvidia Threaded Optimisation.

« on: January 25, 2018, 11:38:20 am »

Thanks for the link.

Unfortunately there's never just one cause of stutter. For instance, I had to heavily patch SFML to remove the multiple render target contexts due to stutter. Disabling those glChecks is certainly something to try.

10

General discussions / Re: Game stuttering? It could be Nvidia Threaded Optimisation.

« on: January 25, 2018, 09:44:47 am »

Good to know. In my case I encountered the stuttering with the RelWithDebInfo build. Maybe that calls glCheck, I'm not sure.

11

General discussions / Game stuttering? It could be Nvidia Threaded Optimisation.

« on: January 25, 2018, 03:14:49 am »

Here's a community announcement: If your game is stuttering it may be due to something called Nvidia Threaded Optimisation. See this Stack Overflow thread for an analysis and solution of the issue. The easier way to fix it is to register an Nvidia profile that disables the optimisation in an installer. The key triggers of this problem for me seemed to be Nvidia Card, OpenGL, Multiple Threads, and FBOs.

There are discussions of this in other threads, but I thought I'd make one focusing on this exact issue. I hope some future SFMLer finds this before tearing all their hair out like I've done. It plagued me for years!

12

SFML development / Re: C++ standards

« on: November 13, 2017, 02:55:35 am »

I highly agree with updating the c++ version. Some thoughts:

• c++ core guidelines may be useful when deciding how to restructure some of the api
• clang-tidy/clang-format could help with upgrading the code (though clang-tidy has some flaws)
• enum classes should be used if possible

Don't want to bikeshed, but I'll just to say that less use of auto is better. e.g. the auto here makes the code a little harder to follow:

auto bounds = sprite.getLocalBounds();
rectf bounds = sprite.getLocalBounds();

13

General discussions / Re: Fundraiser for a Mac mini

« on: September 16, 2015, 10:28:41 am »

So glad to be able to donate a little for the project. You guys do a great job!

14

Feature requests / Re: One context per RenderTexture?

« on: September 05, 2015, 01:21:18 am »

Yep, that's one solution, although RenderTexture is a friend of Texture, etc., for a reason. Not all the internals of these things are available to external code -- although you can use glGet to grab the important gl ids.

I had written a reply with a few alternatives but the forum went down just as I posted it, gah. Needless to say there are a few ways around this. But ultimately, a single-context or manual-context system would be the best future for SFML, based on a lot of discussions I've had with other devs about this issue. Up until now, this is the only serious design flaw I've seen with sfml, but at least it's hidden behind the api.

SFML should remain simple to use, but in order to be Fast the devteam may need to consider opening up more of the internals so users can more easily incorporate optimisations.

15

Feature requests / Re: One context per RenderTexture?

« on: September 04, 2015, 03:00:30 am »

Thanks for the great explanation. So a single-context rewrite would eliminate all these extra contexts, but then each sf::Context/RenderTarget would have to manually cache whatever state it needed?

In any case, it seems that using many RenderTextures as they are is out of the question. Unfortunately there doesn't seem to be a nice way to manually write my own single-context FBO code because I need a rendertarget to use SFML's drawing routines. I wonder if you have any suggestions there?