1
General / Re: Problem with static linking SFML 2.5.1
« Last post by eXpl0it3r on Today at 12:36:54 am »Did you build SFML yourself?
Recent Posts
2
General discussions / Re: Can someone send a builded sfeMovie library?
« Last post by eXpl0it3r on Today at 12:35:26 am »Guess you're in luck that I just recently built them. It's for VS 2019 x64 and include debug and release shared libraries (incl. SFML).
sfeMovie-VS2019-x64.7z
sfeMovie-VS2019-x64.7z
3
General discussions / Can someone send a builded sfeMovie library?
« Last post by youngkreskov1337 on June 06, 2020, 07:52:16 pm »Hi, can someone send in a built sfeMovie library?
4
General / Problem with static linking SFML 2.5.1
« Last post by Marfi on June 06, 2020, 04:43:22 pm »Hello to everyone.
I'm having issues when trying to static link.
I'm using this version of sfml 2.5.1 and
g++ --version
g++ (MinGW.org GCC-6.3.0-1) 6.3.0
if I try to compile with dynamic link everything is going fine
g++ -g main.cpp -I"e:\SFML-2.5.1\include" -o main.exe -L"e:\SFML-2.5.1\lib" -lsfml-graphics-d -lsfml-window-d -lsfml-system-d -lopengl32 -lwinmm -lgdi32
but if I try to static link
g++ -DSFML_STATIC -g main.cpp -I"e:\SFML-2.5.1\include" -o main.exe -L"e:\SFML-2.5.1\lib" -lsfml-graphics-s-d -lsfml-window-s-d -lsfml-system-s-d -lopengl32 -lwinmm -lgdi32
I have got:
e:\SFML-2.5.1\lib/libsfml-system-s-d.a(Err.cpp.obj): In function `sync':
D:/Programming/C++/Releases/_Sources/SFML/src/SFML/System/Err.cpp:87: undefined reference to `_imp____acrt_iob_func'
collect2.exe: error: ld returned 1 exit status
Can anyone point me what I'm doing wrong?
I'm having issues when trying to static link.
I'm using this version of sfml 2.5.1 and
g++ --version
g++ (MinGW.org GCC-6.3.0-1) 6.3.0
if I try to compile with dynamic link everything is going fine
g++ -g main.cpp -I"e:\SFML-2.5.1\include" -o main.exe -L"e:\SFML-2.5.1\lib" -lsfml-graphics-d -lsfml-window-d -lsfml-system-d -lopengl32 -lwinmm -lgdi32
but if I try to static link
g++ -DSFML_STATIC -g main.cpp -I"e:\SFML-2.5.1\include" -o main.exe -L"e:\SFML-2.5.1\lib" -lsfml-graphics-s-d -lsfml-window-s-d -lsfml-system-s-d -lopengl32 -lwinmm -lgdi32
I have got:
e:\SFML-2.5.1\lib/libsfml-system-s-d.a(Err.cpp.obj): In function `sync':
D:/Programming/C++/Releases/_Sources/SFML/src/SFML/System/Err.cpp:87: undefined reference to `_imp____acrt_iob_func'
collect2.exe: error: ld returned 1 exit status
Can anyone point me what I'm doing wrong?
5
Window / Hitching and Crashing with multiple sf::Window handles
« Last post by Ant on June 05, 2020, 11:17:58 pm »I've been experiencing hitches with sf::Window::pollEvents function. Most of the time, the application can run smoothly (over 100 fps). But every few seconds, the app hitches on this function.
I've been struggling with this for awhile. The best theory I have is maybe because there many window handles in this application. The application I have is basically runs multiple unit tests so it pops up about five windows on a thread. And to test this theory, I closed all but one of the windows. And it seems to never hit that break point when it's down to one window handle.
I tried moving one of the tests to its own thread, but by doing so, I'm running into a new issue where creating a new window handle on the separate thread causes an infinite recursion crash.
Callstack crash:
While reading through docs and forums, I learned about sf::Window::setActive. Although I call setActive(true) during the draw/render stage, it did not seem to make a difference. Then I started calling setActive(false) everywhere (after creating sf::RenderWindow, before render calls, before pollEvents, etc...). I know that's not the right way of doing things, but I was hoping it would at least 'lock' the windows instead of crashing whenever I create a window handle on a different thread.
I've did this for sf::RenderTextures, too. And I'm still crashing whenever I create a window handler on the other thread.
And here I am currently stuck. I'm running SFML version 2.4.0. I suppose I can upgrade it to a later version in case there was a bug fix for this.
Questions I have are:
1. Any idea why polling events sometimes take over 150 milliseconds even though there aren't any events?
2. When do I need to call setActive on a window handle? Can it only be activated before calling clear, draw, display functions? Or do I need to activate the window handles when polling events, too? I presume the same should be done for sf::RenderTextures, too.
3. Any idea what could be causing the infinite recursion crash? If the windows are self contained in their own threads, is it possible to handle windows and render textures in multiple threads if setActive is called appropriately?
Stopwatch pollEventsStopwatch;
int counter = 0;
sf::Event sfEvent;
while (Resource != nullptr && Resource->pollEvent(sfEvent))
{
counter++;
//Do stuff in this loop, but this loop is never iterating since there aren't any events.
}
FLOAT elapsedTime = pollEventsStopwatch.GetElapsedTime();
if (elapsedTime > 50)
{
int breakHere = 0; //<---- I'm hitting this breakpoint since elapsed time is usually above 150 milliseconds even when counter is 0.
}
int counter = 0;
sf::Event sfEvent;
while (Resource != nullptr && Resource->pollEvent(sfEvent))
{
counter++;
//Do stuff in this loop, but this loop is never iterating since there aren't any events.
}
FLOAT elapsedTime = pollEventsStopwatch.GetElapsedTime();
if (elapsedTime > 50)
{
int breakHere = 0; //<---- I'm hitting this breakpoint since elapsed time is usually above 150 milliseconds even when counter is 0.
}
I've been struggling with this for awhile. The best theory I have is maybe because there many window handles in this application. The application I have is basically runs multiple unit tests so it pops up about five windows on a thread. And to test this theory, I closed all but one of the windows. And it seems to never hit that break point when it's down to one window handle.
I tried moving one of the tests to its own thread, but by doing so, I'm running into a new issue where creating a new window handle on the separate thread causes an infinite recursion crash.
//Other stuff here. Let me know if you want me to post the full context of this function.
PrimaryWindow = Window::CreateObject();
PrimaryWindow->SetResource(new sf::RenderWindow(sf::VideoMode(800, 600), PROJECT_NAME)); //<---- crashes here
PrimaryWindow = Window::CreateObject();
PrimaryWindow->SetResource(new sf::RenderWindow(sf::VideoMode(800, 600), PROJECT_NAME)); //<---- crashes here
Callstack crash:
....
sfml-window-d-2.dll!`anonymous namespace'::getInternalContext() Line 159 C++
sfml-window-d-2.dll!sf::priv::GlContext::ensureContext() Line 217 C++
sfml-window-d-2.dll!sf::GlResource::GlResource() Line 61 C++
sfml-window-d-2.dll!sf::Context::Context() Line 61 C++
sfml-window-d-2.dll!`anonymous namespace'::getInternalContext() Line 159 C++
sfml-window-d-2.dll!sf::priv::GlContext::ensureContext() Line 217 C++
sfml-window-d-2.dll!sf::GlResource::GlResource() Line 61 C++
sfml-window-d-2.dll!sf::Context::Context() Line 61 C++
sfml-window-d-2.dll!`anonymous namespace'::getInternalContext() Line 159 C++
sfml-window-d-2.dll!sf::priv::GlContext::ensureContext() Line 217 C++
sfml-window-d-2.dll!sf::GlResource::GlResource() Line 61 C++
sfml-window-d-2.dll!sf::Context::Context() Line 61 C++
....
sfml-window-d-2.dll!`anonymous namespace'::getInternalContext() Line 159 C++
sfml-window-d-2.dll!sf::priv::GlContext::ensureContext() Line 217 C++
sfml-window-d-2.dll!sf::GlResource::GlResource() Line 61 C++
sfml-window-d-2.dll!sf::Context::Context() Line 61 C++
sfml-window-d-2.dll!`anonymous namespace'::getInternalContext() Line 159 C++
sfml-window-d-2.dll!sf::priv::GlContext::ensureContext() Line 217 C++
sfml-window-d-2.dll!sf::GlResource::GlResource() Line 61 C++
sfml-window-d-2.dll!sf::Context::Context() Line 61 C++
sfml-window-d-2.dll!`anonymous namespace'::getInternalContext() Line 159 C++
sfml-window-d-2.dll!sf::priv::GlContext::ensureContext() Line 217 C++
sfml-window-d-2.dll!sf::GlResource::GlResource() Line 61 C++
sfml-window-d-2.dll!sf::Context::Context() Line 61 C++
....
While reading through docs and forums, I learned about sf::Window::setActive. Although I call setActive(true) during the draw/render stage, it did not seem to make a difference. Then I started calling setActive(false) everywhere (after creating sf::RenderWindow, before render calls, before pollEvents, etc...). I know that's not the right way of doing things, but I was hoping it would at least 'lock' the windows instead of crashing whenever I create a window handle on a different thread.
I've did this for sf::RenderTextures, too. And I'm still crashing whenever I create a window handler on the other thread.
And here I am currently stuck. I'm running SFML version 2.4.0. I suppose I can upgrade it to a later version in case there was a bug fix for this.
Questions I have are:
1. Any idea why polling events sometimes take over 150 milliseconds even though there aren't any events?
2. When do I need to call setActive on a window handle? Can it only be activated before calling clear, draw, display functions? Or do I need to activate the window handles when polling events, too? I presume the same should be done for sf::RenderTextures, too.
3. Any idea what could be causing the infinite recursion crash? If the windows are self contained in their own threads, is it possible to handle windows and render textures in multiple threads if setActive is called appropriately?
6
SFML projects / Ruby Wrapper Using FFI
« Last post by MetalCoder on June 05, 2020, 09:47:06 pm »Hello all,
I have made a wrapper for SFML in the Ruby programming language. This updates it to 2.5. It is based off the C port of SFML. I used FFI to help make things easier. I have most of the modules wrapped. The only one I don't have wrapped is the Net module. I noticed the last SFML wrapper for Ruby hasn't been updated in a long time. I don't have this on Github or anything yet. Just wondering if anyone would be interested?
Here is a brief example of the wrapper using FFI.
I have made a wrapper for SFML in the Ruby programming language. This updates it to 2.5. It is based off the C port of SFML. I used FFI to help make things easier. I have most of the modules wrapped. The only one I don't have wrapped is the Net module. I noticed the last SFML wrapper for Ruby hasn't been updated in a long time. I don't have this on Github or anything yet. Just wondering if anyone would be interested?
Here is a brief example of the wrapper using FFI.
attach_function :sfRenderWindow_create,[:uint,:uint,:uint,:string,:uint32,:pointer],:pointer
require 'ffi'
#don't run infinite loop
x = Graphics.sfRenderWindow_create(800,600,32,"SFML",0,nil)
while Graphics.sfRenderWindow_isOpen(x)
Graphics.sfRenderWindow_display(x)
end
#don't run infinite loop
x = Graphics.sfRenderWindow_create(800,600,32,"SFML",0,nil)
while Graphics.sfRenderWindow_isOpen(x)
Graphics.sfRenderWindow_display(x)
end
7
SFML projects / Re: Nero Game Engine
« Last post by Sk Landry on June 05, 2020, 09:35:27 pm »Hi there, how do you do? 
First video tutorial released
I've just released a first video tutorial on the Nero Game Engine 2 Demo, watch it on you Youtube
https://www.youtube.com/channel/UCIR0nDUMGzJ3Pkpa3gDCUeQ
Nero Game Engine 1 SDK Update
I've just released a new version of the Nero Game Engine 1 SDK (r1.0.3). With this new update, you can now change the DevEngine Window size as you want.
The DevEngine has two constructors now
With the first one, you specify the width and the height you want, with the second one you only specify the width and the engine will compute the height.
Important
There are a min-width (1305.f) and a min-height(670.f). If you set a value below these ones, the engine will ignore your inputs.
Example
How to update
You can download the full SDK already updated (Nero Game Engine SDK 1.0.3) or you can download the update only (Engine Update 1.0.3) and copy its content in your current installation
download page here
What next
Build the website and make tutorials
As of now, I will focus on building the Engine Website and making some youtube tutorials. I'll try to make 2 or 3 tutorials per week.
Engine development
I will slow down with the Engine 2 development in order to focus on tutorials. But just for info, the next thing I'll be working on is the Engine Android Backend. Like Unreal on Unity, the Engine will able to deploy your game in android automatically.
First video tutorial released
I've just released a first video tutorial on the Nero Game Engine 2 Demo, watch it on you Youtube
https://www.youtube.com/channel/UCIR0nDUMGzJ3Pkpa3gDCUeQ
Nero Game Engine 1 SDK Update
I've just released a new version of the Nero Game Engine 1 SDK (r1.0.3). With this new update, you can now change the DevEngine Window size as you want.
The DevEngine has two constructors now
DevEngine(const unsigned int& windowWidth, const unsigned int& windowHeight);
DevEngine(const unsigned int& windowWidth);
DevEngine(const unsigned int& windowWidth);
With the first one, you specify the width and the height you want, with the second one you only specify the width and the engine will compute the height.
Important
There are a min-width (1305.f) and a min-height(670.f). If you set a value below these ones, the engine will ignore your inputs.
Example
nero::DevEngine engine(1900.f, 1000.f);
//or
nero::DevEngine engine(1900.f);
//or
nero::DevEngine engine(1900.f);
How to update
You can download the full SDK already updated (Nero Game Engine SDK 1.0.3) or you can download the update only (Engine Update 1.0.3) and copy its content in your current installation
download page here
What next
Build the website and make tutorials
As of now, I will focus on building the Engine Website and making some youtube tutorials. I'll try to make 2 or 3 tutorials per week.
Engine development
I will slow down with the Engine 2 development in order to focus on tutorials. But just for info, the next thing I'll be working on is the Engine Android Backend. Like Unreal on Unity, the Engine will able to deploy your game in android automatically.
8
Feature requests / Re: DRM/KMS support
« Last post by oomek on June 05, 2020, 04:19:23 pm »A little heads up.
The DRM backend is almost finished. But we stumbled across an issue that we can't find an elegant way aroud. There was a problem with rendering locking up after pressing the Enter key. We discovered that it was due to the keyboard input being passed to the terminal underneath. We solved that by grabbing an exclusive rights to all keyboard events in /dev/input by calling `ioctl(*itr, EVIOCGRAB, 1);` unfortunately this left us unavle to generate a TextEvent. Can you think of any way of converting a keycode to utf32 without relying on tables for each codepage like in SDL?
The DRM backend is almost finished. But we stumbled across an issue that we can't find an elegant way aroud. There was a problem with rendering locking up after pressing the Enter key. We discovered that it was due to the keyboard input being passed to the terminal underneath. We solved that by grabbing an exclusive rights to all keyboard events in /dev/input by calling `ioctl(*itr, EVIOCGRAB, 1);` unfortunately this left us unavle to generate a TextEvent. Can you think of any way of converting a keycode to utf32 without relying on tables for each codepage like in SDL?
9
General / Re: SFML 2.5 CMake Migration
« Last post by prakhar9998 on June 04, 2020, 05:02:30 pm »https://www.sfml-dev.org/faq.php#build-link This link mentions a dependency order, maybe that's what is been referred to here.
10
SFML projects / Re: A Tank Combat 'Simulator' - With a Focus on Destructible Terrain/Environments
« Last post by LarsXYZ on June 04, 2020, 01:04:39 pm »Thanks! It's plenty of fun. I've spent several hours testing it with friends. I might upload a video of some gameplay in a few days.