[META::Emscripten] Live version integration strategy and progress report

[PavelSharp]

The first step in integrating Emscripten is to choose the backend. See the report below.

Emscripten Integration Report

Good News

1. ⭐⭐ Successfully built and tested demo/sdl3_renderer.
   Everything works, including builds with INCLUDE_ALL. However, this requires either merging the small PR fix(style_configurator): fix unsafe int to nk_bool pointer casts #883 or manually fixing it by adjusting field types.
2. ⭐ Successfully built and tested demo/sdl_opengles2.
   Everything works as expected. Untested with INCLUDE_ALL.
3. ❌Successfully built demo/sdl_renderer.
   Launch is currently unsuccessful, since opening index.html results in an infinite loading loop. But I didn't take many attempts.

Bad News

1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.
   1.1 The issue is described here issues/319.
   1.2 There is an interesting PR Reduce differences between the OpenGL 3 and OpenGL ES 2 demos #873 that introduces a have_mapbuffer flag, but it is always true. As a temporary workaround, its value could be set based on the __EMSCRIPTEN__ macro.
   1.3 This PR will only fix demos including demo/glfw_opengl3, but the our examples (based on GLFW/OpenGL3 too) remain unchanged.
2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in Support the file browser with more demos #590.

Notes

1. Some work on Emscripten support has already been done by @DeXP:
   1.1. In the old repository, this PR added sdl_opengles2 and a web rule to Makefile.
   1.2. About 10 years ago, a live version was created, but it is no longer maintained.
2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

[sleeptightAnsiC]

(I'm well aware the text above is LLM-generated/edited)

Bad News: 1. Standard examples (Nuklear/example/) based on GLEW/GLFW do not build due to glMapBuffer and glUnmapBuffer calls.

Yes, this is a huge problem that we will need to solve somehow. For now, I think it would be fine to simply exclude some of those examples, and rewrite them later.

Bad News: 2. If we choose sdl3_renderer as the Emscripten backend, we cannot include demo/common/file_browser.c, since the icon_load uses direct OpenGL calls. This is already fixed in #590.

IIRC, there are more problems in demo/sdl3_renderer that may prevent you from loading images. I believe, I just forgot to implement this functionality back in #852 and only recently noticed (shame on me...) EDIT: I think, that demo doesn't need custom image handling, because it has no shaders involved and simply passthroughs the texture handle, but I'm not sure, if it works correctly. I never tested it.

We can do a little bit of hacky-wacky approach, and still use unchanged demo/sdl3_renderer code by creating SDL_Renderer backed by GLES2 context (aka SDL_CreateRendererWithProperties with *_CREATE_NAME_STRING set to opengles2). If you're interested, let me know, and I'll give you some snippet.

Notes: 2. I believe, for sdl3_renderer, it may also make sense to add a web rule in the Makefile to improve consistency.

According to emscripten-core/emscripten#23831 the most up to date version of Emscripten should already ship with it's own SDL3 port, so in theory you should be able to do emmake make and the spoofed pkg-config should be able to pick that version. If that's not happening, then maybe there is something wrong with that makefile (?) EDIT: added PR for this one: #894

---

I'm planning to do some work on this demo, so I will most likely fix those issues too. If you (or anyone reading this) have any wishlist about some other features/fixes, let me know ;) Currently, there are several PRs open touching this code (#884, #878, #879, #841, #894, more?) so I need to do something about them first.

also adding few refs:

• [META] Proposal for Changes #887
• A demo #871
• https://discord.com/channels/922234432071548968/922234432071548973/1467183758376702015