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 - Foaly

Pages: [1] 2 3 4
SFML development / Window state
« on: February 01, 2018, 11:35:24 pm »
Hello everybody,
I was looking into a ticket that I have already been working on in the past. It is on maximing a window from code. Reading over the discussion again it seems to end with an already pretty good concept for an API. I though about it some more and I want to propose a design here. I'd like to hear your thoughts and if we can agree on it or develop it further I would like to start an implementation soon. Oh and a thing you guys are gonna like: we don't have to change the existing API, except for one deprecation ;)

So I would suggest this:
enum State

sf::Window::State state = sf::Window::State::Minimized;
window.create(videoMode, title, style, settings, state);
state = window.getState();

So as you can see we have a seperation between state and style. Style is now only for the appearance/decoration of a window. The state of the window can now be described seperatly. An enum somewhere contains the possible window states. States are exclusive, so a window can only ever have one state. The create method will be extended by another parameter for the style, which can default to Windowed. The platform implementation of create will then open the window in the given state. There is also a getter and a setter in sf::Window. The setter will simply apply the state to the window. The getter will return the windows current state. Those are all the additions to the API. The Fullscreen window style would have to be deprecated in order to make a clear distinction between style and state.

This API would have two welcome side effects. You could finally switch to fullscreen mode and back (at least I have found it very annoying in the past that you always have to recreate the window for that, especially since things like the mouse visibility are not saved). Also it would allow creating a hidden/invisible window on creation by passing the minimized state to the create function.

So I would like to hear your thoughts on this :)

General discussions / Unfreezing the API
« on: January 25, 2018, 02:48:37 pm »
Hello everybody!

I would like to talk about the ban on API changes. For years there has been the rule in place to not introduce changes that alter the public API in any way except in major version releases.

I understand the desire to have a stable, reliable API. Afterall one of SFMLs strong points is its clean and simple API. To my understanding the incentive when introducing this restriction was to make SFML more attractive for bigger projects and companies. The reasoning was that for game studios or companies it is uneconomic to have to refactor their code base every couple month when a new version with a changed API of SFML is released.

In my opinion the assumptions have failed the test of time and have actually done more damage than good. Here is why I think that. From what I can tell (and please correct me if I am wrong) not many companies/studios use SFML for producing games since the limitation was introduced. The biggest chunck of users are still hobby developers, people learning graphics development/OpenGL and small projects. There are occasionally some polished and finished games on some game distribution platform or app store. I think its absolutly fine to confront people learning, studying or simply enjoying graphics programming with new features and potentially a couple minutes/hours of work when updating to a new version. I would actually argue that those users enjoy updates/changes.
Most importantly though the assumptions there will be a new major version "soon" turned out to be false. Back when this was introduced SFML 2.0 had just been released, the new development team had just been founded, development was going strong and there was a minor release about every half year. SFML 2 had just changed more or less the entire API so it made sense to say the next API change will happen in SFML 3. By that time and judging by the development activity at the time SFML 3 was thought to be release within a couple years. We are here a couple years later now and SFML 3 is still a couple years away. Development has slowed down significantly and there is a minor release about once a year. So any advances will just continued to be halted for years?

More that any of that I think that the attitude displayed to outside developers with this is extremly toxic to progress. Be it one time contributors or people enjoying sending patches every now and then. Reading something like: "yeah thanks thats a nice idea. we could implemented it right now, but we won't. why don't you come back in like 2-3 years, then we will think about it again". It is extremly discouraging and I have seen this many times. I think we can all agree that given the pace of SFMLs current development we should make it as welcoming and easy as possible for contributors to help.

So in the good old fashion of proving a necessity could somebody from the team please provide a concrete use case for an API that is stable and without change for years and years on end.

Sorry if this comes across harsh. I am not trying to hate on anybody. Its just that its incomprehensible and mind-boggling to me to see the already slow development of SFML being crippled even further for no advantage. But this is a discussion please let me know your opinion.

System / sf::Vector comparison operator (< and >)
« on: April 11, 2016, 01:33:50 pm »
I want to create a element at the mouse position. I order to keep it within the window I want to clamp the mouse position to the windows dimensions. Maybe I am just being stupid here, but I can't get it to work...
Here is the code I am using:
#include <SFML/Graphics.hpp>
#include <iostream>
#include <algorithm>

template <typename T>
bool operator <(const sf::Vector2<T>& left, const sf::Vector2<T>& right)
    return (left.x < right.x) && (left.y < right.y);

template <typename T>
bool operator >(const sf::Vector2<T>& left, const sf::Vector2<T>& right)
    return (left.x > right.x) && (left.y > right.y);

int main()
    sf::RenderWindow window(sf::VideoMode(800, 600), "Example");

    // run the program as long as the window is open
    while (window.isOpen())
        // check all the windows events
        sf::Event event;
        while (window.pollEvent(event))
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)

            else if (event.type == sf::Event::MouseButtonReleased && event.mouseButton.button == sf::Mouse::Left)
                auto mousePosition = window.mapPixelToCoords(sf::Mouse::getPosition(window));
                const auto windowSize = sf::Vector2f(window.getSize());

                // clamp to window size
                mousePosition = std::min(windowSize, std::max(sf::Vector2f(0.f, 0.f), mousePosition));

                std::cout << mousePosition.x << "x" << mousePosition.y << std::endl;

        // clear the window to black

        // display the windows content
    return 0;

I am getting these compilation errors for the std::max and std::min templates: no match for 'operator<' (operand types are 'const sf::Vector2<float>' and 'const sf::Vector2<float>')
and operator> respectively. I don't really know whats wrong since I do define these operators above. Maybe somebody can tell me whats wrong.

This also got me wondering: Is there a reason why these operators are not defined by SFML?

Thanks in advance,

General / SFML 2 and Qt 5
« on: January 15, 2016, 01:41:47 pm »
Hi everybody!

As the title suggest I am trying to set up SFML and Qt to work together. I know this has been done before and I am probably just being stupid somewhere, but I ran into some issues. I couldn't find a complete example/template that uses recent versions of SFML or Qt. Thats why I thought I just ask here.

So here is my code. It is of course based on Elias Dalers awesome project and the existing wiki page. I pushed my code into a repo to make it easier to download.

(click to show/hide)

As you can see in the screenshot most of the stuff is already working. The weird part I am having trouble with is that some events do not reach in the SFML window event loop. For example I do receive MouseButtonReleased and Resized events, but I can't get any MouseWheelScrolled or KeyReleased events. Does anybody have a clue why thats happening?
Also I can't connect the button to a function, but I think thats an unrelated problem. Still if somebody knows why that would be a great help.

Here is the error output when the program is run:
(click to show/hide)

I hope that somebody how has more experience with Qt and SFML working together can help me figure this out.
Maybe we can put it on the wiki once its working. I am sure it can be useful to other people in the future as well.

Thanks in advance,

Feature requests / Assertions in sf::Image::getPixel()
« on: November 16, 2015, 08:34:02 pm »
This is a tiny thing, but a helpful one I think.
Recently more and more assertions have been added to the SFML code (see the new audio reader/writer files) and I think it's an awesome thing from a developers point of view. I have been working with the sf::Image class recently and I think the sf::Image::getPixel(x, y) method could really benefit for a debug assertion that checks if x and y are within range. Speed is what count here, so I totaly see the reason to not do bounds checks in release mode, but I think assertions in debug mode can be really helpful. The documentation only specifies that x and y are the "coordinate of pixel to get" but it doesn't specify in which range. Could be (0, size] or [0, size). (It's the first one by the way ;) ) It took me some trial & error and code reading, that I want to save the next user. Thats way I'm suggesting the assertions and mentioning the expected range in the documentation.

Feature requests / SoundRecorder improvments
« on: October 02, 2015, 03:57:32 pm »
Hello everybody!
I have been using SoundRecorder quiet a bit in the past for different things and I noticed a couple things that need improvment. I have been using some of these improvments in my own code for a while, but I found the time now to make some clean commits.
So first up I noticed an error when you destroy a sf::SoundBufferRecorder while it's recording. You get a
Code: [Select]
pure virtual method called
terminate called without an active exception
error in the console when doing so. After diging into the code I think I found the answer. It's a threading issue. SoundBufferRecorder::onProcessSamples overwrittes the pure virtual function SoundRecorder::onProcessSamples which is called by the audio capture thread. When SoundBufferRecorder is destroyed it's method gets deleted, before the thread stops using it. Calling stop() in SoundBufferRecorders destructor fixes this problem. I think we should notice in a red box in the tutorials that a derived class has to call stop in it's destructor, since there is already a section on threading issues. Here is my fix.

Secondly I would like to suggest a new feature: Stereo recording. I have used it for quiet some time now and it comes in really handy. I saw there are also a couple threads on the forum with people requesting it. The answers suggest that it will be implemented later on. Here is my commit.

The last thing is something that I have implemented myself, but using it I noticed it would be better to do it differently. Right now if you call setDevice with an invalid device name while you are already recording the recording stops. Of course sometimes that's not what you want. So I think it would be a better behaviour to print an error message and fall back to device already in use if the one you specified is not available. Think of an application like VOIP or a sound installation where you want to make sure that there are always samples available. The commit can be found here. This commit also fixes another small issue when the method is called with an empty string.

So tell me what you think. The commits are ready to go and I'll send a PR once I heard some feedback.

SFML website / Recording audio tutorial update
« on: September 25, 2015, 03:21:38 pm »
I was having a look at the the Recording audio tutorial and I noticed something wrong. In the section Custom recording there is a big red box stating that you the rate at which onProcessSamples is being called, is hard coded into SFML. To my knowledge this is configurable since 2.2 (this commit).
Also I noticed that the tutorial doesn't mention that you are able to configure the input device used for recording anywhere. I thought since there is already a dedicated tutorial for sound recording, we might as well mention it. I think it's a very handy feature (not because I wrote it, but because I have used it quiet often :) )
So what I am asking is would anybody mind if I removed the box and wrote a section on selecting the input device?

General discussions / Multi monitor support
« on: September 08, 2015, 09:38:35 pm »
Good evening everbody!
I'm starting another attempt at the good old multi monitor setup issue :) But this time I am bringing a fully functional reference implementation for windows with me! You can check it out here: https://github.com/Foaly/SFML/tree/multi-monitor-windows (commit d3bfdbfb)
This weekend I dug through the old discussions and the MSDN and implemented a working multi monitor API for windows. It follows the ideas brought up inprevious threads. I designed the API so that it is fully backwards compatiple with the current SFML master. The usage looks like this:

#include <SFML/Window.hpp>
#include <iostream>

int main()
    std::cout << "# of connected Screens: " << sf::VideoMode::getScreenCount() << std::endl;

    // display all supported fullscreen resolutions for all monitors
    for (unsigned int id = 0; id < sf::VideoMode::getScreenCount(); ++id)
        std::vector<sf::VideoMode> modes = sf::VideoMode::getFullscreenModes(id);
        std::cout << "Valid resolutions for screen " << id << std::endl << std::endl;
        for(std::size_t i = 0; i < modes.size(); ++i)
            sf::VideoMode mode = modes[i];
            std::cout << "Mode #" << i << ": "
                      << mode.width << "x" << mode.height << " - "
                      << mode.bitsPerPixel << " bpp" << std::endl;
        std::cout << std::endl;

    // display the desktop resolution for all screens
    for (unsigned int i = 0; i < sf::VideoMode::getScreenCount(); ++i)
        sf::VideoMode mode = sf::VideoMode::getDesktopMode(i);
        std::cout << "Desktop mode for screen #" << i << ": "
        << mode.width << "x" << mode.height << " - "
        << mode.bitsPerPixel << " bpp" << std::endl << std::endl;

    // get infos about the second screen
    sf::Screen screen = sf::VideoMode::getScreenInfo(1);
    std::wcout << "Monitor 1 name: " << screen.realName << std::endl
               << "x: " << screen.geometry.left << " y: " << screen.geometry.top << " width: " << screen.geometry.width << " height: " << screen.geometry.height << std::endl
               << "framerate: " << screen.frameRate << "Hz" << std::endl;

    // open a window on the second monitor
    sf::VideoMode videoMode(1280, 1024, 32, 1);
    sf::Window window(videoMode, "Multi Monitor Example!" /*, sf::Style::Fullscreen*/);

    // run the program as long as the window is open
    while (window.isOpen()) {
        // check all the windows events
        sf::Event event;
        while (window.pollEvent(event)) {
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)

            else if (event.type == sf::Event::KeyReleased) {
                // close if escape key was pressed
                if (event.key.code == sf::Keyboard::Escape) {

        // display the windows content

    return 0;

Of course this is a proof of concept rather than a polished and finished implemention. It's supposed to be a base for further discussion about the API and the implementation. I know there are some dirty hacks in there (like including sf::Rect from the graphics package, exposing platform specific details in the public API or breaking compilation on Linux/Mac... ::)) but I'd still love to hear feedback (both on the implementation and the API). Also the code needs testing. I tryed it with my setup (win7 + NVIDIA GTX 970 + 3 monitors) and everything works as expected, but there are loads of different configurations and the winapi is quiet complicated, so if some more people with different configuration would test this, that would be awesome!

Ok I'd love to hear improvents, comments or criticsim. Let's get this feature implemented!

edit: also just noticed 400th post yay :D

Graphics / Can't use texture coordinates without a texture
« on: July 29, 2015, 12:44:47 pm »
Hello there!

Yesterdy I checked out the radial gradient shader that appeared on the wiki recently, because I wanted to use this effect in a little project of mine. While I was browsing the code I wondered why the code is so complicated. You have to specify a center, a radius and the windows height; all in screen coordinates! So I thought there has to be an easier way using variables that are already defined in the shader, like texture coordinates.

It turns out it's not that easy. I set up a sf::CircleShape with a size, a color, a position and a gradient fragment shader. Something was wrong with the texture coordinates though. When I set the output color to gl_TexCoord[0].xy the output was always black for all fragments. Debbuging into the code of sf::Shape it turns out the texture coordinates are only calculated properly if m_textureRect is set. So I set the texture rect to sf::Int(0, 0, size, size) and the texture coordinates in the shader turned white, meaning there was another problem. I debugged a little further and remembered that SFML uses non-normalized texture coordinates. Since I don't have a texture applyed sf::Texture::bind doesn't get called and the texture coordinates are not being converted. If I devide the coordinates by the shapes size in the shader everything works as expected.

All of that seems quiet hackey to me though. I think we should be able to use the texture coordinates even if the shape has no texture. A lot of effects rely on texture coordinates, especially post processing effects done in the fragment shader, it would be sad if you can't use them with an untextured shape. Or is there a reason that this has been left out?
I'd suggest if m_texture is NULL, set m_textureRect to the shapes dimensions and apply the texture transform matrix in the draw method or simply set the texture coordinates to normalized coordintes when m_texture is NULL. I can write a pull request if this gets agreed on.

Feature requests / sf::Text horizontal character spacing
« on: July 21, 2015, 11:36:44 am »
Hi there,
I want to propose a feature that I think sf::Text is missing. Vertical spacing between characters (letter-spacing).
It kept reappearing in a couple of my projects now, so I thought I suggest it. For example there are some fonts that I used of the web. They looks fine on a regular size, but if I scale them up to a very big or down to a very small size, the spacing between characters just doesn't look right anymore. The whole text looks streched/squeezed and it affects the readability (could also be used as an effect thought). It would be nice if you could counter that.
Besides that it would enable people to do bounchy/streching effects with text.
This is nothing excotic and users know this feature from software like GIMP/Photoshop, Word/LibreOffice or from CSS. It's just something you would expect from a multimedia library handeling text.
I have helped myself with a modified version of sf::Text in the past, so there is a tested code ready to go.
What do you guys think?

General discussions / Multi Monitor Setup
« on: July 30, 2014, 12:49:42 am »
Hello there!
I think I already mentioned it in some other post, but I often have a setup, where I have a normal pc/laptop with a control window and a projector as a second screen with a fullsreen window, that displays the graphics.
There was a topic recently about multi monitor support and selecting the fullscreen monitor, but it hasn't gotten much attention. Since designing a clean and simple API for this seems tricky (things like fullscreen windows streching over multiple monitor or vertical setups have to be considered) and the process hasn't even started; I thought I'd make this suggestion.
Right now with SFML it is impossible to select the monitor for the fullscreen window. If a SFML window is created with the fullscreen flag it always goes into fullscreen on the first monitor. I think it would be way better to let the window go into fullscreen on the monitor it currently resides in. That would offer a nice way for some workarounds till a good design is found.
Right now I am using this on windows to get a window into fullscreen on the second monitor:
sf::RenderWindow window(sf::VideoMode::getFullscreenModes()[0], "Window", sf::Style::Fullscreen);

// width of first monitor is 1280, so move the window onto the second monitor
window.setPosition(sf::Vector2i(1300, 0));

MONITORINFO mi = { sizeof(mi) };

HWND hwnd = window.getSystemHandle();

// get the coordinates of the monitor the window is currently in
GetMonitorInfo(MonitorFromWindow(hwnd, MONITOR_DEFAULTTOPRIMARY), &mi);

// move the window
SetWindowPos(hwnd, HWND_TOP,
             mi.rcMonitor.left, mi.rcMonitor.top,
             mi.rcMonitor.right - mi.rcMonitor.left,
             mi.rcMonitor.bottom - mi.rcMonitor.top,
Other people had similar setups/problems, so I think integrating something along those lines into the switchToFullscreen method would be a very nice addition.

Graphics / Subtractiv Blend mode
« on: July 19, 2014, 12:30:27 pm »
Hello everybody!
I wanted to give the newly implemented blend modes a try and see if they can solve an issue cleaner than what I use right now (a shader). What I am trying to acchive is that a render texture fades out over time.
So my idea is to simply draw a black rect with very low alpha over the entire render texture each frame to make it slowly fade. When I use the default alpha blending mode I get weird visual artefacts. (it seems to be related to some value being very small and causing problems when multiplyed; seems to be a know problem) Thats why I wanted to try a subtractive blend mode.
I tryed to simply take the Alpha Mode and exchange the blend function from add to subtract, but that didn't work.
const sf::BlendMode BlendSubtractive(sf::BlendMode::SrcAlpha, sf::BlendMode::OneMinusSrcAlpha, sf::BlendMode::Subtract,
                                     sf::BlendMode::One, sf::BlendMode::OneMinusSrcAlpha, sf::BlendMode::Subtract);
I am a little confused to what option to choose. Could somebody with a better OpenGL knowledge explain the correct way to me?
Thanks in advance,

Graphics / Problem with sf::Shader after updating
« on: July 17, 2014, 11:15:19 pm »
Hi there!
I updated my SFML repo to the current master recently and now using sf::Shader seems to be broken...
Whenever setParameter() or bind() or the destructor is called I get a: "An internal OpenGL call failed in Shader.cpp (421) : GL_INVALID_VALUE, a numeric argument is out of range" error in the console. (line number changes respectivly to the calling method of course)

I investigated a little bit and it seems that m_ShaderProgram is invalid. When I step through the compile() method with the debugger it stops in line 490 where m_ShaderProgram is created. The method return on this line (eventough there is no return?!) and m_ShaderProgram stays at 0.
Through checking out different git commits if found that 1fe22e2 seems to be the breaking commit. Before that everything works fine.
I don't quiet understand why. But can somebody explain to me whats going on? Or has anybody experienced similar problems?

Thanks a lot, Foaly

System / Deleting variable safely from a different thread
« on: November 13, 2013, 04:40:40 pm »
Hello everybody!
I was writing some code the other day and after reading it again today, I noticed something, that looks like a potential crash to me, but I'm not sure.
So here we go:
Let's say I have a class that runs a thread. In that thread among other thing there is a part that constantly writes stuff to a file. Something like this:
    *m_logFile << string;

The m_isLogging variable is an atomic bool, so I can switch the it on and off from a different thread. For that I have a method startLogging() that looks something like this:
void Worker::startLogging()
    // Create the file
    m_logFile = std::unique_ptr<File>(new File);

    // Open the file
        std::cerr << "Unable to open log!" << std::endl;
    m_isLogging = true;
As far as I see it everything is fine here.
Here comes the stop method:
void Worker::stopLogging()
    m_isLogging = false;
Now here is my question: As you can see I have the mutex to protect m_logFile from being deleted while it's still being writen to. But what happens when stopLogging() (being called from another thread) locks the mutex. Then the thread functions enters the if (because m_isLogging is still true) and put the thread to sleep, because the mutex is locked. Then stopLogging() finishes deleting the file and releases the mutex. The thread function resumes, because the mutex is unlock and wants to write to an object that isn't there anymore.
Eventhough this might be highly unlikly, because the reset() and the assignment are really fast operations, this looks like a potetial crash to me. Is that correct?
Now, would it be enough to put a
if(m_logFile != nullptr)
    *m_logFile << string;
after the m_mutex.lock()? Or is there something different/better?

Thanks in advance,

General / Factoryfunction pointer
« on: October 31, 2013, 07:57:22 pm »
Hello everybody!
I have a design question for C++11. It's not directly SFML related, but more to graphics programming in general.
I have a program that makes extensive use of particles. Here is my current design: I programmed a particle system, that consists out of a super class Particle. The subclasses (like StarParticle) inherate from it. Because the type of particle changes at runtime I created a "factory function" for each particle type, which looks like this:
std::unique_ptr<Particle> createStarParticle (sf::Vector2f position)
    return std::unique_ptr<StarParticle> (new StarParticle(position));
I then have a std::vector<std::unique_ptr<Particle> (* pointerToFactoryFunction) (sf::Vector2f)> which holdes pointers to all the factory functions. For the insertion I use:
particles.push_back((*factoryFunctionVector[index])(sf::Vector2f(x, y)));

Now, the code works perfectly fine, like I expected it, but it looks to like C style to me. So I my question is, is there a C++11 way of doing this. I read a little bit about std::function and lambdas, but I'm not a 100% if I can acchive what I want with those.
Could somebody with more C++11 knowledge help me on that one?

Thanks in advance,

Pages: [1] 2 3 4