Recent Posts

71

Graphics / Re: Graphical glitch appearing

« Last post by Missqu on March 31, 2025, 12:33:06 am »

Allright, I am sorry for late response.
I am not exactly sure what happened, but I copied my up to date code. Rollbacked project few weeks the issue disappeared... Applied updated code, still couldn't reproduce the bug.
So yeah, it seems like there was something gnarly going on with project tree most likely, I have no idea what, maybe some stray include(that is my educated guess).

72

General / Re: sf::Sprite undefined / no default value

« Last post by gwendyn on March 29, 2025, 10:59:41 pm »

hey thanks, passing works great. but i noticed you can also just load the texture in the initialization like that:

Game::Game():
mPlayerTexture("resources/eagle.png"),
mPlayer(mPlayerTexture) {}

I dont get how std::optional is supposed to work tho. if i use it in the header it dosnt really help because it wont allow me to use move() or draw() on that sprite because its not recognized as an sf::Sprite.

And now i built a simple texture manager with the guidance of a sfml book which loads the texture into a std::map with a pointer to retrieve it like that:

textures.Load(Textures::Airplane, "resources/eagle.png");
mPlayer(textures.Get(Textures::Airplane));

So i have now the same problem a third time D:
cant do that in the initialization and i cannot use it in the constructor.

edit: nvm got it.

73

General / Re: Missing SFML.framework for arm64 architecture on macOS

« Last post by wEconomiKus on March 28, 2025, 08:55:54 pm »

Thanks a lot for confirming!

Just to clarify a bit further (not easy, English is not my native language):

Even though I’m linking the individual frameworks (sfml-graphics.framework, sfml-window.framework, etc.), I still rely on the presence of SFML.framework, even if it’s only built for x86_64 (without it, it would not compile).

Surprisingly, building for arm64 actually works as long as I include the x86_64 SFML.framework alongside the others (in arm64). It’s a bit strange (I guess macOS or the linker just silently accepts it) but it feels more like a lucky accident than a robust solution.

Maybe SFML.framework only contains headers and metadata, which would explain why it technically works even if it was built for x86_64 only, the compiler probably just uses it as a header bundle (I do not know, just a guess).

That’s why having a proper SFML.framework for the arm64 architecture would make things much cleaner and more reliable, especially when maintaining cross-architecture builds.

Anyway, glad to hear it’s likely to be fixed in 3.0.1!

wEconomiKus

74

General / Re: Missing SFML.framework for arm64 architecture on macOS

« Last post by eXpl0it3r on March 28, 2025, 08:08:33 am »

Seems like an oversight during the packaging process.

Linking the specific frameworks directly isn't hacky or error-prone just a bit more characters to type

Will double check the packaging script and hopefully it should be available again with SFML 3.0.1.
Thank you for letting us know!

75

General discussions / Re: What is the main cause for SFML triggering anti-virus software?

« Last post by Me-Myself-And-I on March 27, 2025, 09:06:33 pm »

Good to know.

76

General / Missing SFML.framework for arm64 architecture on macOS

« Last post by wEconomiKus on March 27, 2025, 08:06:18 pm »

Hi,

First of all, thank you very much for this new version of SFML!

I just wanted to point out a possible omission: It seems that the SFML.framework is missing for the arm64 architecture on macOS, while it is present for x86_64.

Is this an oversight or an intentional choice?

I’m currently compiling my project with a cross-platform Makefile (macOS arm64, macOS x86_64, and Windows), and although I can work around the issue by linking the other frameworks directly (sfml-graphics.framework, etc.), it feels a bit hacky and potentially error-prone.

Thanks!

wEconomiKus

77

General discussions / Re: What is the main cause for SFML triggering anti-virus software?

« Last post by kojack on March 27, 2025, 06:48:38 am »

For a long time now the Win32 function GetAsyncKeyState has triggered various antivirus programs, as it could be used as a keylogger.
SFML uses GetAsyncKeyState in both isKeyPressed and isMouseButtonPressed.

78

General discussions / Re: What is the main cause for SFML triggering anti-virus software?

« Last post by Me-Myself-And-I on March 27, 2025, 03:48:02 am »

Okay

79

General discussions / Re: What is the main cause for SFML triggering anti-virus software?

« Last post by eXpl0it3r on March 26, 2025, 11:14:37 pm »

There isn't a singular cause. Anti-virus software uses lots and lots of different heuristics and code signatures. Whether your binary triggers such a heuristic is impossible to say or predict.
Signatures might match with some tool that used the same Windows API as SFML and that might already be enough.

Avoiding sf::Keyboard::isKeyPressed() and potentially sf::Mouse::getPosition() are a good idea, because they use "global" APIs and aren't restricted to a specific window, as such are often used for "spying" on the users. Which is why on macOS you need to explicitly granted monitoring access to the application to be able to utilize them and Wayland doesn't even directly offer certain functionality.

If you want your applications to not be flagged, you may submit it to virustotal and open false-positive reports with the AV companies that wrongly flag it.
If you're really serious about this, you can sign your application with a certificate, but this usually requires some sort of legal entity and money.

80

General discussions / What is the main cause for SFML triggering anti-virus software?

« Last post by Me-Myself-And-I on March 26, 2025, 09:43:51 pm »

Hello, I was wondering if the main causes for SFML triggering anti-virus software could be improved upon in this respect. I'm not sure on what are all the causes for anti-virus false positives. Someone had suggested that the cause could be sf::Keyboard because this is detected as keylogging. Alternatively sf::Event does not get seen as such. As far as the keylogger mistake, I made a very simple function that just stores the event input so that an external function can detect a keypress.

Like so:

namespace Key
{
        bool keyStates[sf::Keyboard::KeyCount];


        bool Get(sf::Keyboard::Key key)
        {
                return keyStates[key];
               
        }
       
       
        void update(sf::Event &e)
        {
                //handle key press
                if (e.type == sf::Event::KeyPressed) {
            int keyCode = e.key.code;
            if (keyCode >= 0 && keyCode < sf::Keyboard::KeyCount) {
               
                keyStates[keyCode] = true;
            }
        }

        // Handle key release
        if (e.type == sf::Event::KeyReleased) {
            int keyCode = e.key.code;
            if (keyCode >= 0 && keyCode < sf::Keyboard::KeyCount) {
               
                                keyStates[keyCode] = false;
            }
        }
        }
       
};
 

I'm not aware if the problems with anti-virus false positives was fixed in SFML 3 or not but this is what I have for SFML 2. What do you think? Is sf::Keyboard only one of several issues or not. Or is sf::Keyboard not even the culprit?