Drawing sf::Text results in a crash"writing_system_class" was nullptr

[obscurelyme]

Hello,

I'm looking for some advice on how to use sf::Text object. Specifically what is causing this crash to occur from Freetype library. Right now, any attempts to draw sf::Text results in a crash. I have included a link to my source code below as well as screenshots that showcase my setup after a build/crash. I am running 64-bit Windows with vcpkg as my main source of pulling in dependencies. I'm more than certain I am using debug libraries for a DEBUG build as vs code cmake tools sets by default.

My Source Code
https://github.com/obscurelyme/hello-sfml/blob/ed15963b38b896e414fab1b811ac5c8c7918e92d/main.cpp#L53-L73

Code Snippet:

// Load fonts
    std::string executableDirectory = std::filesystem::weakly_canonical(std::filesystem::path(argv[0])).parent_path().string();
    std::string relativeFontFile = "/assets/fonts/Roboto/Roboto-Regular.ttf";
    std::string fontFilePath = executableDirectory.append(relativeFontFile);
    sf::Font font;
    if (!font.loadFromFile(fontFilePath))
    {
        spdlog::debug("Could not load Roboto-Regular.ttf from directory {}", fontFilePath);
    }
    else
    {
        spdlog::debug("Successfully loaded {} font-family.", font.getInfo().family);
    }

    sf::Text text{"Hello", font, 48};
    text.setFillColor(sf::Color::Red);
    text.setStyle(sf::Text::Regular);
    text.setPosition(200, 200);
    ...
    while(running) {
       sf::Event event;
       while(window.pollEvent(event)) {
           // handle event[s] ...
       }

       window.clear(sf::Color::Blue);

        window.draw(text); // program crashes when this is called.

        window.display();
    }
 

Here is the screenshot of the crash in debugger

[obscurelyme]

Update:

I pulled down my source and compiled on OSX Big Sur v11.5.2 and it seems to work as intended. So right now I'm unsure if this is a platform issue or perhaps Mac is compiling with static libs vs on Windows I'm getting dynamic libs.

Here is the screenshot on OSX attached.

Would still like to get to the bottom on why this code doesn't work on x64 Windows 10.

[eXpl0it3r]

As vcpkg pulls in the freetype version provided by vcpkg, it might be that there's some incompatibility or otherwise different build. You could try to use the freetype library provided by SFML in the extlibs directory.

[obscurelyme]

Thanks for the advice. I'll give it a go configuring CMake to pull in freetype from SFML. More to come.

[obscurelyme]

Yikes, so vcpkg does have some in-development version control over what dependencies are to be installed. The lowest version of freetype that anyone can specify using vcpkg is 2.9.x and SFML uses 2.5.5 So Looks like vcpkg could be a non-starter for SFML type projects.

[texus]

Have you tested a FreeType version on Windows other than 2.11?

There is a freetype bug that causes a crash in af_face_globals_get_metrics (where your callstack also points to) that only occurs on Windows (with libraries build with Visual Studio) and only with FreeType 2.11. https://gitlab.freedesktop.org/freetype/freetype/-/issues/1092

Downgrading to any version lower than that fixes that issue. FreeType versions are backwards compatible, I would expect SFML to work fine with FreeType 2.9 or 2.10

[obscurelyme]

I just updated my vcpkg.json to use Freetype 2.10 and it works! Many thanks.

[theo]

May I ask how you did this? For me it won't work.
I edited the vcpkg.json in the ports\sfml dir to

(click to show/hide)

{
  "name": "sfml",
  "version": "2.5.1",
  "port-version": 10,
  "description": "Simple and fast multimedia library",
  "homepage": "https://github.com/sfml/sfml",
  "dependencies": [
    "freetype",
    "libflac",
    "libogg",
    "libvorbis",
    "openal-soft",
    "stb"
  ],
  "builtin-baseline":"92af1ff59a651c1cf43aca48f54369a86d40d81c",
  "overrides":[{"name":"sfml", "version":"2.10.0"}]
}

I got the value of builtin-baseline by doing
git rev-parse HEAD

This didn't do anything for me: it still grabbed freetype version 2.11.0.

Then I edited vcpkg\versions\baseline.json and changed the baseline of freetype to 2.10.0 and I edited the vcpkg.json of freetype to also take 2.10.0:
"version-semver": "2.10.0",

Now it SAYS that it takes 2.10.0. And vcpkg list says 2.10.0 for freetype. But the dll version is STILL 2.11.0 and drawing an sf::Text STILL crashes in freetype.

Maybe the easier way is to compile sfml with cmake and copy the freetype dll into the vcpkg\bin dir

[theo]

stupid mistake: in vcpkg.json:

"overrides":[{"name":"sfml", "version":"2.10.0"}] -> "overrides":[{"name":"freetype", "version":"2.10.0"}]

But it doesn't make a difference, it still builds freetype 2.11.0

[theo]

Got it working, though my method is a bit hacky.

• Downloaded the sources of freetype 2.10.4
• opened the provided visual studio solution (builds\windows\vc2010 (yes this one works on vs2019 too)
• built it for the desired configuration
• now VS builds a dll named freetype.dll. I renamed it to freetyped.dll (debug version). Hovering in windows confirms that it is version 2.10.4.
• copied it to vcpkg\installed\x64-windows\bin (overwrite existing file)
  
• now it works. It seems that 2.10.4 and 2.11.0 are binary compatible.

Stackoverflow says that you have to edit header files. This is not necessary anymore. Just choose dll in the solution properties.

Hopefully they fix that bug soon. I do wonder however how they could miss this with any kind of testing on windows (not an entirely insignificant platform).

[obscurelyme]

I have a branch that leverages freetype 2.10. You can take a look here. There isn't any modification needed just leverage the extensions to handle the heavy lifting.

It's important to remember that you need to have VCPKG_FEATURE_FLAGS set to "versions" as an environment variable in order for vcpkg versions to work.

https://github.com/obscurelyme/Semi-Pro-Cpp/tree/feature/sfml-freetype

Let me know if you have any questions.