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

Pages: [1] 2 3 ... 33
SFML development / Re: DPI-Scaling on Windows
« on: November 27, 2023, 08:06:30 pm »
I have no idea how things will work with child windows or windows that weren't created with SFML, so I won't comment on that.

Scaling behavior of the window content

The thing that needs to be discussed is how much options are left to the user. Will SFML force a certain scaling or will it provide many different options. I'll list the possible options that I'm aware of below.

1) DPI-Unaware

When using this, Windows will scale the entire window, including the title bar. Windows does everything for you and the developer doesn't has to do anything. The big downside is that the whole window will be blurry, making text less nice to read.

This mode is really intended for legacy applications that were written without DPI in mind.

2) Don't scaling anything (Per Monitor Aware V1 without handling WM_DPICHANGED)

This is what we currently do in SFML 2.6 and what my PR does if you don't set the highDpi flag.

Both the window contents and the title bar are unscaled and show up as if the monitor had 100% scaling. The window will look too small for people that have DPI scaling on their monitor. While that clearly isn't an ideal thing to do, it gives all the control to the developer. The window has exactly the amount of pixels that the developer wanted, without SFML manipulating anything.

The problem with this method is mainly that SFML doesn't provide enough tools to the developer to actually do anything themself. They would need to know the DPI scaling of each monitor, and get an event when the window switches monitor. Only then would they be able to manually decide what the wanted window size should be.

3) Scaling everything automatically (Per Monitor Aware V2)

This is what my PR does with the highDpi flag.
The advantage is that SFML takes care of all the DPI changes for the user, the downside is that it takes all control away from the user.

I'm sure there are alternative ways to implement this, but this was the easiest that I could think of: only manipulating the window size on window creation and on DPI changes (e.g. when switching monitor). When a window of 800x600 is requested on a monitor with 200% scaling, a window of size 1600x1200 will be created instead.

While SFML doesn't has to do the same as SDL or GLFW, it might be useful to know how they handle things:
- SDL uses option 1 (DPI-Unaware) as default. When a high-DPI flag is set, they act similar to option 3 (scaling contents and title bar automatically). The big difference with my implementation is that SDL chose to keep the window size and mouse events unscaled. So even with the high-DPI flag set, the real window size and rendering area are larger than what SDL_GetWindowSize reports, and you have to manually scale mouse events to figure out where on the render target the mouse is located.
- GLFW uses option 2 (not scaling anything) and option 3 (scaling contents and title bar automatically) based on a global flag. My PR code was heavily influenced by this design, because I liked how it kept the window and rendering area the same unlike with SDL.

Scaling behavior of the window decoration

With scaling options 1 and 3 above, the contents and decoration are scaled the same. For option 2, you could provide an alternative that would not scale the contents but would scale the title bar. So that gives a 4th scaling option:

4) Scaling only title bar (Per Monitor Aware V2 while keeping the window at a fixed size)

I'm not sure how easy or difficult this is to implement, I do know it requires handling WM_DPICHANGED. When moving monitor, Windows won't resize the window. So when it changes the title bar size, it also changes the client size of the window (which you wouldn't want). So you would need to implement WM_DPICHANGED in such a way that it reverts the change that Windows automatically makes (this will likely be similar to the code from option 3).

API to get the scaled and unscaled sizes

With all 4 scaling modes mentioned above (at least when implementing it like I did in the PR), the window size and rendering area are the exact same, so no additional functions are needed. The size of the window on screen is also the size reported when requesting the window size in SFML.
The only case where the scaled and unscaled sizes differ is with "DPI-Unaware", but there Windows is intentionally providing SFML with the wrong window size, so as far as SFML can tell the rendering size is still the same as the window size (and Windows will just stretch it when displaying).

One thing that needs to be done is make people aware that the window size will no longer be what they specify in the API. That's why I had the highDpi flag: to keep thing as expected until the user made the choice to activate the new behavior. But if the other scaling modes are deemed as unneeded, then you could just force the behavior on everyone in SFML 3 without the flag. Although I can think of at least one case where you might want to have such flag (to turn scaling off): what if the user queries the monitor size and tries to create a window that matches it? SFML shouldn't change the window scale at that moment.

General / Re: Android support
« on: November 22, 2023, 10:53:21 pm »
You can show the software keyboard with "sf::Keyboard::setVirtualKeyboardVisible(true)", if that is what you mean with triggering input text.

General / Re: Android support
« on: November 20, 2023, 03:05:01 pm »
After running "make install" when building SFML, the SFML files should have been installed to the "sources/third_party/sfml" folder inside your NDK. First double check that the files exist there.

The last part of the tutorial is slightly outdated as it is still written for SFML 2, for SFML 3 you need to edit the "app/gradle.build.kts" file inside the android example. At the top of the file it sets a default NDK_VERSION and ARCH_ABI. If either of these is wrong then it will fail to find SFML with the error that you showed. So you need to change the NDK_VERSION from "25.2.9519653" to the version where SFML was installed to, and change ARCH_ABI from "arm64-v8a" to whatever you set CMAKE_ANDROID_ARCH_ABI to when building SFML (which is "armeabi-v7a" in the tutorial).

Edit: Are you using the NDK installed with the sdkmanager? The CMAKE_ANDROID_NDK is usually "<ANDROID_SDK_ROOT>/ndk/25.2.9519653" (where you replace "<ANDROID_SDK_ROOT>").

General / Re: Android support
« on: November 20, 2023, 12:33:50 pm »
Are you following https://github.com/SFML/SFML/wiki/Tutorial%3A-Building-SFML-for-Android ?

Where are you stuck exactly?

For me your code showed a white rectangle (or white triangles if a key is pressed), so something is definitely wrong with the code.

It turns out that you are using 2 separate shaders objects, while you should only be using 1. The code should look something like this:
sf::Shader shdr;

if(!shdr.loadFromFile("../shader.vert", "../shader.frag"))
    pauseExitErrorMessage("Failed to load shader!\n");

// Bind shaders

That makes the code work for me. Also I noticed that the fill_shape is changed no matter which key is being pressed instead of only when pressing F. You will need "event.key.code == sf::Keyboard::F" there in your code.

Does this have anything to do with TGUI? If you don't include TGUI and don't link to it, does the issue still exist? If yes then you should probably remove the TGUI include and change the title so that more people might look at the code.

Can you also share the code inside shader.vert and shader.frag, so that people can look at that as well?

sf::Shader uses legacy OpenGL, while you are using modern OpenGL (e.g. requesting GL 4.6 and using glGenVertexArrays). I don't know how well those will mix in the way you are using it. I couldn't tell if this code is supposed to run correctly or not (especially not without seeing the contents of those shader files).

There are graphics drivers that happily accept shaders with wrong GLSL versions or even GLES shaders while a desktop OpenGL context is loaded, but other graphics drivers will be more strict about following the OpenGL standard. So it is possible that the GLSL shaders you are loading will work on your friend's computer but not on yours if you have different GPUs (e.g. if he has nvidia and you have amd or intel).

SFML development / DPI awareness on Windows
« on: November 03, 2022, 11:22:58 pm »
I've written an implementation to provide minimal High-DPI support on Windows. The code can be found at https://github.com/texus/SFML/tree/feature/high-dpi-windows (view diff).
I can make a PR for this once the design has been discussed. I don't expect the code to be merged as-is, the design can be discussed and altered, but the code itself is already functional (although not extensively tested).

I've looked at how DPI scaling is handled on Windows in SDL and GLFW and did some research on my own. When I saw GLFW's implementation I started questioning whether we really need to have a framebuffer and window that have seperate sizes like in SDL: while GLFW has a separate framebuffer size, it keeps the same size as the window by default. Based on this I designed the DPI support to work without much changes to SFML's API.

Current SFML behavior

Before creating the window, System Aware scaling is enabled, but the window size is exactly as requested (i.e. no scaling is happening).

Unfortunately when dragging the window to a monitor with different scaling, Windows stretches the window and draws it at a different size without SFML knowing about it.

New default behavior

Per Monitor aware scaling is requested when creating the window. This changes nothing when only one monitor is involved or if they all have the same scaling, the window will still be exactly the size as requested. Moving the window to a monitor with different scaling (or changing the DPI on the monitor where the window is open) keeps the exact same window size though.

I've created a PR on github to make this the default behavior even in SFML 2.6, as this should be better behavior than System Aware.

New behavior with HighDpi

When manually choosing to have a high-DPI window (in my code this is done through VideoMode) the window may be created at a larger size than requested. If the main monitor has a scaling of 150% and a window of 800x600 is created, SFML would create a window of 1200x900. Everything has a 1:1 relation afterwards: rendering and mouse events all happen with the 1200x900 rectangle, only the initial size of the window differs.
When dragging the window to a monitor with 200% scaling (or when changing the scaling of the display that contains the window), the window will automatically be resized to 1600x1200. When moved back to the first monitor, it will become 1200x900 again.

On Windows 10 version 1703 or higher, the title bar of the window will also be scaled with the window (Per Monitor V2 awareness). On older Windows versions, the title bar will keep the size which it has when creating the window.

I did notice a rare bug on my system where the window sometimes gets a few pixels smaller or larger when moving monitor, but this occurs because a Windows event (WM_GETDPISCALEDSIZE) isn't being send to the app. I reproduced this in both SDL and GLFW so I'm assuming this is a bug in Windows, so I didn't bother trying to work around it.

There is currently no special event when the window changes monitor, but you would get an event about the window changing size and you could call window.getDpiScale() to figure out whether the resize was the result of the scaling changing or not.

Example code

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

const bool highDpi = true;

int main()
    sf::RenderWindow window{ sf::VideoMode{{800, 600}, 32, highDpi}, "SFML - HighDpi" };

    // The green rectangle is centered in the window at 100% scaling
    sf::RectangleShape shape1;
    shape1.setPosition({ 100, 100 });
    shape1.setSize({ 600, 400 });

    // The red rectangle is placed just outside the view at 100% scaling
    sf::RectangleShape shape2;
    shape2.setPosition({ 800, 600 });
    shape2.setSize({ 800, 600 });

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

            else if (event.type == sf::Event::Resized)
                window.setView(sf::View{ sf::FloatRect{{0.f, 0.f},
                    {static_cast<float>(event.size.width), static_cast<float>(event.size.height)}} });

                std::cerr << "Resized: "
                          << event.size.width << "x" << event.size.height
                          << "  dpi-scale=" << window.getDpiScale()
                          << "\n";


How to test

Go to Display Settings in Windows and change the Scale to a value other than 100%.
If you have 2 monitors, set the same or a different scale and see what happens when the window is dragged to the other monitors.
You can also change the scale while the window is open.

The code contains different code paths depending on the system. While I did test different code paths by manually editing the code, I only tested on Windows 10 21H2.
- Windows 10 version 1703 or newer (Per Monitor V2 awareness)
- Windows 10 version 1607 (Per Monitor V2 introduced, documentation is unclear about whether you need 1607 or 1703 to use V2)
- Windows 8.1 or Windows 10 before version 1607 (Per Monitor V1 awareness)
- Windows Vista, Windows 7 and Windows 8.0 (Only System Aware, no per monitor settings)
- Windows XP or any other version older than Vista (no DPI scaling at all)

In the first screenshot you have "C:\SFML-2.5.1\include" for "Additional Include Directories". This should probably be "C:\Libraries\SFML-2.5.1\include".

Have you tested a FreeType version on Windows other than 2.11?

There is a freetype bug that causes a crash in af_face_globals_get_metrics (where your callstack also points to) that only occurs on Windows (with libraries build with Visual Studio) and only with FreeType 2.11. https://gitlab.freedesktop.org/freetype/freetype/-/issues/1092

Downgrading to any version lower than that fixes that issue. FreeType versions are backwards compatible, I would expect SFML to work fine with FreeType 2.9 or 2.10

Feature requests / Re: Diagonal resize cursors on Linux
« on: July 25, 2020, 05:35:05 pm »
Yes, I can send a PR for this.
I guess I'll just implement the fall back to the double arrows on macOS for now, if anyone wants it differently then it could still be changed later.

Edit: see PR #1688

Feature requests / Diagonal resize cursors on Linux
« on: July 12, 2020, 05:51:22 pm »
I would like to change the mouse cursor when the mouse is at the corner of a child window in my gui, but SFML doesn't support diagonal arrows on Linux (Cursor.hpp#L65-L66).

I know that this is because X11 doesn't support those double arrows, but could directional arrows (e.g. XC_bottom_left_corner) perhaps be added?
The following would be useful, but only the last 4 are required to add support for diagonal resizing on linux.
- SizeLeft
- SizeRight
- SizeTop
- SizeBottom
- SizeTopLeft
- SizeTopRight
- SizeBottomLeft
- SizeBottomRight

On linux, all of those exist.

On windows, none of those exist. It should be easy to just display the double arrow if one of those directional sizes are requested though.

On macOS, all of those should also exist, but are undocumented just like the diagonal double arrows. I'm not sure if they are ever used on mac though, maybe it would be better to fall back to double arrows here as well (for my gui I would only try to set those directional cursors in Linux anyway and use double arrows on Windows and macOS).

Is there any chance that those cursors could be added to SFML, even though they are specific for Linux?
I've already changed my code to just load those cursors directly and only use SFML when loading other cursors, but it would be nice if I could set those cursors via SFML as well in future SFML versions (as I now have to link with Xlib myself).

Graphics / Re: weird behavior from my color picker (SFML & TGUI)
« on: March 31, 2020, 07:42:54 pm »
You should really reduce code to a minimum if you want people to help you find the issue. It takes too much time for someone who doesn't know the code to get started with it. The code isn't minimal at all: it uses plog, is spread over multiple files and contains many unnecessary things. Why do I need to press a button and check a checkbox before I can start trying something? If it is not related then it should be removed, the contents of the child window should just be the contents of the main window. If it would have been related, then it should explicitly be said so as it would help narrowing the issue.

Do the scrollbars have any influence on the issue for example? Print the scrollbar values when the issue occurs and hardcode these values instead of getting them from the scrollbars. If the issue still occurs, then the scrollbars can be removed. If it doesn't occur when hardcoding the values then at least you get some more information as to where in the code to look.

Your code has so many weird things going on that may or may not be related to your issue that it is hard to even pinpoint the issue for someone who doesn't know the code. Printing the ColorHue variable for example shows that you are trying to store 360 values in a 8-bit variable. You seem to know this already because it has a comment next to it that you should prevent overflow, but you should probably fix this first as these kind of issues might contribute to the real issue or at least waste time of people trying to look for the issue. You also imply in your previous post that HSV(0, 20, 13) would be bright red, but it is actually much closer to black if you look it up. Even the debug print is confusing since you print the values in S, V, H order instead of H, S, V. The image you use is also a bit confusing: Normally white is at the left side (because an S value of 0 gives you white to black, with no hue).

Values in HSV are usually limited to (360, 100%, 100%), but it doesn't seem to be the case in your code (and the magic numbers don't make it easier to understand what the code is actually using). The fact that the HSV class stores its values as doubles made me think that it might use values between 0 and 1 for S and V, and looking at the ColorTest function at the bottom of ColorHeader.h shows that the assumption was right. Yet your code stores them as uint8_t with values from 0 to 255. If this isn't the main issue then at least it is part of it.

If your input is HSV(0, 20, 13) and your output is RGB(243, 247, 247), like you showed in your last post, and you believe that the given output is incorrect for the provided input then you could have minimized your code to this:
int main()
    HSV hsv = HSV(0, 20, 13);
    RGB rgb = HSVToRGB(hsv);
    std::cout << (int)rgb.R << " " << (int)rgb.G << " " << (int)rgb.B << std::endl;

That is how much you could have reduced the code. And then you probably would have been able to find the issue yourself.
Changing the HSV parameters to (0, 0.2, 0.13) does print the correct RGB values in this code.
If there are other issues in the code then at least this one would be dealt with and you can handle them one at a time by minimizing the code around some issue instead of trying to fix them all at once.

General discussions / Re: GUI with SFML
« on: February 29, 2020, 10:39:46 pm »
Make sure there are no conflicting options checked (e.g. if c++98 is also checked).
There are actually several places where you can set these options. Under "Settings > Compiler..." you can set it globally for all your projects (not recommended). Under "Project > Build options..." you find the settings for your current project. But on the left side of the window you can select whether you are viewing options for Debug, Release of both. So make sure you aren't e.g. only adding the option in release while building your option in debug mode.

Have a look at the build log to see which parameters are passed to g++.
In the build log you can see which options are actually being used. Your error clearly mentions that you don't have c++14 enabled, so either the -std=c++14 option won't appear here or there will also be e.g. some -std=c++98 in the same command that overwrites it.

General discussions / Re: GUI with SFML
« on: February 28, 2020, 05:55:36 pm »
lambda capture initializers only available with -std=c++14 or -std=gnu++14
You need to add "-std=c++14" to your compiler options in order to use TGUI. Where you do this depends on how you are compiling, but if you are using codeblocks then you can do this in the "Compiler flags" in the "Project build options" as shown in the tutorial (https://tgui.eu/tutorials/0.8/codeblocks/#using-tgui).

General discussions / Re: GUI with SFML
« on: February 27, 2020, 06:44:18 pm »
What fails exactly?

Pages: [1] 2 3 ... 33