Messages

1

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 😁

2

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:

std::string str = u8"привет";
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()));
 

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()));
 

3

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 😅

4

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.

5

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:

#version 120
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

6

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

7

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.

8

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.

9

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.

10

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)

11

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

12

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

13

Graphics / Re: Perspective distortion issue

« on: February 15, 2024, 07:36:49 pm »

What you're getting is Affine Texture Mapping - caused by the vertex stage interpolating the UV coordinates in 2D space. (It's actually what the PS One did).

For Perspective Texture Mapping you'll need to supply some sort of depth value. This article explains more: https://mtrebi.github.io/2017/03/15/texture-mapping-affine-perspective.html as does wikipedia: https://en.wikipedia.org/wiki/Texture_mapping#Affine_texture_mapping

14

Graphics / Re: LineStrip VertexArray and ConvexShape problem

« on: February 02, 2024, 10:54:32 am »

SelbaWard looks like it supports this: https://github.com/Hapaxia/SelbaWard/wiki/Polygon

15

Graphics / Re: Drawing Vertex Array with big Texture

« on: January 29, 2024, 10:54:59 am »

I'm not against the idea, I just have no clue how I'd approach it.
I'm aware that may be due to my lack of understanding of OpenGL, so if that's the case please let me know. Thank you

I apologise if this is jumping in at the deep end a little - I just wanted to highlight what's possible if you're able to mix some OpenGL with SFML.

However, if there are any SFML devs reading this, I think sf::ArrayTexture might not be a bad idea? It would also be useful for animating sprites, for example. Array textures are available though this extension.