Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrapper method loadFontEx does not handle loading the default character set properly #14

Open
qrokodial opened this issue Dec 25, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@qrokodial
Copy link

The loadFontEx method does not properly handle when the codepoints argument is null.

As per the raylib documentation (emphasis added):

Font LoadFontEx(const char *fileName, int fontSize, int *codepoints, int codepointCount); // Load font from file with extended parameters, use NULL for codepoints and 0 for codepointCount to load the default character set, font size is provided in pixels height

In other words, codepoints should be null when we want to load the default character set, but under the hood, the loadFontEx wrapper function does not handle the case when codepoints is null.

The workaround is to not use the wrapper function and instead do something like the following (Kotlin code, but I'm sure you get the point):

Arena.ofConfined().use { localArena: Arena ->
    return RaylibFont(
        LoadFontEx(
            Arena.ofAuto(),
            localArena.allocateFrom(fileName),
            fontSize,
            MemorySegment.NULL, // this is usually where `MemorySegment.ofBuffer(codepoints)` would be
            0 // codepointCount
        )
    )
}

It seems like the loadFontEx wrapper method needs to be tweaked so it can handle the case where codepoints is null and substitute in MemorySegment.NULL.

@electronstudio
Copy link
Owner

Thanks for finding this. Looks like another shit thing about Raylib API, no way to specify in the signature that the pointer is nullable yet behaviour requires it to be.

Yes only solution I can think of is an if statement in the wrapper. Would need to check if there are any other such functions that require one too.

@electronstudio electronstudio added the bug Something isn't working label Dec 26, 2024
@electronstudio
Copy link
Owner

However the if statement will add overhead. The intention is that the majority of the wrapper should be able to be optimized away by a smart compiler, but I don't think think the if statement would be. (In theory function call could be inlined and an if statement that is always false could be removed, but I'd be surprised if java does this. We could investigate.)

A nicer solution would be to overload the function and have one that doesn't have the codepoints parameter at all, but that would probably have to be written manually, which is bit annoying for an auto-generated binding.

electronstudio added a commit that referenced this issue Dec 26, 2024
@electronstudio
Copy link
Owner

Have implemented the if statement fix because it was easiest.

@electronstudio
Copy link
Owner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants