Messages

1

Graphics / Re: Using GetWindowHandle() to make the window background transparent.

« on: August 27, 2024, 09:02:54 am »

Also note that the SetWindowLongPtrA documentation contain the following notice about the return type:

If the previous value is zero and the function succeeds, the return value is zero, but the function does not clear the last error information. To determine success or failure, clear the last error information by calling SetLastError with 0, then call SetWindowLongPtr. Function failure will be indicated by a return value of zero and a GetLastError result that is nonzero.

So the function can return 0 even if there isn't an error. And only calling GetLastError to figure out if there was an error is unreliable (because it could still contain an error from an earlier win32 function call).

So based on the docs you would need something like the following:

SetLastError(0);
result = SetWindowLongPtrA(...);
if ((result == 0) && (GetLastError() != 0))
{
    // TODO: Print out what the value of GetLastError() is, so you can look up what the real error is
    MessageBox(handle,"Error","Error",MB_OK);
}

If that still fails, then make sure you know what GetLastError() returns, if you weren't doing anything weird with processes or threads then there is always the possibility that it is failing for some other reason that isn't explicitly mentioned in the docs.

2

General / Re: Compiling GCC into the exe

« on: August 03, 2024, 07:24:45 am »

These linking errors are because you aren't linking to SFML's dependencies (which as requires when linking statically).

If you link to sfml-graphics-s then you also need to add the following libraries to the linker (you don't need to tell codeblocks where to find them as those are system libraries):

Code: [Select]

opengl32
freetype
winmm
gdi32

If you are going to link to sfml-network-s and sfml-audio-s (which is only needed when you need these modules), then you need to add even more libraries, see the list in https://www.sfml-dev.org/tutorials/2.6/start-cb.php

3

Graphics / Re: Get the maximum possible height of single line sf::Text

« on: June 18, 2024, 07:00:03 pm »

I wouldn't recommend using the branch I created. You could download the code from https://github.com/texus/SFML/tree/feature/font-ascent-descent and compile it with CMake if you want to, but I don't intend to keep the branch up-to-date with new changes being made into SFML.
The pull request that I linked to is something that will hopefully be merged into SFML at some point. I don't know how much they care about this functionality, I imagine that it has a low priority for now while they focus on API breaking changes for the SFML 3.0 release and might only properly look into this in a later update (e.g. SFML 3.1).

While having access the the ascent and descent allows fine control over the position of your text, maybe you don't necessarily need them right now.

Are you rendering the lines as a single sf::Text object (which contains newlines in its string)?
In that case you know that the distance between each line is exactly `font->getLineSpacing(characterSize)` (unless you called setLineSpacing on the sf::Text object, in which case you need to multiply it with that factor).

If you are rendering each line with a different sf::Text object then you can still use `font->getLineSpacing(characterSize)` to position them below each other. This will only fail with broken fonts, so unless you allow the user to set custom fonts you can ignore that.

In either case you may want to move the text or each line slightly upwards to compensate for the difference between characterSize and ascent (if you feel like text is always positioned slightly too low). The following code will get the ascent from the Ê character if it exists in the font, otherwise it assumes that characterSize equals the ascent and hope for the best.

Code: [Select]

float topOffset = 0;
if (font->hasGlyph(U'\u00CA'))
  topOffset -= font->getGlyph(U'\u00CA', characterSize, false, 0).bounds.height;

4

Graphics / Re: Get the maximum possible height of single line sf::Text

« on: June 18, 2024, 11:48:48 am »

This is why I created https://github.com/SFML/SFML/pull/3053
The information exists, SFML just doesn't expose it.

I've used "Êg" for finding the line height.
You can also check the getLineSpacing in the Font class. It will usually be close or equal to the size you need (unless the font is broken for multi-line texts).

5

Graphics / Re: Is it safe to overwrite sf::Texture after calling render_texture.draw()?

« on: April 29, 2024, 12:40:43 pm »

dynamic_pointer_cast will return a nullptr if the backend texture is of a different type, while static_pointer_cast assumes the type is correct and has undefined behavior if the backend texture is of a different type.

As long as you use the SFML_GRAPHICS backend, you can be certain that the backend texture always has type BackendTextureSFML, so the cast will always succeed and a static_pointer_cast is fine. Also, there is no point in using dynamic_pointer_cast if you aren't going to check whether the return value is a nullptr or not.

6

Graphics / Re: Is it safe to overwrite sf::Texture after calling render_texture.draw()?

« on: April 29, 2024, 08:33:53 am »

If you need a texture that you use for drawing in SFML and you also use for TGUI then I actually recommend loading it twice (once as sf::Texture and once as tgui::Texture), because TGUI makes no guarantees about how its texture is stored internally and whether it will be compatible with sf::Texture.

That said, you can get access to the internal SFML texture with the methods that eXpl0it3r mentioned:

const sf::Texture* pTex = &std::static_pointer_cast<tgui::BackendTextureSFML>(texture.getData()->backendTexture)->getInternalTexture();
rect.setTexture(pTex);

7

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.

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.

8

General discussions / Re: [Solved] How to build SFML 3 with gradlew for Android on Window 10 with MinGW?

« on: January 04, 2024, 08:41:40 am »

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.

9

General discussions / Re: How to build SFML-master with gradlew for Android?

« on: January 03, 2024, 10:26:26 pm »

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.

10

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

11

Graphics / Re: Convex Shape issue

« on: December 28, 2023, 08:40:29 am »

It's related to the outline thickness, see https://github.com/SFML/SFML/issues/2727 and https://github.com/SFML/SFML/pull/2741

12

SFML development / Re: DPI-Scaling on Windows

« on: December 02, 2023, 05:57:59 pm »

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.

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.

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

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.

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

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.

13

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.

14

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.

15

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