Messages

is that something I should consider in general or is it more something for debugging?

It's only for debugging.
The higher the number, the faster the project will build (as the number indicates how many source files can be compiled simultaneously). At least as long as the number doesn't exceed the amount of CPU threads your processor has (a higher number will work but won't make it faster) and as long as you have sufficient RAM (which becomes important for very high values).
Setting it to 1 means that all operations are done sequentially and nothing is done in parallel. This makes building much slower, but then the logs will properly show you which step is being executed when the error happens.

I now have an issue with the example for the SFML backend, encountering an undefined reference to the bool runExample(tgui::BackendGui& gui) function.

The TGUI examples found in the "examples" folder are split into 2 parts. The first part contains just the main() function and shows how to initialize the window and gui (using backend-specific code, in this case using SFML Graphics). The second part is the "runExample" function that contains the code that is backend-independent and which is thus the same no matter whether you are using SFML, SDL or GLFW. The second part is found inside either the "scalable_login_screen" or "many_different_widgets" subfolder.

I'm guessing you only have a declaration like "bool runExample(tgui::BackendGui& gui);" in your current code. You can replace it with the following to have an example that compiles:

Code (cpp) Select Expand

bool runExample(tgui::BackendGui& gui)
{
    return true;
}
The website contains some more example codes: https://tgui.eu/examples/latest-stable/

The error isn't with the gui builder. If you set TGUI_BUILD_GUI_BUILDER to OFF then you would get the same error.

The library name passed to "target_link_libraries" should be either "TGUI::TGUI" (recommended) or "tgui" (deprecated), but "TGUI" is wrong.

The cmake command that is being executed has "-j 6" in it. Is this something you can change yourself? The log output would have been more clear if you ran it with "-j 1" (which you should only do when investigating an issue, as usually you do want to build with more threads). Now it builds your project and the gui builder at the same time so it prints both outputs interleaved and it isn't clear that the error is about your project and not the gui builder.

You can just create a new font object:

Code (cpp) Select Expand

tgui::Font font;
font = tgui::Font("font.ttf");
There is practically no performance cost in copying the Font object, as it is a lightweight object that will just share its internal resources between the different font objects.

Note that unlike Texture objects, creating multiple Font objects with the same filename will cause the file to be loaded multiple time. So to keep memory usage minimal, you should only call the tgui::Font("font.ttf") constructor once in your code and then just copy that font object to anywhere that you need it.

Now the log output looks more normal.
You need to move the set(SFML_DIR "c:/SFML/lib/cmake/SFML") line in your script to ABOVE the "add_subdirectory(TGUI)" line.

Also, your code should either contain "add_subdirectory(TGUI)" or "set(TGUI_DIR ...)\n find_package(TGUI 1 REQUIRED)", but not both of these.

I'm a bit confused about how the project is being build.

The log contained the following line:

[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=C:\mingw64\bin\gcc.exe -DCMAKE_CXX_COMPILER:FILEPATH=C:\mingw64\bin\g++.exe -SC:/Users/luka-/OneDrive/Desktop/AutoBackupScript2/TGUI -Bc:/Users/luka-/OneDrive/Desktop/AutoBackupScript2/build -G "MinGW Makefiles"

The source directory is being set to the "TGUI" subdirectory, but the build directory is the one from your project? That would mean that it is trying to build TGUI and your own cmake script isn't even being executed.

If that command where to contain "-DSFML_DIR=c:/SFML/lib/cmake/SFML" then it would probably build TGUI successfully. However that would only build TGUI and not your project, so you probably want to change the source directory instead.

The set(SFML_DIR "c:/SFML/lib/cmake/SFML") should be sufficient when placed before the find_package or add_subdirectory line.

TGUI tries to find SFML with "find_package(SFML 2 CONFIG COMPONENTS graphics REQUIRED)".

- Which files does c:/SFML/lib/cmake/SFML contain?
- Which SFML version is located in c:/SFML?
- Did you build SFML yourself or download a precompiled version from their website?
- Which MinGW version are you using?

Is the Scene class perhaps being destructed after the main() function has finished executing?
SFML and TGUI objects need to be destroyed before the end of the main function and shouldn't be part of a static global object.

Edit: Also, all TGUI widgets need to be destroyed before the Gui object is destroyed.

Actually I think this issue was fixed already recently.
The "Texture::operator==" contained a bug where it considered two images with the same filename but a different part rect to be identical to each other.
So calling setTexture would do nothing because the code thought that you were just setting the same texture again.

I just uploaded TGUI 1.2.0 to the website (if it still shows 1.1 on the download page then refresh the page with ctrl+F5). If you use that version then this and the earlier reported bug should be fixed.

It's probably best to put it in a new topic.

Definitely a bug. Two bugs even.

This has now been fixed in the last TGUI 1.x-dev version.
Just in time for the TGUI 1.2 release that is coming later today.

You will need the touch events that you get directly from SFML in your main loop for this.

I could maybe add a new event, something like a PinchZoom event, which works similarly to mouse wheel scrolling (i.e. has one + or - parameter with a relative value since the last position). I'm however uncertain how to properly detect a pinch zoom, and I'm not sure what the value should even be. As soon as you put 2 fingers down, TGUI will currently already think that you are scrolling with two fingers (which is an assumption I could only make because no other gestures were supported). So adding the event (which I'd be willing to do), is the least amount of work. Getting both zooming and scrolling with two fingers to behave well would be a lot harder (and not something that I'm currently willing to do).

You are defining SMFL_STATIC (which even has a typo) and TGUI_STATIC, but you are linking to the dynamic libraries (i.e. the ones that don't end have "-s" in the name). So you should remove SMFL_STATIC and TGUI_STATIC from the PreprocessorDefinitions.

I'm assuming you would also get a linking error when using e.g. tgui::Color::Black in your code?

While I haven't seen this issue with TGUI yet, I remember seeing similar issues before with SFML (where people got linking errors only for the "static" variables). I think the cause might have been mixing libraries like shared vs static ones.

Can you maybe share the .vcxproj file of your project so that I can check if I can see something unusual about it?

My first instinct was to just render with both versions of the code and see which one looked correct, so that I didn't have to bother with understanding the math again, but I couldn't visually tell the difference between both variants

I think my code is correct though.

Let's examine the bottom left corner. The first point needs to be at the leftmost position (as it is connected by a vertical line from the last point of the top-left corner), while the last point needs to be at the bottom-most position (as it needs to be connected with a horizontal line to the first point of the bottom-right corner).
So when you plug in i=0 in the formula, you need to get a cos value of -1 and a sin value of 0. When you set i=nrCornerPoints-1 (the last iteration of the for loop), the cos value should be 0 and the sin value should be -1. I verified with WolframAlpha that this is the case when using my formula.

The thing that makes it weird is probably that when drawing a circle (instead of a rounded rectangle), the top, right, bottom and left points on the circle are duplicated. There is also the fact that the "nrPointsInCircle" might be a bad name. There are "4 * nrCornerPoints" points in total, but "nrPointsInCircle" is set to "4 * (nrCornerPoints - 1)" (the amount of unique points when drawing a circle instead of a rounded rectangle).