Messages

136

SFML projects / Re: SFML Light System - Let There Be Light

« on: November 29, 2014, 11:54:02 am »

Hi lolz123 -

That's wonderful news!  Thanks for revisiting LTBL, and thanks again to eXpl0it3r for helping out as well.

A couple quick notes I have from working with LTBL1, in case it helps with LTBL2.

1.  Transparent hulls visible seam:
When you use transparent hulls, you can see a visible seam between the main umbra and the shadow fins.  I'm pretty sure I tracked this down to being a problem of the fin tris (created by function MaskShadow) overlapping with the main umbra created in that same function.  The overlap results in the dark seam due to rendering the overlapping alpha-blended geometry.

Transparent hulls are a pretty important feature, as without them the shadows appear completely black, rather than using the ambient color.  So I ended up using hull transparency to work around this.

2.  Static QuadTree crash:
There was a crash associated with the Static QuadTree related to these functions:

Code: [Select]

StaticQuadTree::StaticQuadTree(const AABB &rootRegion)
: m_created(false)
{
m_pRootNode.reset(new QuadTreeNode(rootRegion, 0));

m_created = true;
}

void StaticQuadTree::Create(const AABB &rootRegion)
{
m_pRootNode.reset(new QuadTreeNode(rootRegion, 0));

m_created = true;
}

There are two versions of the QuadTreeNode constructor.  The one used above does not pass in a QuadTree pointer.  So the root node of the StaticQuadTree has an uninitialized m_pQuadTree pointer.

This causes a crash later when Update is called on the StaticQuadTree's root node.

My solution was to change the above code to:

Code: [Select]

StaticQuadTree::StaticQuadTree(const AABB &rootRegion)
: m_created(false)
{
m_pRootNode.reset(new QuadTreeNode(rootRegion, 0, NULL, this));

m_created = true;
}

void StaticQuadTree::Create(const AABB &rootRegion)
{
m_pRootNode.reset(new QuadTreeNode(rootRegion, 0, NULL, this));

m_created = true;
}

3.  Offset shadows
If the view dims don't match the screen dims, the shadows are drawn in the wrong place.
This is solved by making this change in LightSystem::SetUp

Code: [Select]

void LightSystem::SetUp(const AABB &region)
{
// Create the quad trees
m_lightTree.Create(region);
m_hullTree.Create(region);
m_emissiveTree.Create(region);

// Base RT size off of window resolution
// *** CHANGE THIS LINE
// sf::Vector2u viewSizeui(m_pWin->getSize());

// *** TO THIS
sf::Vector2u viewSizeui;
// - adding 0.1f for float imprecision so we don't round down to the lower unsigned int.
viewSizeui.x = (unsigned int)(m_viewAABB.GetDims().x + 0.1f);
viewSizeui.y = (unsigned int)(m_viewAABB.GetDims().y + 0.1f);

For this to work, you must also set the m_viewAABB before setup is called.

4.  Window resizing support

LTBL doesn't handle window resizing.  It would need to hook into the resize event, and recreate the m_compositionTexture at the appropriate size.  I believe this is also necessary for view size changes.

______

I very much appreciate the work you've done with LTBL.

137

SFML projects / Re: SFML Light System - Let There Be Light

« on: November 23, 2014, 12:57:33 am »

I've setup my own repository now. It contains all the "historical" source files from SourceForge and I've updated the code base to make it work with SFML 2.x. Besides making sure the CMake script works and the original example builds and runs fine, I haven't done much more on the code base, so if there were other issues, they'll still exist. Let me know which ones and I can fix them, or you can send in a PR.

Based off the LTBL 1.5.1 code base: https://github.com/eXpl0it3r/LTBL

THANK YOU!!!

Keep in mind that there is also GLLight2D, the "sequel" to LTBL according to lolz123. GLLight2D seems to take a different approach rather than representing a refactored LTBL, but you might still take it into consideration when extending the work.

LTBL provides significantly different functionality than GLLight2D. 
I can safely say that most users are looking for what LTBL offers, and not GLLight2D.

GLLight2D is a much more technical approach that allows things like global illumination.  But this is generally not the approach you want to take for a real-time application like a video game.  Especially a graphically "simple" 2D game which would otherwise run on lower level hardware.

Basically, it's just not worth the performance hit.

Quote from the GLLight2D post:

For now, GLLight2D is real time @60fps / resolution of 900x600 on a moderate rig and remains dynamic but looks grainy unless you let it sit there and accumulate samples for a bit. If this is unacceptable, you could then just use it for computing static lighting on level load (a 2D light map). That, or you could just use a blur shader and blur away the graininess (although it doesn't look quite as good then).

That performance is very likely unacceptable for many applications.  Remember, that's just GLLight2D, with no other physics/graphics/AI/game logic/etc running.  He specifically points out 900x600 (tiny) because anything larger is going to have even worse performance.

Lightmaps are generally unacceptable for any kind of dynamic lighting scenario, and add a significant complication to your content pipeline.

138

SFML projects / Re: SFML Light System - Let There Be Light

« on: November 20, 2014, 11:58:32 pm »

Thanks eXpl0it3r.
I'm not sure how I missed that before.

I don't think it solves the fundamental problem of the 1.5.1 LTBL / 2.x SFML compatibility issue.  But it should be helpful to myself and others who are trying to get things working.

139

SFML projects / Re: SFML Light System - Let There Be Light

« on: November 20, 2014, 04:28:30 pm »

So I'd say we have same problem - 1.5.1 doesn't work with 2.1.

Ahh right.  Yes, we both have the same problem.

Does the exe from the first post work for you too?

Yes it does.

140

SFML projects / Re: SFML Light System - Let There Be Light

« on: November 20, 2014, 03:25:13 pm »

Is there the source code of the original example exe from the 1.5.1 zip anywhere?

If there is, I never found it.

It works for me but the code from 2 posts above doesn't and I'm not sure if it's SFML or the above code causing that...

Weird.  As I noted above, I had the exact opposite problem.
What doesn't work with the github code?
How did you get the 1.5.1 code working with SFML 2.x?  (or are you using SFML 1.x?)

141

SFML projects / Re: SFML Light System - Let There Be Light

« on: November 20, 2014, 12:04:42 am »

Update:  the LTBL source from here works with SFML 2.1:  https://github.com/hovatterz/light

Unfortunately it is an older version that ltbl 1.5.1, so is missing some key functionality like LightSystem::SetView.  Between this functional version in github, and the 1.5.1 source, hopefully I should be able to create a working version 1.5.1.

I understand it happens with open source projects, but it's a real shame that ltbl isn't maintained.  I am sure it would be very popular functionality for sfml users as some sort of official add-on.

142

SFML projects / Re: SFML Light System - Let There Be Light

« on: November 19, 2014, 01:16:14 pm »

*** (edit)  See update next post ***

Hi,

I have the LTBL sample compiled and running.  But the only effect I can see is the ambient light.

SFML version:  2.1
LTBL version:  1.5.1

• LTBL source code modified with the sf::Texture::bind and sf::Shader::bind changes as discussed in this thread.

Here's the program, which is copied directly from the Let there be Light manual.pdf
The only changes are:

• changes to compile with sfml 2.x
• changes to compile with ltbl 1.5 - apparently the ltbl manual is out of date.  I needed to change the Light* to a Light_Point*
  
• the call to ls.SetView
• setting ls.m_ambientColor

Code: [Select]

#include <LTBL/Light/LightSystem.h>
#include <LTBL/Light/Light_Point.h>
#include <assert.h>
#include <SFML/Graphics.hpp>

int main(int argc, char* args[])
{
   sf::VideoMode vidMode;
   vidMode.width = 800;
   vidMode.height = 600;
   vidMode.bitsPerPixel = 32;
   assert(vidMode.isValid());
   sf::RenderWindow win;
   win.create(vidMode, "Let there be Light - Demo");

   // ---------------------- Background Image ---------------------
   sf::Texture backgroundImage;
   assert(backgroundImage.loadFromFile("D:/SFML/Let_There_Be_Light_v1.5.1/Let_There_Be_Light_v1.5/data/background.png"));
   // Tiling background
   backgroundImage.setRepeated(true);
   sf::Sprite backgroundSprite(backgroundImage);
   backgroundSprite.setTextureRect(sf::IntRect(0, 0, vidMode.width, vidMode.height));


   // --------------------- Light System Setup ---------------------
   ltbl::LightSystem ls(AABB(Vec2f(0.0f, 0.0f), Vec2f(static_cast<float>(vidMode.width), static_cast<float>(vidMode.height))), &win, "D:/SFML/Let_There_Be_Light_v1.5.1/Let_There_Be_Light_v1.5/data/lightFin.png", "D:/SFML/Let_There_Be_Light_v1.5.1/Let_There_Be_Light_v1.5/data/shaders/lightAttenuationShader.frag");
   ls.m_ambientColor = sf::Color(55,55,110);
   ls.SetView(win.getView());

   // Create a light
   ltbl::Light* testLight = new ltbl::Light_Point();
   testLight->m_center = Vec2f(200.0f, 200.0f);
   testLight->m_radius = 500.0f;
   testLight->m_size = 30.0f;
   testLight->CalculateAABB();
   ls.AddLight(testLight);

   // Create a hull by loading it from a file
   ltbl::ConvexHull* testHull = new ltbl::ConvexHull();
   if (!testHull->LoadShape("D:/SFML/Let_There_Be_Light_v1.5.1/Let_There_Be_Light_v1.5/data/testShape.txt"))
      abort();
   // Pre-calculate certain aspects
   testHull->CalculateNormals();
   testHull->CalculateAABB();
   testHull->SetWorldCenter(Vec2f(300.0f, 300.0f));
   ls.AddConvexHull(testHull);


   // ------------------------- Game Loop --------------------------
   sf::Event eventStructure;
   bool quit = false;
   while (!quit)
   {
      while (win.pollEvent(eventStructure))
      if (eventStructure.type == sf::Event::Closed)
      {
         quit = true;
         break;
      }
      sf::Vector2i mousePos = sf::Mouse::getPosition(win);
      // Update light
      testLight->SetCenter(Vec2f(static_cast<float>(mousePos.x), static_cast<float>(vidMode.height - mousePos.y)));
      win.clear();
      // Draw the background
      win.draw(backgroundSprite);
      // Calculate the lights
      ls.RenderLights();
      // Draw the lights
      ls.RenderLightTexture();
      win.display();
   }
   win.close();
}

Screenshot attached.
It is blue/purple because of the ambient colour setting.  But no light or shadow other than that appears.

Thanks for any help!

143

Feature requests / Re: System specs

« on: October 29, 2014, 11:00:32 am »

You do know that glGetString() and those definitions are part of OpenGL since at least 1.1 right? You don't have to include/link GLEW to access them, because they are provided out of the box, even on Windows.

I didn't know that!  Thanks for the info.  In that case, my request is less important.

(edit)Although I imagine many users might still appreciate it.  Many of us use SFML because we don't know a lot about low level graphics code.

144

Feature requests / Re: System specs

« on: October 29, 2014, 10:23:38 am »

Have you searched before posting? This might be interesting for you.

Unfortunately the links in that post are dead.

I'll add a related request.  I'd really like to see SFML log some basic info about the host computer, or else provide access to this data so I can log it myself.

Here's the most basic info I need:

GL_VERSION = 4.2.0 - Build 10.18.10.3308
GL_VENDOR = Intel
GL_RENDERER = Intel(R) HD Graphics 4600

That gives me the OpenGL version, the driver, and the graphics card.
This is invaluable information when collecting a log from a user who is having troubles with the game.

This info can be gathered with a couple simple calls from glew.h

Code: [Select]

glGetString(GL_VERSION);
glGetString(GL_VENDOR);
glGetString(GL_RENDERER);
This is what I do in my own project currently, to add this info to the log.  But I'm sure others would appreciate it.  And it would be nice if I didn't have to include/link to the glew stuff in my core app, but instead just rely on the SFML graphics lib.

145

Graphics / Re: Box2d body and sfml sprite drift out further away from window origin

« on: October 04, 2014, 08:28:07 am »

It's tough to say without more code, but how is it you can tell where the box is in relation to the sprite?

You chose a scale of 1 physics unit = 30 pixels, which is fine.  Are you sure you are using this 1:30 conversion everywhere?  For example when sizing the physics shape?  Or testing the position of the physics shape?

146

Graphics / Re: stuttering on some hardware, not others

« on: October 03, 2014, 12:47:45 am »

@binary1248
Agreed with everything you wrote.  But I should point out that it was the default option ("Auto") that was causing the stuttering.  Only by explicitly setting this option to "Off" did the stuttering go away. 

While it is very useful to find this work-around (changing a setting in the NVidia control panel), this still presents a pretty nightmarish situation if this is a requirement of the released product.  I've got some more investigation to do.

Just because some OpenGL code doesn't play 100% smooth on a specific system with a specific GPU and driver

Agreed. 
Although that is very different from what I said.  Just to stress it a third time in bold and italics I would only do this *if* it proved to be a OpenGL-specific problem that affected a lot of users.

Sure cross-platform support doesn't seem like a big deal when starting out development on one system, but once you're ready to release a game and can only serve one platform, you'll very quickly regret it.

I fully agree on the importance of cross platform.  It was a significant factor on why I choose SFML.

For what it's worth, I ported my last game to linux as well as windows.

147

Graphics / Re: stuttering on some hardware, not others

« on: October 02, 2014, 11:15:34 pm »

For anyone interested, here are some links discussing stuttering and performance problems with NVidia's "Threaded optimization" across many different OpenGL and DirectX games. 

Minecraft (OpenGL-based)

Go into Control Panel (should be in your start panel button, if not just search for it), click Appearance and Personalization, then go to NVIDIA Control Panel and turn off threaded optimization, and it should work.

GTA IV

Since the 180.84 drivers nVidia f*cked up this game completely. They added a so called "GTA IV Optimization" into their drivers from that point on. And it just made it stutter like hell for at least 30% of the players.

However, I found that if you disable "Threaded Optimization" in the nVidia control panel, the stuttering issue is eliminated 90% of the time on all nVidia drivers, old and new.

I know this because I have at least 20 coworkers who have had that problem. Deactivating the threaded optimization worked for 17 of them.

Diablo 3

Hi Guys,

was having a play around on the weekend, still get massive latency issues but here are some options that fixed my framerate.

Optical Occlusion - OFF
Pre Rendered Frames - 0
Threaded Optimization - OFF

I have done a few other things but the Threaded Optimization was what fixed the stuttering.

Alien Arena (OpenGL-based)

Just wanted to post this in a dedicated thread to make it easier to search:

Make sure to turn OFF Threaded Optimization in your nVidia control panel (do not leave on Auto). Twice now this has gotten the better of me and it was only luck that I rediscovered an old thread to remind me. For me there is a significant performance increase with it OFF as opposed to Auto (default).

With each driver update you should check it again and make sure its still off. I had mine off but when I checked again, its back on (Windows). Linux does not have this in the nVidia control panel, you have to use: export __GL_THREADED_OPTIMIZATIONS=0

Keywords:
Video, FPS, nVidia, frame rate, choppy, stutter, jitter, performance, settings

Arkham City

I turned off "Threaded Optimization" in Nvidia Control Panel and it seemed to work wonders for me. I get stuttering before but it seemed fixed when I turned of Threaded Optimization. Worth a shot for Nvidia users having problems.

Diablo 3

Turning Threaded optimization off, in the nvcpl helps alot, turning on triple buffering also helps a bit, but it's still not gone.

Oblivion

In the Nvidia drivers control panel, under 'Manage 3D Settings', and in the profile window there is an option labelled 'Threaded Optimization' which can be set to Off, Auto or On.

Now i'm guessing it has something to do with the way multi-core CPU's handle in game visuals and the like. A lot of people think it produces nothing but bad results when left to Auto or On....and I can concur that Oblivion for example would stutter and crash while I had this forced on.

Testing NVIDIA's Linux Threaded OpenGL Optimizations

The HTML documentation bundled with the driver binary goes on to explain:
"The NVIDIA OpenGL driver supports offloading its CPU computation to a worker thread. These optimizations typically benefit CPU-intensive applications, but might cause a decrease of performance in applications that heavily rely on synchronous OpenGL calls such as glGet*.

NVIDIA "threaded optimization" oxymoron

So I pulled out Process Explorer and looked at the threads, lo and behold there is an opengl thread using a whole core on its own. I looked at the stack trace and saw this thread was doing the VSYNC. This confused me, because another thread was apparently also doing this, why do you need two threads to do the same thing? Especially something so costly? Well as it turns out, NVIDIA calls this an optimization, threaded optimization, and guess what, it's enabled by default.

148

Graphics / Re: stuttering on some hardware, not others

« on: October 02, 2014, 10:54:51 pm »

After analysing the uncompressed video frame by frame

I really appreciate your thoughts and effort on this binary1248.  Super cool of you.

Let me give an update before I respond to the rest of your post.  If I turn off "Threaded optimization" in the NVidia Control Panel, the problem seems to disappear.  I'll talk more about this in a separate post following this lengthy one.

I have come to the conclusion that frames aren't being dropped. A frame just happens not to be synchronized, and delayed to the point it gets swapped right before the next one does, leading to the appearance that a frame has been skipped.

So this would have the effect of displaying the same frame twice, correct? 

Now consider, what I just said with having too many or too little frames works out nicely if you produce around a multiple or fraction the amount of frames compared to the vsync rate. What if you produce something in between, that doesn't fit so nicely?

With vsync off, the game runs at ~450 fps.  So this doesn't appear to be the case.  Apologies for not providing this info in the original post, but I did a lot of testing and wasn't sure what info would be relevant or not.

If you write code that depends on having a constant framerate, sorry to be the bearer of bad news, but it simply won't work. You haven't posted any code whatsoever, so based on what I've seen on this forum recently and in the past, I cannot exclude this possibility. If you have thought of this already, then you can ignore what I just said, but showing a bit of code would still be helpful.

I totally understand you bringing this up.  My code is not dependent on a constant framerate. 

Not only was it downloaded > 6 months ago, it is almost 1.5 years old, and many fixes behind the current master.

Ok, I'll grab latest.

Perhaps... but drivers have gotten better and better over the years, and I think such a prominent "issue" would have been fixed long ago, since this would have affected any OpenGL application.

Interestingly, stuttering problems with threaded optimization (both on OpenGL and DirectX apps) seem to be pretty common.  I'll link some stuff in my next post.

It is true that SFML uses legacy OpenGL code, but I don't know where you got the misinformed idea from, but it does not have any impact on whether stuttering might occur or not.

Let me justify my thoughts.  I am doing so because I recognize your much greater expertise in SFML/OpenGL, and find the opportunity to discuss this with you highly educational.

I was trying to identify differences between my SFML-based game and other games which operate properly on the NVidia card.  (Legacy) OpenGL is one of those differences. 

In researching the "threaded optimization" NVidia option, I came across many cases where specific driver instances led to stuttering.  These were often fixed in subsequent driver updates. 

I don't know to what extent legacy OpenGL driver code diverges from current OpenGL driver code.  But, as you discussed, deprecated code is generally marked as such because either 1.) it will cease to be maintained, and/or 2.) it is a sub-optimal way of doing things.  In either case, it likely receives less driver support, as more programs migrate to the modern recommended API. 

For example, there was a certain NVidia driver in mid 2012 where "threaded optimization" was blatantly broken and caused widespread stuttering.  It is conceivable that these types of driver problems may linger longer in deprecated OpenGL.  Again, this is just a hypothesis.

You haven't even ruled out that it might not happen on certain AMD or even Intel cards. Again... necessary condition.

Absolutely true.
I was just making some guesses based on the known information so far.  Testing the game on a wider range of hardware will certainly add clarity to the issue.

This can probably be considered a lesser manifestation of shotgun debugging, and Microsoft is obviously happy that many misinformed people still think like that. Before transitioning to another library, or even different code using the same library, understand what the problem is and why the change might make a difference. Simply saying "I don't know how that fixed it, but all I care about is that it seems to be fixed." isn't considered good software development practice, and often is the result of badly trained or lazy developers.

Well, I consider myself neither badly trained or lazy. 

There is likely a very different mindset between an indie game developer and an open source library dev such as yourself.  I need to be lazy in the sense that the path of least resistance is a crucial factor in my engineering decisions.  Otherwise, I simply would not finish my projects, or else spend too much time on low level engineering issues at the expense of coding and polishing gameplay.  Now, the path of least resistance is not the only consideration.  If it were, I would likely be using something like Unity3D rather than building a game engine around SFML.  I choose SFML because I dislike working in a "scripted sandbox" such as Unity, and much prefer to have access to all the source code in my project.

Given infinite time, I could absolutely understand what the problem is and why the change might make a difference.  But I don't have infinite time, so I must set boundaries before resorting to "shotgun programming".  Given the evidence so far (works on ATI on different machine, works on intel card of same machine, does not work on NVidia, other DirectX games do work on NVidia), NVidia OpenGL driver issues are an obvious candidate for consideration.  *If* (and I stress if, as I did in my original post) SFML/OpenGL/driver issues repeatedly plagued the project, and the solution to these issues lay in closed source NVidia driver code, or low level SFML/OpenGL code (which is beyond my current expertise to fix), switching would be a reasonable consideration.  But that is just one potential outcome of many.  And please do not interpret this as a criticism of SFML code, which I find to be excellent code to work with.

Hopefully that provides some insight into my (I think reasonable) mindset.
I certainly agree much more investigation is warranted before such a drastic decision.

Please, don't be one of these people. I still have hope that you can rise above that.

And before more people ask. No, Direct3D support in SFML will not be coming before SFML 3. Even if we decide that it is doable, I am certainly not going to invest my unpaid time promoting a graphics library that has done nothing but mislead and stab people in the back time and again. When it comes to open source development, I am strongly driven by my morals, and Microsoft has violated them in too many ways already.

I'll try not to be.    I necessarily mix my morals with some pragmatism, but I understand and respect your stance.

149

Graphics / stuttering on some hardware, not others

« on: October 02, 2014, 09:23:51 am »

Hi,

I have noticed my SFML game experiences stuttering or frame loss on some graphics cards, but not others.

which shows the problem.  Although the video compression makes it appear worse than it actually is.  In the non-compressed avi captured using FRAPS (264mb download here), the motion is smooth except when the stuttering occurs.

I noticed the stuttering on my laptop, which has 2 graphics cards:
1.  Intel HD Graphics 4600 (integrated)
2.  NVIDIA GeForce GT 750M

Interestingly, the stuttering occurs only on the more powerful GeForce, but not on the Intel.

I also tested the game on my desktop, which has an AMD Radeon 7700 card.  The game runs perfectly smooth there.  So:

• NVidia (Win8.1 laptop):  Significant stuttering.  Other (non OpenGL) games run fine on this card.
• Intel (Win8.1 laptop):  No stuttering
• AMD (Win7 desktop):  No stuttering

The game was tested in fullscreen, with vsync on.  All drivers are updated.  I am using a SFML 2.1 stable release which I would have downloaded probably >6months ago.

Given the different behaviour on different cards, maybe it is an NVidia OpenGL driver problem.

Questions:
1.  Has anyone else experienced this kind of issue with SFML?
2.  Is NVidia known to have crappy OpenGL drivers?
3.  Have there been any recent changes to SFML that might address this issue?
4.  It appears to be an OpenGL-specific problem.  Is it possible it is because SFML uses old/legacy OpenGL?
5.  Any ideas on how to fix it?

My biggest concern is that this problem will affect all, or even a significant portion of NVidia users.  I really like SFML, and have already written a lot of code around it.  But *if* the problem is OpenGL specific, and there is no work around, I may have to consider migrating to DirectX-based graphics middleware.  Unless maybe SFML plans to support a DirectX back-end. 

Thank you very much for your time and help.

150

General discussions / Re: AW: Re: SFML 3 - What is your vision?

« on: September 15, 2014, 02:11:19 am »

\However one should also not forget that developing for consoles usually comes with a licensing price to begin with, thus officially porting SFML to such "pay-first-develop-later" platforms probably won't happen, unless there are generous sponsors or something.

I understand eXpl0it3r, and that makes sense.
But it only applies to one of the 3 steps involved

• decouple the rendering backend (opengl) from SFML
• create a DirectX back-end for SFML
• create SFML console port(s)

Of course console ports may not be realistic for the SFML team (without the generous sponsors).  But the other two steps at least do not have the licensing issue.  One or both would be extremely helpful.

Ogre3D is an open source example (MIT licensed) that does exactly what we're discussing, except in 3D rather than 2D.  I just mention it as a reference.  The sample programs begin with a startup dialog which allows you to select the render system (OpenGL, DirectX).  And the code demonstrates one approach to creating a render system independent graphics API that can hook into different back ends.  Anyway, I am highly encouraged you are considering some work in this area, and just wanted to express my enthusiasm for the idea.  I am sure, given the quality of the SFML code, that should the SFML team pursue this, the code will be very well done.

Regardless, I am highly appreciative of SFML and the team's work.  But since we're discussing the future of SFML, this would probably be the single most important change for SFML to bring in a larger audience of professional studios.  I'm pretty new around here - I'm not sure whether this is important to you or not.

Thanks for your time!