1
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.
2
Graphics / Re: rotate tanslate vs translate rotate
« on: November 14, 2024, 01:47:20 pm »
SFML Drawables which inherit sf::Transformable call sf::Transformable::getTransform() which always combines the components as Translation->Rotation->Scale. If you want to combine these in a different order you'll need to replace getTransform() with your own function which combines sf::Transform in your custom order. You can then pass the result to the sf::RenderStates for your drawable.
3
General / Re: Memory usage increasing when drawing a sprite?
« on: October 17, 2024, 04:06:41 pm »
Not sure if this counts as a bug with Visual Studio but I have noticed that the profiler, when running the debugger, seems to include Visual Studio's memory usage on top of whatever is being debugged. If you launch the Task Manager while you're debugging the game compare the memory usage reported there and you'll probably find that the game itself is using a very small amount of RAM and Visual Studio is using most of it. Add the values together and you'll get something close to what's being reported in the profiler.
HTH
HTH
4
General / Re: Using std::futures for creating chunks
« on: July 23, 2024, 08:43:51 am »
Without running your code I can't say for sure, but I'm guessing the bottleneck is the single shared mutex. What is probably happening is that all the worker threads finish at more or less the same time, but then have to queue as each one waits for the mutex to lock and unlock for each thread.
A possible solution would be to have each worker thread have its own mutex then the main thread can check and gather results from finished threads by locking each of those individually - that way none of the other threads are interacting with each other, just the main one.
std::future is possibly also not the magic bullet you're looking for here, and you may have to get your hands dirty with threads directly - although there is the std::execution policy in C++17 (except on Apple clang, where it's not mplemented) https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t which allows running stl algorithms in parallel.
Overall this is more generally called (or is a variant of) the producer-consumer problem: https://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem - which is worth reading up on and might help you find a more suitable solution. HTH ๐
A possible solution would be to have each worker thread have its own mutex then the main thread can check and gather results from finished threads by locking each of those individually - that way none of the other threads are interacting with each other, just the main one.
std::future is possibly also not the magic bullet you're looking for here, and you may have to get your hands dirty with threads directly - although there is the std::execution policy in C++17 (except on Apple clang, where it's not mplemented) https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t which allows running stl algorithms in parallel.
Overall this is more generally called (or is a variant of) the producer-consumer problem: https://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem - which is worth reading up on and might help you find a more suitable solution. HTH ๐
5
Graphics / Re: Issues drawing characters outside ASCII char set
« on: July 20, 2024, 09:47:37 am »
SFML actually has this built in. https://www.sfml-dev.org/documentation/2.6.1/classsf_1_1String.php#aa7beb7ae5b26e63dcbbfa390e27a9e4b
With C++17:
or if you want to use wstring (assuming wchar_t is 16 bit on your platform, it might not be)
If you want to read utf8 from a file you can copy it byte by byte into a vector and do the same thing:
With C++17:
std::string str = u8"ะฟัะธะฒะตั";
text.setString(sf::String::fromUtf8(str.begin(), str.end()));
text.setString(sf::String::fromUtf8(str.begin(), str.end()));
or if you want to use wstring (assuming wchar_t is 16 bit on your platform, it might not be)
std::wstring str = L"ะฟัะธะฒะตั";
text.setString(sf::String::fromUtf16(str.begin(), str.end()));
text.setString(sf::String::fromUtf16(str.begin(), str.end()));
If you want to read utf8 from a file you can copy it byte by byte into a vector and do the same thing:
std::vector<std::uint8_t> fileBytes;
//read file into fileBytes here
text.setString(sf::String::fromUtf8(fileBytes.begin(), fileBytes.end()));
//read file into fileBytes here
text.setString(sf::String::fromUtf8(fileBytes.begin(), fileBytes.end()));
6
General / Re: Trying to render a texture with opengl in a SFML application
« on: July 01, 2024, 11:03:08 am »
I had to double check - according to this GLES2 is a mix of both ๐
https://www.khronos.org/opengles/sdk/docs/reference_cards/OpenGL-ES-2_0-Reference-card.pdf
It uses varyings rather than in/out and has the gl_FragColor constant (old style), however there's no gl_TexCoord array, texture coords need to be passed via a varying instead (new style)... It also uses the old style texture2D() sampler functions.
So, uh.. probably best to forget I mentioned GLES ๐
https://www.khronos.org/opengles/sdk/docs/reference_cards/OpenGL-ES-2_0-Reference-card.pdf
It uses varyings rather than in/out and has the gl_FragColor constant (old style), however there's no gl_TexCoord array, texture coords need to be passed via a varying instead (new style)... It also uses the old style texture2D() sampler functions.
So, uh.. probably best to forget I mentioned GLES ๐
7
General / Re: Trying to render a texture with opengl in a SFML application
« on: June 30, 2024, 05:50:33 pm »
I think the most important thing when starting out is to know that there *are* different versions of OpenGL/GLSL... and that they're kind of a mess ๐
Mixing OpenGL versions is not particularly recommended - it *might* work on Windows, *kinda* works on Linux and definitely doesn't work on macOS.
Once you get your head around that just make sure to stick with one particular version and use an appropriate library. There's the "old" style, which SFML uses (as does WebGL and GLES2 if memory serves, but don't quote me on that) or the "new" style, as taught by most OpenGL learning resources.
"Old" style OpenGL versions are up to 2.1, which uses GLSL up to 1.2
OpenGL3, 3.1 and 3.2 use GLSL 1.3, 1.4 and 1.5 - though you rarely see these anywhere
"New" style OpenGL is 3.3+ and the GLSL version numbers match (3.3, 4.0, 4.1 etc)
When you have the basics down in either version from there it's actually pretty easy to see the differences and swap between the various versions as you need to.
Mixing OpenGL versions is not particularly recommended - it *might* work on Windows, *kinda* works on Linux and definitely doesn't work on macOS.
Once you get your head around that just make sure to stick with one particular version and use an appropriate library. There's the "old" style, which SFML uses (as does WebGL and GLES2 if memory serves, but don't quote me on that) or the "new" style, as taught by most OpenGL learning resources.
"Old" style OpenGL versions are up to 2.1, which uses GLSL up to 1.2
OpenGL3, 3.1 and 3.2 use GLSL 1.3, 1.4 and 1.5 - though you rarely see these anywhere
"New" style OpenGL is 3.3+ and the GLSL version numbers match (3.3, 4.0, 4.1 etc)
When you have the basics down in either version from there it's actually pretty easy to see the differences and swap between the various versions as you need to.
8
General / Re: Trying to render a texture with opengl in a SFML application
« on: June 30, 2024, 02:51:53 pm »
Unless things have changed on the development branch, SFML 2 uses GLSL 1.2
Try:
https://www.sfml-dev.org/tutorials/2.6/graphics-shader.php#minimal-shaders
Try:
#version 120
uniform sampler2D u_texture;
void main()
{
gl_FragColor = texture2D(u_texture, gl_TexCoord[0].xy);
}
uniform sampler2D u_texture;
void main()
{
gl_FragColor = texture2D(u_texture, gl_TexCoord[0].xy);
}
https://www.sfml-dev.org/tutorials/2.6/graphics-shader.php#minimal-shaders
9
Audio / Re: sf::sound causes severe performance lag.
« on: May 30, 2024, 05:11:08 pm »
Make sure you're only loading the buffer from file *once* then keeping it around, and not trying to load it every frame
10
General / Re: Can you integrate allegro into an sfml window?
« on: May 26, 2024, 11:43:02 am »
Based on your earlier post I assume you're using Dev C++ in which case check their FAQ: https://bloodshed.net/FAQ#9
Else if you're using CMake use the FindOpenGL command https://cmake.org/cmake/help/latest/module/FindOpenGL.html
Or in Visual Studio add "opengl32.lib" to the library list in the project properties and it'll find the file automatically.
Else if you're using CMake use the FindOpenGL command https://cmake.org/cmake/help/latest/module/FindOpenGL.html
Or in Visual Studio add "opengl32.lib" to the library list in the project properties and it'll find the file automatically.
11
General / Re: Can you integrate allegro into an sfml window?
« on: May 23, 2024, 10:56:07 am »
Just tried it with gcc and there were a few typos which needed fixing ๐
I've updated the repo with a version that I've tested on my linux box and added a CMake project for the demo if you'd like to try it.
I've updated the repo with a version that I've tested on my linux box and added a CMake project for the demo if you'd like to try it.
12
General / Re: Can you integrate allegro into an sfml window?
« on: May 22, 2024, 05:22:14 pm »
It depends on you compiler/toolchain setup.
For example Visual Studio lists 2 folders in its source tree "Header Files" and "Source Files". Only the files which are included in the "Source Files" folder are sent for compilation. It's at this point any header files which are #include 'd in the *.cpp files are pulled in by the compiler for compilation. (Well, kinda, they're put in place by the preprocessor just before compilation).
On the other hand *.hpp files listed in the "Header Files" section are ignored, except for when they're explicitly #include 'd in a *.cpp file. If you try adding an *.hpp file to the "Source Files" folder, Visual Studio will try to compile it directly which may or may not be what you want (probably not in most cases, and definitely not in this specific case).
Other toolchain/compiler setups are similar: you list the source files (*.c and *.cpp) you want to compile, followed by the directories containing the header files. That way the compiler will only pull in any header files for compilation as is needed.
So what I mean is - make sure the *.hpp files are not being added to the list of files to be compiled, either by accidentally adding them to the "Source Files" folder in Vidual Studio, or by any other means with a different compiler.
For example Visual Studio lists 2 folders in its source tree "Header Files" and "Source Files". Only the files which are included in the "Source Files" folder are sent for compilation. It's at this point any header files which are #include 'd in the *.cpp files are pulled in by the compiler for compilation. (Well, kinda, they're put in place by the preprocessor just before compilation).
On the other hand *.hpp files listed in the "Header Files" section are ignored, except for when they're explicitly #include 'd in a *.cpp file. If you try adding an *.hpp file to the "Source Files" folder, Visual Studio will try to compile it directly which may or may not be what you want (probably not in most cases, and definitely not in this specific case).
Other toolchain/compiler setups are similar: you list the source files (*.c and *.cpp) you want to compile, followed by the directories containing the header files. That way the compiler will only pull in any header files for compilation as is needed.
So what I mean is - make sure the *.hpp files are not being added to the list of files to be compiled, either by accidentally adding them to the "Source Files" folder in Vidual Studio, or by any other means with a different compiler.
13
General / Re: Can you integrate allegro into an sfml window?
« on: May 19, 2024, 11:57:24 am »
When you add the files to your project, make sure you're only compiling VideoTexture.cpp (not the header files)
14
General / Re: Can you integrate allegro into an sfml window?
« on: May 18, 2024, 12:05:47 pm »
This should get you off on the right foot:
https://github.com/fallahn/VideoTexture
Just add the files in the 'src' directory to your project, and check the example for usage
https://github.com/fallahn/VideoTexture
Just add the files in the 'src' directory to your project, and check the example for usage
15
General / Re: Can you integrate allegro into an sfml window?
« on: May 15, 2024, 10:46:39 am »
What sort of video do you need to support? If it's just for some intro videos/cutscenes pl_mpeg is pretty easy to integrate with a RenderTexture/AudioStream
https://github.com/phoboslab/pl_mpeg
or there's more comprehensive support with libvlc:
https://github.com/kjetand/vlc4sfml
https://github.com/phoboslab/pl_mpeg
or there's more comprehensive support with libvlc:
https://github.com/kjetand/vlc4sfml