I’ve been trying to port the sdl_renderer demo in the Nuklear repo, but I get the following:
This is what it should look like (this is the C demo):
“I’ve seen that before when font loading messed up”
From the very slooooow discord.
If anyone can help work out why the built-in font isn’t working right, I’d be happy
To build with alr, just change the pins to the url versions to get the latest from sdlada git.
Seems the font.texture element is missing from my record, even though it’s there.
type nk_font;
type nk_font is record
next : access nk_font; -- ./Nuklear/nuklear.h:4091
handle : aliased nk_user_font; -- ./Nuklear/nuklear.h:4092
info : aliased nk_baked_font; -- ./Nuklear/nuklear.h:4093
scale : aliased float; -- ./Nuklear/nuklear.h:4094
glyphs : access nk_font_glyph; -- ./Nuklear/nuklear.h:4095
fallback : access constant nk_font_glyph; -- ./Nuklear/nuklear.h:4096
fallback_codepoint : aliased nk_rune; -- ./Nuklear/nuklear.h:4097
texture : aliased nk_handle; -- ./Nuklear/nuklear.h:4098
config : access nk_font_config; -- ./Nuklear/nuklear.h:4099
end record
with Convention => C_Pass_By_Copy; -- ./Nuklear/nuklear.h:4090
It seems the compiler has optimised out the nk_handle object and inlined it’s contents, ptr/id fields. Anyone seen this before?
mgrojo
July 7, 2024, 11:32am
4
I wouldn’t trust the debugger, since it is giving inconsistent information. Is the code optimized? Couldn’t you turn off optimization to see if it changes anything?
Fixed it, Defining NK_UINT_DRAW_INDEX as per the docs, does not work.
Not nice to use, but it works.
This is the first time I’ve seen C_Pass_By_Copy. Is that nonstandard, or new? I’m curious as to why it exists.
Seems to be the standard way C passes structs to functions.
jere
July 7, 2024, 10:38pm
10
It was a GNAT extension up to Ada95. The language spec added it officially for Ada2005
1 Like