You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add optional 32-bit ImDrawIdx support (large meshes) in Pascal binding #6
Hi, I forgot to ask in my previous PR if you could provide a version with 32-bit indices support for drawing large meshes, aligned with ImGui’s documented compile-time switch:
// ImDrawIdx: vertex index. [Compile-time configurable type]
// - To use 16-bit indices + allow large meshes: backend sets 'io.BackendFlags |= ImGuiBackendFlags_RendererHasVtxOffset'
// and handles ImDrawCmd::VtxOffset (recommended).
// - To use 32-bit indices: override with '#define ImDrawIdx unsigned int' in your imconfig.h file.
#ifndef ImDrawIdx
typedef unsigned short ImDrawIdx; // Default: 16-bit
#endif
Default (current): ImDrawIdx = Word (16-bit)
In the version I am asking for, I am expecting: ImDrawIdx = Cardinal (32-bit)
with default 16-bit we are limited to 65,536 vertices buffer - I tried with the following without good result io.BackendFlags := io.BackendFlags or ImGuiBackendFlags_RendererHasVtxOffset;
with default 16-bit we are limited to 65,536 vertices buffer - I tried with the following without good result
io.BackendFlags := io.BackendFlags or ImGuiBackendFlags_RendererHasVtxOffset;
This won't work on current version because the default is compiled with ImDrawIdx set to 16-bits
I'll compile a new version with the default ImDrawIdx to be 32-bits ( It makes more sense to make it 32-bits )
I updated the code internally to support the latest version, And I used the implementation code from the IMGUI source code and embed it in the code for rendering so I don't have to maintain the pascal implementation It needs a lot of rework and someone with free time to keep up with the changes they do in IMGUI, And now ImDrawIdx is 32bit by default.
I added GLFW3 & SDL3 backends Static & Dynamic libs with ImGui 1.92.6-docking and everything works great with FreePascal x86-64 on windows and Linux
But for the static libraries there's a bug in the compiler I already fixed on my side But still waiting the FPC team to confirm it
I'll upload the new updates tomorrow after finishing some refactoring.
SDL3 with OpenGL
GLFW3 with OpenGL
I'll also publish a small video & the cmake script to explaining how I compile the libraries and maybe try to create a GitHub action to automate all of this
Hey Coldzer0 - glad to hear that! I'll give it a try.
Last week I ran into an issue (on the old version) that made me took another way on a project - a GPU-emulated terminal. I need emojis to render properly, and I think there's a limitation in the compiled lib: a constant probably needs to be increased from 16 bytes to 32. I'll have to check the code because I don't remember which constant it is right now.
On your side and on this version, do emojis render correctly?
ImWchar = ImWchar16 = Word (16-bit) emoji codepoints (U+1F600+) are above 16-bit range, so they can't be added to the ImGui font atlas --> all emoji render as ??.
The fix requires rebuilding cimgui.dll with IMGUI_USE_WCHAR32 defined, which changes ImWchar from 16-bit to 32-bit. Without that, the font atlas simply cannot index any glyph above U+FFFF.
BMP symbols (box-drawing, etc) work fine - only actual emoji (surrogate pairs) are blocked.
Meanwhile, I could build a version using SDL2 with emoji support. I think my previous attempt failed because, on Windows 11, the Segoe UI Emoji font now uses COLRv1, whereas earlier versions used COLRv0.
Also, about my comment on the old PRs where I said I couldn't compile your last published version was mainly due to some #IfDef BLABLA vs #If Defined(BLABLA) conditions, anonymous functions and reference to procedure not supported syntax.
I compile on fpc-3.2.3 and I'm not a fpc options ninja.
ps: do not hesitate to publish sdl3 version on a new branch :D
Activity
Coldzer0 commentedon Aug 23, 2025
This won't work on current version because the default is compiled with ImDrawIdx set to 16-bits
I'll compile a new version with the default ImDrawIdx to be 32-bits ( It makes more sense to make it 32-bits )
Coldzer0 commentedon Mar 15, 2026
Hello @flydev-fr
I updated the code internally to support the latest version, And I used the implementation code from the IMGUI source code and embed it in the code for rendering so I don't have to maintain the pascal implementation
It needs a lot of rework and someone with free time to keep up with the changes they do in IMGUI, And now ImDrawIdx is 32bit by default.I added GLFW3 & SDL3 backends
Static & Dynamic libswithImGui 1.92.6-dockingand everything works great with FreePascal x86-64 on windows and LinuxBut for the static libraries there's a bug in the compiler
I already fixed on my sideBut still waiting the FPC team to confirm ithttps://gitlab.com/freepascal.org/fpc/source/-/work_items/41662
I'll upload the new updates tomorrow after finishing some refactoring.
SDL3 with OpenGL
GLFW3 with OpenGL
I'll also publish a small video & the cmake script to explaining how I compile the libraries and maybe try to create a GitHub action to automate all of this
flydev-fr commentedon Mar 15, 2026
Hey Coldzer0 - glad to hear that! I'll give it a try.
Last week I ran into an issue (on the old version) that made me took another way on a project - a GPU-emulated terminal. I need emojis to render properly, and I think there's a limitation in the compiled lib: a constant probably needs to be increased from 16 bytes to 32. I'll have to check the code because I don't remember which constant it is right now.
On your side and on this version, do emojis render correctly?
flydev-fr commentedon Mar 15, 2026
I just found it:
ImWchar = ImWchar16 = Word (16-bit)emoji codepoints (U+1F600+) are above 16-bit range, so they can't be added to the ImGui font atlas --> all emoji render as ??.The fix requires rebuilding cimgui.dll with IMGUI_USE_WCHAR32 defined, which changes ImWchar from 16-bit to 32-bit. Without that, the font atlas simply cannot index any glyph above U+FFFF.
BMP symbols (box-drawing, etc) work fine - only actual emoji (surrogate pairs) are blocked.
https://github.com/ocornut/imgui/blob/master/docs/FONTS.md#using-colorful-glyphsemojis
Coldzer0 commentedon Mar 16, 2026
Yes I do build the new one with
Here's a screen shot from the emoji font fully loaded
flydev-fr commentedon Mar 16, 2026
flydev-fr commentedon May 25, 2026
Hi @Coldzer0 ,
Meanwhile, I could build a version using SDL2 with emoji support. I think my previous attempt failed because, on Windows 11, the Segoe UI Emoji font now uses COLRv1, whereas earlier versions used COLRv0.
Also, about my comment on the old PRs where I said I couldn't compile your last published version was mainly due to some
#IfDef BLABLAvs#If Defined(BLABLA)conditions, anonymous functions andreference to procedurenot supported syntax.I compile on fpc-3.2.3 and I'm not a fpc options ninja.
ps: do not hesitate to publish sdl3 version on a new branch :D