Messages

46

Window / Re: SFML 2.5.0 - Crashes when using sf::Clipboard::getString() in Linux

« on: May 12, 2018, 02:30:39 pm »

I can reproduce this error with this code:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(200, 200), "Test");

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        sf::err() << sf::Clipboard::getString().toAnsiString() << std::endl;

        window.clear();
        window.display();
    }
}

Will work on a fix.

47

Graphics / Re: sf::RenderWindow and resetGLStates()

« on: April 20, 2018, 08:47:05 pm »

Why aren't you checking for errors after every OpenGL function you call?

48

Window / Re: DInput update appears to cause an exception with Steam API

« on: April 16, 2018, 06:40:16 pm »

Checking if and who is using DirectInput is not something we can do across process boundaries. Probably by design and by chance.

The whole idea behind the COM and IUnknown interface that DirectInput also uses is that you grab a handle to the interface before using it. This increments an internal reference count. When ->Release() is called, the reference count is decremented and when it goes down to 0 it is destroyed. Nothing new here. If multiple people make use of it, then they don't have to know if or who is using it simultaneously. As long as everybody ->Acquire()s and ->Release()s the interface properly everything should work out. This is under the assumption that they willingly share the same object with each other somehow. The stack trace in your screenshot looks kind of like a double delete/free. This can only happen if someone isn't playing by the rules.

Because of how the overlay works (that thing that is rendered on top of your game that you can control with keyboard and mouse, obvious culprit judging from the stack trace), I am fairly certain that it tries to hook DirectInput. It basically "pretends" to us like it is the real DirectInput even though it isn't. In order to intercept and when applicable block input events from reaching our code, they need to do some funky stuff in theirs. This is the reason why they couldn't simply just create their own DirectInput object and had to hijack ours. The facts are kind of clear. We create an object (which implies ->AddRef()). And at some point we destroy the object with ->Release(). From our perspective, nothing else can happen in between. A double delete/free can only happen if they also play around with the the reference count for an object that we own.

There is nothing we can do. If they want/have to hook a DLL, then the least they can do is at least try to make sure it behaves like the real deal under all circumstances, yes... including C++ code... that doesn't make use of SDL... with static object destructors... that can ->Release() objects after main() returns. This tendency to design everything under the assumption that everybody programs in C style can be kind of disturbing at times...

49

Window / Re: DInput update appears to cause an exception with Steam API

« on: April 15, 2018, 03:42:43 am »

Try this:

#include <SFML/Graphics.hpp>
#include <steam/steam_api.h>
#include <cstdlib>
 
int main()
{
    if(SteamAPI_Init())
    {
        std::atexit([]{ SteamAPI_Shutdown(); });
        sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
        sf::CircleShape shape(100.f);
        shape.setFillColor(sf::Color::Green);
 
        while (window.isOpen())
        {
            sf::Event event;
            while (window.pollEvent(event))
            {
                if (event.type == sf::Event::Closed)
                    window.close();
            }
 
            window.clear();
            window.draw(shape);
            window.display();
        }
    }
    return 0;
}
 

I have this weird feeling that whatever is going on inside the Steam DLL doesn't like it when applications call through its hooks after it has been shut down.

50

General discussions / Re: What's the future of SFML's OpenGL-based renderer?

« on: April 08, 2018, 06:46:34 pm »

Well... nothing in getNativeHandle suggests that it has to be an OpenGL object ID.

If you look at the Pong example, we can already write applications without having to care about how it is actually rendered underneath. In typical applications you would also not have to touch sf::Context in any way either.

The only hurdle left to deal with is specification of the shader source. In OpenGL GLSL is used, in Direct3D HLSL is used and in Vulkan... SPIR-V is "used" in the sense that it is the stuff you feed into the API. All the examples you see in the wild will have generated the SPIR-V from GLSL using a compiler (in fact Vulkan has gotten to the point where it can accept GLSL directly now). It has become so easy nowadays to translate from one shader language to another shader language that this isn't even a problem that is impossible to solve any more.

The fact that you can use SFML as an OpenGL capable window isn't going to disappear. If you wanted to you could even attach an OpenGL context, a Direct3D device and a Vulkan device to the same window simultaneously if you really wanted to. One doesn't exclude the other.

Like I said in my previous post, the first step in this direction is to solve the problem of non-legacy shaders. Once that is done we can deal with the other smaller problems on the way.

51

General discussions / Re: What's the future of SFML's OpenGL-based renderer?

« on: April 08, 2018, 04:26:44 pm »

The question is not if... but how and when.

I would have already started with this years ago if it were not for this unresolved discussion.

52

Graphics / Re: [OpenGL + SFML mixing] Using multiple texture units causes STACK{OVER|UNDER}FLOW

« on: April 06, 2018, 04:16:37 pm »

Try calling glActiveTexture in the opposite order when cleaning up in your loop so you are left with 0 active when you are done. This reversal of order is a good habit when setting up and tearing down anything that results in residual state. Each texture unit has its own matrix stack. SFML expects to always have 0 active when it does anything. This is currently not checked in pushGLStates/popGLStates.

53

Feature requests / Re: Anisotropic Filtering

« on: March 30, 2018, 05:59:27 pm »

If the user wants to set AF globally they will be able to do it in their own code... We don't need to provide them with this.

54

Feature requests / Re: Anisotropic Filtering

« on: March 30, 2018, 05:25:18 pm »

I would do this on a per-texture basis. Forcing an all-or-nothing implementation robs the user of the ability to fine tune their application performance as they see fit. They will also know best which textures would benefit from AF.

55

Feature requests / Re: Anisotropic Filtering

« on: March 30, 2018, 03:31:06 pm »

What would be the reason(s) to not use it by default then? Compatibility? Performances?

AF requires additional texture lookups when sampling textures in a shader. If this is a bottleneck, then yes... AF can have a performance impact. Since applications can often get GPU memory bottlenecked (GPU memory is shared by geometry, texture and other data), we shouldn't force it to be enabled, especially since it doesn't always lead to an improvement in image quality, e.g. when isotropic filtering already provides the theoretical maximum.

I also expect the PR to provide a way for the user to query the maximum AF value and also set it as they see fit. This is a trade-off that can only be made by the application developer themselves.

56

Feature requests / Re: Anisotropic Filtering

« on: March 30, 2018, 01:26:47 pm »

I imagine this could have some applications in certain use cases.

• Textured GUIs generated on-the-fly from structural descriptions
• Procedurally generated artwork, think grammar-based building façades etc.
• ...

Since I don't imagine this being such a big change, and it will enable new ways of using the library and more artistic freedom, you could submit an initial pull request. Whether you discuss the necessary modifications to the public API here or in the PR comments is up to you.

57

General / Re: [Android] Crash when paused

« on: March 22, 2018, 08:47:07 pm »

SFML's context handling on OpenGL ES platforms is still in its infancy. When you switch away from an application (or cause the system to go into a power saving mode) on Android or any other mobile platform, the system is allowed to destroy any active OpenGL ES contexts that have been created. This is mainly to save/share the limited system resources more efficiently. A robust OpenGL ES application would have to be able to deal with context loss if it happens. Currently, there is no way for this to be handled elegantly in SFML.

Someone with more experience developing for Android might know of a workaround to prevent context loss so that SFML would not have to deal with this situation. Something along the lines of setPreserveEGLContextOnPause.

58

Feature requests / Re: Smart Shader Binding

« on: March 14, 2018, 05:40:41 pm »

Coming soon™ to an SFML near you.

59

SFML development / Re: How should SFML handle non-legacy shaders?

« on: February 26, 2018, 02:04:58 pm »

I'd just default to the non-legacy variation but add an additional parameter to the members loading shaders to enable legacy mode (which would just redeclare the legacy variables).

From the GLSL specification:

Identifiers starting with “gl_” are reserved for use by OpenGL, and may not be declared in a shader; this results in a compile-time error.

60

SFML development / Re: How should SFML handle non-legacy shaders?

« on: February 25, 2018, 05:02:16 pm »

Maybe my formulation set some wrong expectations but the "new" API isn't going to be (and doesn't have to be) significantly different from the current one.

The only required extension to the API, mandated by the transition away from client side arrays, is the explicit specification and binding of vertex attributes within the shaders. Built-ins like gl_Vertex and gl_MultiTexCoord0 cease to exist in GLSL 3.00 along with the built-in matrix stacks (gl_ModelViewMatrix, gl_ProjectionMatrix, etc.).

A replacement mechanism for those is all that is needed to make the shader API "non-legacy". The rest of the current API can stay as it is. Uniforms haven't gone anywhere, and the compilation process has stayed mostly the same.

Sure... this won't encompass every addition that has been made to shaders in OpenGL up to 4.5, but those additions can be made iteratively on a case by case basis, like every other feature addition to SFML. None of it is necessary in contrast to what I described above.