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 ... 34
1
General discussions / Re: iOS and ANdroid support?
« on: February 05, 2024, 06:20:15 pm »
Maybe the home page could be updated to clarify that SFML already supports Android and iOS. The "and soon" part makes it sound like support for mobile is not yet available.

Quote from: homepage
With SFML, your application can compile and run out of the box on the most common operating systems: Windows, Linux, macOS and soon Android & iOS.

2
You have to follow the procedure of building and installing SFML, and building the example again, but this time use "x86" instead of "armeabi-v7a" everywhere in order to get an apk that can be used in the emulator.

- armeabi-v7a is for 32-bit ARM devices (which is to support old phones, but the program of course also runs on new devices).
- arm64-v8a is for 64-bit ARM devices (all modern phones)
- x86 or x86_64 is used for running android on a PC (usually with an emulator). Which one you need depends on the emulator. The emulator you were using requires you to use "x86".

So an apk with ARM architecture will run on a real device, but not in an emulator, while an apk with x86 will run on the emulator but not on a real device. This is why your current apk is only working on a real device.

You can actually change the example later to build an apk with both x86 and armeabi-v7a so that it runs in both the emulator and real devices, but at least SFML needs to be build and installed for each architecture separately. Plus it's best to first get it working with a single architecture before attempting to make it more complex.

3
At the top of the examples/android/app/build.gradle.kts file, you need to change the constants to the versions you are using.

NDK_VERSION is set to 26.1.10909125 by default, so it is looking for SFML in that NDK version. Based on your previous posts, you used "E:/AppData/Android/SDK/ndk/25.1.8937393" when installing SFML. So you either need to use NDK 26 when building and installing SFML, or change the NDK version at the top of build.gradle.kts in the example to 25.1.8937393.

Similarly, check that the cmake value CMAKE_ANDROID_ARCH_ABI which you specified when building SFML matches with the ARCH_ABI value at the top of build.gradle.kts, otherwise you will also get the same error about SFML not being found.

Instead of changing build.gradle.kts, you can optionally pass these values as parameters to gradle, so that the command looks something like the following
gradlew assembleDebug -P ARCH_ABI=armeabi-v7a -P NDK_VERSION=25.1.8937393

Edit: In your previous posts you mentioned building and installing SFML 2 with cmake, make sure you followed these steps again with SFML 3 as well before attempting to build the example.

Edit: I've updated the wiki with the above information, as the instructions on the wiki were a bit outdated.

4
General discussions / Re: A problem occurred evaluating project ':app'
« on: January 03, 2024, 07:59:18 pm »
The android example in SFML 2.6 doesn't really support recent Gradle versions out of the box.

One thing you can still try is changing the classpath to
com.android.tools.build:gradle:7.4.1

In SFML 3 the android example was updated to use more modern versions (and it also comes with a gradlew.bat file that you can use instead of using gradle directly, so that you can always build with the correct version no matter which version you have installed).

5
Graphics / Re: Convex Shape issue
« on: December 28, 2023, 08:40:29 am »

6
SFML development / Re: DPI-Scaling on Windows
« on: December 02, 2023, 05:57:59 pm »
Quote from: eXpl0it3r
It looks like from Windows 10 on there's a thread-based function as well, which MSDN actually recommends to use instead.
SetThreadDpiAwarenessContext does look like the best option (compared to SetProcessDpiAwareness which I was still using in my changes).

I learned today that it can be used to set a different DPI per window (not just per thread): https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-improvements-for-desktop-applications

So SFML would no longer need to change the global DPI setting (on Windows 10 1607 and newer) and can make the change only for the windows that it controls.

Quote from: Hapax
SFML's removal of the scaling actually affects all windows by the instance so all windows will be "unscaled" by SFML even if not at all related to the window used SFML
By using SetThreadDpiAwarenessContext and restoring the old value after creating the window in SFML, we can at least make sure the non-related window (and according to a quick test also the parent window) won't lose their scaling.

Quote from: eXpl0it3r
Scaling behavior of the window decoration
Is there any case where someone wants an unscaled title bar?
My 2nd scaling option "Don't scaling anything" is a bit of a hack, and all other options do scale the title bar according to the monitor DPI. So maybe we should only focus on the window contents and let Windows always handle the decoration (i.e. always use Per Monitor V2 scaling)?

Quote from: Hapax
DPI-unaware should be the default
SFML hasn't supported DPI-Unaware for almost 10 years already (since this commit), and apparently earlier it didn't work correctly (which is why that commit was made). If SFML did support it and people were relying on it, then I would probably agree that it should be kept as an option. However, since nobody has been able to use it, I don't see why SFML should do more effort now to allow people to start programming without taking DPI into account.

Personally I dislike blurry DPI-Unaware apps a lot, so my opinion on DPI-Unaware support in SFML might be a bit biased and you shouldn't put too much value in my opinion.

Quote from: eXpl0it3r
I believe there's no need to have a flag to enable or disable high DPI support
I think we probably do need some flag. Both DPI-Unaware or my "Scaling everything automatically" implementation would create a window at a different size as what the user requests. There should probably be some method for the user to request a window with an exact size (only the title bar would be scaled automatically).

Quote from: Hapax
Also, I'm curious as to how "monitor-aware" windows act when there are multiple windows on different windows and also how they act when they are across 2 (or more) windows e.g. part of the window on one monitor and part of it on another.
A normal window will switch scale when it's center is located on a different monitor. For child windows, according to a quick test, they seem to just scale based on the parent window (instead of having their own scaling). If I create the parent with PER_MONITOR_AWARE_V2 and the child with UNAWARE, then the child window never changes size (when I don't handle WM_DPICHANGED to resize the parent). If I create the parent with UNAWARE and the child with PER_MONITOR_AWARE_V2, the child is scaled with the parent window when switching monitor.

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

Quote
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.

Quote
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).

Quote
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.

8
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.

9
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>").

10
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?

11
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
sf::Shader::bind(&shdr);

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.

12
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).

13
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.setFillColor(sf::Color::Green);
    shape1.setPosition({ 100, 100 });
    shape1.setSize({ 600, 400 });

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

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

            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";
            }
        }

        window.clear();
        window.draw(shape1);
        window.draw(shape2);
        window.display();
    }
}


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)

14
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".

15
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

Pages: [1] 2 3 ... 34