Messages

1

General / Re: console disable c++

« on: April 30, 2023, 08:00:31 pm »

this blogpost might help you, which covers the topic:
"Getting rid of the console window using SFML and CMake on Windows-OS"

http://zaunfish.blogspot.com/2017/

2

General / Re: Unable to use RSFML

« on: July 31, 2022, 12:34:48 pm »

This blog article might be helpful
https://zaunfish.blogspot.com/2022/07/setting-up-rust-sfml-with-mingw-w64-on.html

3

General / CMake: Could not find a configuration file for package "SFML" that is compatible

« on: January 23, 2022, 08:49:23 am »

I have a hard time compiling SFML on my machine.
In the past i have done the following procedure like a 1000 times without having any issues, but now i receive the following error:

CMake Error at CMakeLists.txt:5 (find_package):
  Could not find a configuration file for package "SFML" that is compatible
  with requested version "2.5".

  The following configuration files were considered but not accepted:

    C:/Program Files (x86)/SFML/lib/cmake/SFML/SFMLConfig.cmake, version: 3.0.0



-- Configuring incomplete, errors occurred!
See also "C:/src/test/build/CMakeFiles/CMakeOutput.log".

I compiled SFML on different Windows Versions (10 and 11) and used different versions of mingw-w64 (from https://winlibs.com/), but i always get this error. I never had this issue before. The steps i did:

• Get SFML from Github
• Create Makefiles with CMake, using MinGW Makefiles as generator
• run "mingw32-make install" in the CMake-Build-Folder that i need to select in CMake-GUI

I use this basic CMakeLists.txt-file to build the project:

cmake_minimum_required(VERSION 3.1)

project(SFMLTest)

## If you want to link SFML statically
# set(SFML_STATIC_LIBRARIES TRUE)

## In most cases better set in the CMake cache
# set(SFML_DIR "<sfml root prefix>/lib/cmake/SFML")

find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)
add_executable(SFMLTest main.cpp)
target_link_libraries(SFMLTest sfml-graphics sfml-audio)

Here a similar error-message has been discussed: https://github.com/SFML/SFML/issues/1593
OP stated at one point "You were right. I used the wrong compiler in this project. Thank you!", however i don't think this is the reason in my case why find_package() does not work anymore.

EDIT: When i did the exact same steps described above with the SFML-Source from here:
https://www.sfml-dev.org/files/SFML-2.5.1-sources.zip
the described error does not occure.

I also double-checked this. The error can be reproduced if i use the Github Source-Code. When i use the source from https://www.sfml-dev.org/files/SFML-2.5.1-sources.zip everything is ok. 

4

General / Can't compile SFML on Windows 11

« on: October 17, 2021, 07:38:24 pm »

[EDIT]
I could pinpoint the issue: https://winlibs.com/ offers two versions of the mingw-w64 compiler: One ships with UCRT runtime, the other with MSVCRT runtime. With MSVCRT runtime i had no compilation issues. Visual Studio Compiler also had no issues compiling SFML on Windows 11. So i guess its something with the UCRT runtime.
[/EDIT]


I tried to compile SFML on Windows 11 and it fails with the following error-message:

[ 79%] Building CXX object src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/RenderTextureImpl.cpp.obj
[ 79%] Building CXX object src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/RenderTextureImplFBO.cpp.obj
[ 80%] Building CXX object src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/RenderTextureImplDefault.cpp.obj
[ 81%] Building RC object src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/sfml-graphics.rc.obj
[ 82%] Linking CXX shared library ..\..\..\lib\sfml-graphics-2.dll
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/Keen/Downloads/SFML-master/extlibs/libs-mingw/x64/libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x5614): undefined reference to `_setjmp'
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/Keen/Downloads/SFML-master/extlibs/libs-mingw/x64/libfreetype.a(smooth.c.obj):smooth.c:(.text+0x77a): undefined reference to `_setjmp'
collect2.exe: error: ld returned 1 exit status
mingw32-make[2]: *** [src\SFML\Graphics\CMakeFiles\sfml-graphics.dir\build.make:602: lib/sfml-graphics-2.dll] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:307: src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/all] Error 2
mingw32-make: *** [makefile:155: all] Error 2

I did not have this issue on Windows 10 using the same procedure described below:

• 1. I use mingw-w64 compiler from https://winlibs.com/ (GCC 11.2.0 + LLVM/Clang/LLD/LLDB 13.0.0 + MinGW-w64 9.0.0 - UCRT-Runtime)
  
• 2. Download SFML from https://github.com/SFML/SFML
  
• 3. generate CMake-Files for MinGW.
  
• 4. in Build-Folder: "mingw32-make install"
  

It compiles until 82 % and than cannot find '_setjmp'.
Compilation of SFML always worked for me in the past, this is the first time that it cannot get through to 100 %. Maybe it has something to do with Win 11?

5

Network / Re: Sending sf::Packet via asio fails partly

« on: September 10, 2021, 11:37:43 pm »

Thank you for the replies! Laurents answer got me on the right track.
I changed the function to

void Server::handle_receive(const asio::error_code &error, std::size_t l_receivedBytes) {
    sf::Packet packet;
    std::cout << "received bytes: " << int(l_receivedBytes) << "\n";
    packet.append(m_receiveBuffer.data(), l_receivedBytes);
    uint8_t num1; uint8_t num2;
    packet >> num1 >> num2;
    std::cout << int(num1) << ", " << int(num2) << ".\n"; // Output: 5, 6
    receiveData();
}

and now the console prints the right values. One of the reasons i got it wrong at first was that i initially even tried using

uint8_t num1

instead of

int num1

but printing uint_t to the console resulted  in strange symbols displayed in the console instead of the numerical values, therefore i wrongly assumed that i produced an error using uint8_t and switched to int, which at least printed some numerical values to the console. My bad. 

However, every time i use some other library (like asio) it reminds me about how well designed SFML is and how effectively it is in hiding the confusing low-level stuff, while still allowing to mix it with low-level libs, if needed.

6

Network / Re: Sending sf::Packet via asio fails partly

« on: September 10, 2021, 10:43:41 am »

i found out that the checkSize() method from

// SFML Packet.cpp
Packet& Packet::operator >>(Int32& data)
{
    if (checkSize(sizeof(data)))
    {
        std::memcpy(&data, &m_data[m_readPos], sizeof(data));
        data = ntohl(data);
        m_readPos += sizeof(data);
    }

    return *this;
}

returns false, thus the data does not get copied into the Int32& data parameter. But i don't know why the check fails.

7

Network / Sending sf::Packet via asio fails partly

« on: September 09, 2021, 09:16:27 pm »

I programmed a pong multiplayer game using SFML, where i used sf::UdpSockets for transferring data between two PCs. It worked great. Next i wanted to check out how the result would look like if i used the asio network library for networking instead of the SFML Network-classes.

Here my first big issue was, that asio does not provide a class similar to sf::Packet that helps with serializing the data.
With SFML its so beautifully simple, for example if you want to store an enum and some data that belongs to the enum, you could just do:

enum class CommandsToServer{
        Connect, // empty
        Disconnect, // empty
        Data // Vector2f
};
...

sf::Packet packet;
packet << static_cast<uint8_t>(CommandsToServer::Data);
packet << x << y;

and send the packet to the server, where you unpack the content the same way you put it in.

uint8_t command;
uint8_t x, y;
// ... receive packet from socket ...
receivedPacket >> command >> x >> y;
CommandToServer commandToServer = static_cast<CommandToServer>(command);
 

Since i did not find a straightforward way to pack different types into an array, i just used sf::Packet again with the asio::ip::udp::socket.

This approach looks like this:

    m_packet << static_cast<uint8_t>(5);
    m_packet << static_cast<uint8_t>(6);
    m_socket.send_to(asio::buffer(m_packet.getData(), m_packet.getDataSize()), m_serverEndpoint);

So i just try to transfer two values over the network: 5 and 6.

On the server-side i use

std::array<char, 256> m_receiveBuffer;
...
// in some function
    m_socket.async_receive_from(
            asio::buffer(m_receiveBuffer), m_remoteEndpoint,
            std::bind(&Server::handle_receive, this,
                      std::placeholders::_1,
                      std::placeholders::_2));
 ...

void Server::handle_receive(const asio::error_code &error, std::size_t l_receivedBytes) {
    sf::Packet packet;
    std::cout << "received bytes: " << int(l_receivedBytes) << "\n"; // Output: received bytes 2
    packet.append(m_receiveBuffer.data(), l_receivedBytes);
    int num1; int num2;
    packet >> num1 >> num2;
    std::cout << num1 << ", " << num2 << ".\n"; // Output: 0, 0
    receiveData();
 

Console prints 0, 0. But if i start the debugger and set a breakpoint at the last std::cout-statement, i can see that
packet has the following members:
m_data
[ 0 ] = {char}5 '\005'
[ 1 ] = {char}6 '\006’
m_readPos = 0
m_sendPos = 0
m_isValid = false

Its strange because the values 5 and 6 have apparently been transferred successfully, since they are stored in the std::vector<char> container of sf::Packet. However, they don't get transferred via the >> operator into the variables num1 and num2. I don't know the reason why i cannot transfer the data out of the sf::Packet into the variables on the server-side.

8

General discussions / Re: SFML Game Development by Example - 4th SFML book

« on: October 27, 2020, 11:47:21 pm »

Hi OrderNexus,
i may have discovered a subtle bug in the EventManager-Class.

EventManager.h

struct EventInfo{
        EventInfo(){ m_code = 0; }
        EventInfo(int l_event){ m_code = l_event; }
        EventInfo(const GUI_Event& l_guiEvent){ m_gui = l_guiEvent; }
        union {
                int m_code;
                GUI_Event m_gui;
        };
};

If no argument is passed to an EventInfo Constructor during Object-Creation, the EventInfo's default constructor is invoked which initializes the union member int m_code to 0. So when creating an EventInfo object with a default constructor you are not allowed to use the other union member (here m_gui), this would lead to undefined behaviour.

EventManager.cpp

void EventManager::LoadBindings(){
    ...
        EventInfo eventInfo;
        if (type == EventType::GUI_Click || type == EventType::GUI_Release ||
            type == EventType::GUI_Hover || type == EventType::GUI_Leave)
        {
               ...
        eventInfo.m_gui.m_interface = w;
        eventInfo.m_gui.m_element = e;
        }
 ....

in EventManager::LoadBindings() an EventInfo-object is created with a default constructor (EventInfo eventInfo). However further down below, if the EventType is some GUI-Type, the eventInfo.m_gui-variable is getting assigned to the data that is read from the config-file (here w & e). I consider this assignmeht as undefined since the created EventInfo-Object can only use the "int"-variable from its union-members. Or am i missing here something?

9

General / Re: MinGW + SFML + CLion (Windows 10)

« on: April 09, 2020, 11:38:40 am »

Hey there,
i use a similar setup as you (but mingw-w64 instead of mingw). I had also some trouble getting newest SFML version to run with CMAKE and CLION. However with Laurents help i was able to get it to run. Here the whole process is described in detail, it may be helpful for you.

https://en.sfml-dev.org/forums/index.php?topic=26960.0

10

General / Re: SFML 2.5 CMake configuration

« on: February 22, 2020, 08:32:13 pm »

i altered step Nr.6 (and Nr.12) with the command „mingw32-make install". It builds the libs in "C:\Program Files (x86)\SFML". However the strange behaviour remains the same :-(

Then you must set SFML_DIR to C:\Program Files (x86)\SFML, not C:\SFML.

This finally did the trick, everything works now as expected in Clion. Thanks a lot!

11

General / Re: SFML 2.5 CMake configuration

« on: February 22, 2020, 01:44:08 pm »

i altered step Nr.6 (and Nr.12) with the command „mingw32-make install". It builds the libs in "C:\Program Files (x86)\SFML". However the strange behaviour remains the same :-(

When i don't touch Clion everything works as expected. The Release-Build and Debug-Build of my SFML-Application both gets compiled and run fine.
However when the last Build of SFML with "mingw32-make install" is done with CMAKE_BUILD_TYPE=Debug and i additionally open up Clion and run my SFML-Application in "Release-Mode" the Release-Build of my Program breaks because he searches for *-d-2.dll files (as shown in Nr.15 above).

When i erase all files in the cmake-release-build-Folder and compile everything from scratch via CMD exactly how i done it before i opened and compiled it with Clion, it compiles fine, but the application still won't start because a "*-d-2.dll" is missing which makes no sense since i did run cmake with -DCMAKE_BUILD_TYPE=Release when invoking it from the cmake-release-build-Folder.

Clion seems to scramble something because when i don't touch the SFML-Application with Clion, everything works flawlessly and as expected.

What irritates me the most is that i can't get it to run properly after i compiled my SFML-Program with Clion, except i delete C:/SFML and build it again from scratch.

12

General / Re: SFML 2.5 CMake configuration

« on: February 21, 2020, 09:42:42 pm »

Hi Laurent,
i was able to tackle the issue further down. It seems to be not related to the new SFML CMake System but to my IDE (Clion). Here are the exact steps that lead to the error i encountered. I noticed that when i compile everything "by hand" via CMD the error does not occure. However compiling with CLion provokes the error.
In Detail:

Steps:
1.   Download SFML from Github


2.   Extract ZIP-Contents to Download-Folder

3.   Open Up CMake
-   Set „Where is the source code“ to SFML-Directory in Download-Folder
-   Set „Where to build the binaries“ to C:/SFML which will be the place to store all SFML libraries


4.   Click on „Configure“, specify the Generator to „MinGW Makefiles“ since i use mingw-w64-compiler, use checkbox „Use default native compilers“, click „Ok“


5.   Set „CMAKE_BUILD_TYPE“ to „Release“
and click on „Generate“


6.   Open CMD in administrator-mode, go to C:/SFML, compile the generated CMake-Makefile with command „mingw32-make“


7.   I receive this compiled Libraries in C:/SFML/libs


8.   I copy the received dll-files (for example „sfml-graphics-2.dll“) from C:/SFML/libs to the Destination-Folder where the release-version of my SFML-Application is going to be compiled. Here it is „D:\Nextcloud\C++\observer4\cmake-build-release“


9.   I open up CMD, go to that folder where the release version of my SFML-Application is going to be created and create a makefile with the command „cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release ..“


10.   Then i compile the project with „mingw32-make“ and run the executable. It starts without issues.


11.   I go back to CMake and repeat step 5. But this time i set CMAKE_BUILD_TYPE to „Debug“ and click on generate


12.   I repeat Step 6, after compilation i have not only the release-libraries, but also the debug-libararies of SFML in „C:/SFML/libs“


13.   I copy the received dll-files (for example „sfml-graphics-d-2.dll) from C:/SFML/libs to the Destination-Folder where the debug version of my SFML-Application is going to be compiled. Here it is „D:\Nextcloud\C++\observer4\cmake-build-release“

14.   Then i create a makefile with the command „cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug ..“ and compile.
The Program runs fine.


15.   When i open my IDE Clion and run the program in release mode, it suddenly does not work anymore. The same applies when i try to start the release-version from CMD after i have tried to run it from Clion.


16. Now when i switch the content of the CMakeLists.txt file in "„D:\Nextcloud\C++\observer4\" from

cmake_minimum_required(VERSION 3.10)
project(observer4)
set(CMAKE_CXX_STANDARD 17)
set(SFML_DIR "C:/SFML")
find_package(SFML COMPONENTS graphics window system)
add_executable(observer4 main.cpp etc. etc.)
target_link_libraries(observer4 sfml-graphics)
 

to

cmake_minimum_required(VERSION 3.10)
project(observer4)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/modules)
set(SFML_ROOT "C:/SFML")
find_package(SFML COMPONENTS graphics window system)
include_directories(${SFML_INCLUDE_DIR})
add_executable(observer4 main.cpp etc. etc.)
target_link_libraries(observer4 ${SFML_LIBRARIES})

and compile everything again, the SFML-Application starts running from Clion and CMD.

13

General / Re: SFML 2.5 CMake configuration

« on: February 20, 2020, 07:52:29 pm »

My assumption is that since you're not specifying a CMAKE_BUILD_TYPE for your own CMake script, CMake is simply inferring the type based on the libraries it finds, which then leads to your build picking release libraries, if they are provided, but since you're not providing the release DLLs, it crashes. Once you do provide them, it runs fine.

I made a screenshot where you can see that although i set CMAKE_BUILD_TYPE to Release in CMD it still complains that sfml-graphics-d-2.dll is missing. This happens only when the last compilation of the sfml-source-code in "C:/SFML" is done in debug-mode to create the debug-libraries in C:/SFML.

The same applies the other way around: When the last compilation of the SFML-Source to C:/SFML is done in release-mode, the debug-compilation of my SFML-Application will only accept release-dll-files regardless if the CMAKE_BUILD_TYPE is set to Debug. 

When i change the CMakeLists.txt of the SFML-Program to FindSFML.cmake the compiled release-executable in the cmake-build-release-folder works fine with the release-dll-files in the same folder. Same goes for the debug-version in cmake-build-debug-folder with the corresponding debug-dll-files.

EDIT: You may need to open the attached Screenshot in a new Window to see the whole picture because of its size & thanks for the fast reply btw.
 

14

General / SFML 2.5 CMake configuration

« on: February 19, 2020, 07:52:53 pm »

I have an issue with the new CMake Build Tool. It basically works, but there is a catch.
My CMakeLists.txt file of my SFML-Program looks as follows:

cmake_minimum_required(VERSION 3.10)
project(observer4)

set(CMAKE_CXX_STANDARD 17)
set(SFML_DIR "C:/SFML")
find_package(SFML COMPONENTS graphics window system)
add_executable(observer4 main.cpp )
target_link_libraries(observer4 sfml-graphics sfml-audio)
 

When run CMake everything works smoothly.

-- Found SFML 2.5.1 in C:/SFML
-- Configuring done
-- Generating done
-- Build files have been written to: D:/Nextcloud/C++/observer4/cmake-build-debug

1. When I compile SFML Source-Code (v.2.5.1.) with CMAKE_BUILD_TYPE set to Debug and put everything to C:/SFML, and copy all newly created dll-files...

sfml-graphics-d-2.dll
sfml-audio-d-2.dll
sfml-network-d-2.dll
sfml-system-d-2.dll
sfml-window-d-2.dll

...to the cmake-build-debug-folder of my SFML-Program where the binary that is compiled in debug-mode will get created, everything works fine; the SFML-Application starts without hassle.

But when i now repeat compiling SFML with CMAKE_BUILD_TYPE set to Release, which adds the corresponding compiled "release-SFML-Files" to C:/SFML, the compilation of the SFML-Program in debug-mode suddenly breaks.
The compilation in debug-mode fails with:

Process finished with exit code -1073741515 (0xC0000135)

In the folder C:/SFML/libs this files resides:

libsfml-audio-d.a
libsfml-graphics-d.a
libsfml-main-d.a
libsfml-network-d.a
libsfml-system-d.a
libsfml-window-d.a
[all release and debug DLL-Files]
libsfml-audio.a
libsfml-graphics.a
libsfml-main.a
libsfml-network.a
libsfml-system.a
libsfml-window.a

I did not touch the debug-dll-files in the cmake-build-debug-folder of my SFML-Program where the binary is being compiled.

When i delete

libsfml-audio.a
libsfml-graphics.a
libsfml-main.a
libsfml-network.a
libsfml-system.a
libsfml-window.a

in C:/SFML/libs, which should be no problem, because i compile the SFML-Application in debug mode, the compiler throws this error:

mingw32-make.exe[2]: *** No rule to make target 'C:/SFML/lib/libsfml-graphics.a', needed by 'observer4.exe'.  Stop.
mingw32-make.exe[1]: *** [CMakeFiles\Makefile2:75: CMakeFiles/observer4.dir/all] Error 2
mingw32-make.exe: *** [Makefile:83: all] Error 2

Why does the compiler need C:/SFML/lib/libsfml-graphics.a' ? Im compiling in debug-mode...he should rely on C:/SFML/lib/libsfml-graphics-d.a'. Same goes for the other files. when i return libsfml-graphics.a from trash, he asks for libsfml-window.a, when i return the file, he asks for libsfml-system.a etc. until it finally throws

Process finished with exit code -1073741515 (0xC0000135)

when all release-files (libsfml-audio.a, libsfml-graphics.a, etc. are back.

The weirdest thing is:

Process finished with exit code -1073741515 (0xC0000135)

goes away and the SFMl-Program starts when i copy the release-dll-files (sfml-graphics-2.dll, sfml-window-2.dll etc.) to the cmake-build-debug-folder. In fact, i can even delete all the debug-dll-files.
The Application only needs the release-files though i compiled it in debug-mode.

This is default behaviour out of the box which does not occure when i use a FindSFML.cmake file. When using FindSFML.cmake i can have all SFML-files (debug & release) in C:/SFML/libs in one place and just use the debug-dll-files for the debug build and the release-dll-files for my release-build.

15

General / Re: Odd stripes on different monitors

« on: February 12, 2020, 10:56:15 pm »

If it's working on one operating system with one set of drivers but not on another with another set of drivers, it could be a faulty graphics card driver. It's worth updating the driver fully anyway but certainly on the one that is having the problem. If it's still having a problem, it's possible that that driver for that operating system just hasn't been fixed yet

thank you so much, you saved my day! I installed the newest beta drivers for my vega56 card. -> Stripes were still present. I uninstalled the Graphics-Drivers completely with DDU (Display Driver Uninstaller): Now the Stripes were only present when moving the camera, but dissapeared when standing still (at least an improvement). Now i again installed the newest beta drivers -> The Stripes finally completely dissapeared! So it actually was a Driver-Issue as you suggested!