SDL3 on Emscripten 3.1.56

[LloydJHowarth]

⁸I have a .NET 9 wasm-tools project running SDL2 working flawlessly with no problems at all however I'm trying to shift towards SDL3. As of right now .NET 9 wasm-tools projects are locked at Emscripten 3.1.56 but I've noticed an SDL3 port in version 4.0.15 therefore I backported it to run with 3.1.56.

However I couldn't include this code from the sdl3.py file

def process_dependencies(settings, cflags_only):
if not cflags_only:
# SDL3 includes an internal reference to Module['createContext']
settings.EXPORTED_RUNTIME_METHODS.append('createContext')

Emscripten 3.1.56 doesn't seem to have anything to handle this so I'm unsure what to do so for now I just removed the code and built. I even tried adding it the same way sdl2.py handles its export methods etc with no luck. Anyway.. this outputs a libSDL3.a file that I then used in my project. Everything works as expected such as SDL Initialized, SDL Events and anything else SDL related can be called with no issues, except creating a window.

When I run this code

Console.WriteLine("Attempting to initialize");
if(SDL_Init(SDL_InitFlags.SDL_INIT_VIDEO | SDL_InitFlags.SDL_INIT_AUDIO)) Console.WriteLine("SDL Initialized");

Console.WriteLine("Attempting to create window");
window = SDL_CreateWindow("Hi", 400, 400, 0);
if(window == IntPtr.Zero) Console.WriteLine("Failed to create window");

Console.WriteLine("Attempting to create renderer");
renderer = SDL_CreateRenderer(window, null);
if(renderer == IntPtr.Zero) Console.WriteLine("Failed to create renderer");

This is the output:

Attempting to initialize
dotnet.native.hzzryi8u7q.js:1819 SDL Initialized
dotnet.native.hzzryi8u7q.js:1819 Attempting to create window
dotnet.native.wasm-04a64d1e:0x115bcd Uncaught RuntimeError: null function or function signature mismatch
at dotnet.native.wasm.do_icall (dotnet.native.wasm-04a64d1e:0x115bcd)
at dotnet.native.wasm.do_icall_wrapper (dotnet.native.wasm-04a64d1e:0x111f43)
at dotnet.native.wasm.mono_interp_exec_method (dotnet.native.wasm-04a64d1e:0x103197)
at dotnet.native.wasm.interp_runtime_invoke (dotnet.native.wasm-04a64d1e:0x11344e)
at dotnet.native.wasm.mono_jit_runtime_invoke (dotnet.native.wasm-04a64d1e:0x232430)
at dotnet.native.wasm.do_runtime_invoke (dotnet.native.wasm-04a64d1e:0x1f23c0)
at dotnet.native.wasm.mono_runtime_try_invoke (dotnet.native.wasm-04a64d1e:0x1f2e40)
at dotnet.native.wasm.mono_runtime_invoke (dotnet.native.wasm-04a64d1e:0x1f5a64)
at dotnet.native.wasm.mono_wasm_invoke_jsexport (dotnet.native.wasm-04a64d1e:0x3b06de)
at dotnet.native.hzzryi8u7q.js:811:12

As you can see SDL3 is being called as expected but windows aren't working. I've even checked the exported functions and SDL_CreateWindow is definitely there. I've tried SDL_CreateWindowAndRenderer as well but no luck. Obviously createContext is required but I just can't seem to handle it with 3.1.56

I dont really have in depth knowledge of Emscripten, wasm, etc. I'm just porting my existing working SDL2 project to SDL3 and this is where I'm at right now. Everything works but window creation. Unfortunately I think .NET users will be stuck on Emscripten 3.1.56 for a few years to come. Maybe till even .NET 12 so we are pretty much locked at SDL2...

Is there anything that can be done to solve this issue and create a window / context?

[sbc100]

The createContext thing is red herring. That was fixed upstream and we should remove it from sdl3.py: #25405.

I guess you need to track down where the null function ptr (or bad signature) is coming from. Can you see what is being called when it crashes? I.e. what js exports is being run from mono_wasm_invoke_jsexport? What is on line 811 of otnet.native.hzzryi8u7q.js? Can you get the crash in devtools and poke around to see what values are flowing? i.e. is it actually a null pointer, or just a bad signature? If that function is not null what is it? What function exists at that Wasm table address?

Seems like this maybe an issue that the dotnet folks might be better suited to help debug.

[LloydJHowarth]

I did read that previously that's why I thought it may be acceptable to just remove createContext however when the window didn't work I assumed maybe Emscripten still needed it for something internal. At least that clears up that!

Currently going down the rabbit hole now to try find the root cause.

[LloydJHowarth]

Looking at dotnet.native.4f59ihtvzf.js:811:12 I found this:

> function createExportWrapper(name) {
>   return (...args) => {
>     assert(runtimeInitialized, `native function \`${name}\` called before runtime initialization`);
>     assert(!runtimeExited, `native function \`${name}\` called after runtime exit (use NO_EXIT_RUNTIME to keep it alive after main() exits)`);
>     var f = wasmExports[name];
>     assert(f, `exported native function \`${name}\` not found`);
>     return f(...args); <--- This is line (811)
>   };

Which doesn't assert when checking the wasmExports for SDL_CreateWindow.

Looking at dotnet.native.js.symbols I found this:

1713:SDL_CreateWindow

Which confirms SDL_CreateWindow is exported.

Looking at dotnet.native.4f59ihtvzf.js I found this:

Module["requestFullscreen"] = Browser.requestFullscreen;
Module["requestFullScreen"] = Browser.requestFullScreen;
Module["requestAnimationFrame"] = Browser.requestAnimationFrame;
Module["setCanvasSize"] = Browser.setCanvasSize;
Module["pauseMainLoop"] = Browser.mainLoop.pause;
Module["resumeMainLoop"] = Browser.mainLoop.resume;
Module["getUserMedia"] = Browser.getUserMedia;
Module["createContext"] = Browser.createContext;

Which does confirm createContext is present as expected.

So far...

This issue is not present in SDL2 2.32.10 (latest) or below.

Seems to only happen in SDL 3.x.x but works on ALL other platforms (window, Linux, etc) apart from Emscripten. It may not be SDL_CreateWindow causing the issue it could be something internal that gets triggered when we call SDL_CreateWindow. I've played around with the parameters of the function as well and ensured I'm mapped correctly to the CreateWindow method in C to ensure its not a mismatch with my PInvoke but it works on every other platform. I can provide a minimal test project for this if possible to review?

Other than that, how can I take this further?

[sbc100]

If you can show a simple SDL3 program that fails in SDL_CreateWindow that would be great. Ideally something that doesn't also depend on dotnet too.

[LloydJHowarth]

Unfortunately I only work with dotnet so I can't provide such program. Assuming this works without dotnet being involved that's directing me towards the dotnet team as you previously mentioned. At least we've cleared up the requirement for createcontext here.

Thank you.

[LloydJHowarth]

Solution:

The SDL_WindowFlags in C expects Uint64. In C# my SDL_WindowFlags enum is defined as ulong but LibraryImport wasn’t correctly resolving the enum at runtime when targeting WASM therefore throwing the "function signature mismatch" assertion.

To fix the issue I changed this code from

private static partial IntPtr SDL_CreateWindowInternal(string title, int w, int h, SDL_WindowFlags flags);

to this instead

private static partial IntPtr SDL_CreateWindowInternal(string title, int w, int h, ulong flags);

Now its working on all platforms.