Web builds?

[tommy-mitchell]

Are web builds supported by SDL2, or easy to compile to? Coming from Unity, I’d like to tinker with Foster for a game jam and publish on itch.io.

[NoelFB]

Hey, SDL2 web builds are possible with Emscripten. However, I really do not know what the current state of compiling C# for the web is. You'd need to both build the native C Platform library with Emscripten and then also compile the C# code with Blazor or something, and have them link up nicely.

[MrBrixican]

Theoretically, it may be possible. Something similar was done with Raylib-cs. Keep in mind, it is uncharted territory so documentation/examples are likely to be sparse. I'd be extremely interested in any attempts to make it work, though.

[NoelFB]

I did a quick experiment based on the Raylib-cs example. I got the C# running, but for whatever reason I could not get it to P/Invoke into the native DLL I built with emscripten - it always resulted in an error at System.Reflection.MethodInvoker.InterpretedInvoke(Object , Span`1 , BindingFlags ).

Definitely seems possible though! But would likely require some fixes / changes.

[MrBrixican]

That's great! If possible can you create a branch/repo with what you have so far? I don't really care if it's broken, just a starting point that I could tinker with would be phenomenal.

[tommy-mitchell]

https://gist.github.com/tommy-mitchell/c6aadf0b7fdc1f832a0a075a545a67fb

Here's a gist, I get the same error when running.

[NoelFB]

A few things from your example:

• I don't see a native build of the platform library... If you're getting the same error without it that makes me think it was never linking/loading properly when I was doing it.
• You don't need some flags in emcc (specifically we're not using sUSE_GLFW, but you instead may need sUSE_SDL=2?)

[NoelFB]

I got a little further with this today, but there's definitely a lot of weird issues. I may create a branch to experiment in.

Things I've found so far:

• For whatever reason the native library seems to need to be named FosterPlatform.a and not libFosterPlatform.a
• If I add the Emcc flag -s USE_SDL=2 to the csproj, I get a lot of emscripten cache python errors. However, if I don't include this flag then it's not able to link SDL methods. The weird thing is if I compile once with the USE_SDL=2 flag, and then compile again without it, it works. So I have to awkwardly compile twice with the flag toggled on/off to get it to work.
• Internally Foster sends/receives data via function pointers, but that turns out to be fairly ugly in Wasm. You need to add [UnmanagedCallersOnly(CallConvs = new[] { typeof(CallConvCdecl) })] to any functions you intend to pass into the C library, and then the variables need to be unmanaged delegates, ex. public delegate* unmanaged[Cdecl]<int, byte, void> onKey. It makes me think that perhaps refactoring the internals to an event queue would make more sense instead of creating these ugly delegates.
• After all this, it still fails on SDL methods, but this time during runtime: missing function: SDL_GetVersion. At least at this point it's booting for me and calling into the C library before failing.

[tommy-mitchell]

For whatever reason the native library seems to need to be named FosterPlatform.a and not libFosterPlatform.a

Not sure why, but the Raylib-cs example does the same (libraylib.a -> raylib.a): https://github.com/disketteman/DotnetRaylibWasm/blob/main/.github/workflows/gh-pages.yml#L41

[TheWaWaR]

I tried it too, but with no luck.

However, you guys may interested in some things I found during the discovery.
First, according to SDL Wiki: Emscripten, should include emscripten.h in source code:

#ifdef __EMSCRIPTEN__
#include <emscripten.h>
#endif

And should use emcmake to build the library:

mkdir build
cd build
emcmake cmake ..
emmake make -j4

Also in CMakeLists.txt add_library should use STATIC instead of SHREAD.

Second, according to ASP.NET Core Doc

Prebuilt dependencies typically must be built using the same version of Emscripten used to build the .NET WebAssembly runtime.

Which I find is 3.1.34 in dotnet-8.0.

NOTE: emscripten 3.1.34 use it's own version of SDL2 (which is 2.24) to build the library, and that version of SDL don't support SDL_GetWindowSizeInPixels(which introduced in 2.26) yet.

[javaarchive]

I'm finding that the net 5 guide (that uses Uno Wasm Bootstrap instead of the newer NativeAOT) for fna is actually addressing a lot of these issues:
https://gist.github.com/TheSpydog/e94c8c23c01615a5a3b2cc1a0857415c

Why can't we just use the Emscripten port of SDL2?
Because the Emscripten version of SDL2 is forked from upstream for no apparent reason and is perpetually out of date. As a result it's currently incompatible with FNA.

So hypothetically you could also try shipping your own SDL2 which is implied to work?

The library lib prefix removing thing is also mentioned so I guess it's not actually new with nativeaot.

I believe Uno actually logs the full emscripten cli in debug, so I may potentially see if I have any old screenshots of the expected emcc flags, I'm not sure if -sUSE_SDL is needed if you are providing SDL yourself.

[MrBrixican]

Not sure if these are doing anything different, but here are two more recently updated .NET 7/8 C# raylib wasm repos:
https://github.com/Kiriller12/RaylibWasm
https://github.com/arturnista/RaylibWasm

[NoelFB]

Internally Foster sends/receives data via function pointers, but that turns out to be fairly ugly in Wasm.

I've also just refactored this today, so besides logging functions this should be much more straightforward now.

[NoelFB]

Alright I got this working but it took a fair amount of wrangling:
https://noelberry.ca/content/foster_wasm_test_1/

Brief list of things I had to do to get it working:

Getting SDL2 to work:

• Had to compile SDL2 myself as suggested here. However, I was trying to statically link it myself but I couldn't get it to work, so still had to include SDL2.a after building it.
• I had to modify SDL2 as for whatever reason MAIN_THREAD_EM_ASM_PTR did not exist for me. Fortunately only 2 places in SDL use it (SDL_assert.c and SDL_emscriptenmouse.c) so it was easy to comment those sections out.
• Even if we were fine with using whatever version of SDL2 emscripten comes packaged with, I couldn't get the flag -sUSE_SDL=2 to work. The dotnet wasm compiler stuff would fail in a python script with some kind of "FROZEN_CACHE" error.
• Had to rename libSDL2.a to SDL2.a for it to link properly.

Getting Foster to work:

Platform.FosterSetLogCallback needed to be changed to take a special delegate, as function pointers don't work in WASM the same way. The resulting code needed to look like this:

[UnmanagedCallersOnly(CallConvs = new[] { typeof(CallConvCdecl) })]
private static void HandleLog(IntPtr msg, int type)
{
	switch (type)
	{
		case 0: Log.Info(msg); break;
		case 1: Log.Warning(msg); break;
		case 2: Log.Error(msg); break;
		default: Log.Info(msg); break;
	}
}

static unsafe Platform()
{
	delegate* unmanaged[Cdecl]<IntPtr, int, void> fn = &HandleLog;
	FosterSetLogCallback((IntPtr)fn, 0);
}

[DllImport(DLL)]
public static extern void FosterSetLogCallback(IntPtr logFn, int level);

The main loop doesn't work nicely in emscripten either, and needed to be changed. It also means that the game is hard-coded to a fixed 60fps, instead of being able to dynamically change it like normal. It worked like this:

// in Platform.cs, link to `emscripten_set_main_loop`:
[DllImport(DLL)]
public static extern void emscripten_set_main_loop(IntPtr action, int fps, bool simulateInfiniteLoop);

// in App.cs, comment out `while (!Exiting)` and everything after, and replace with this:
unsafe
{
	delegate* unmanaged[Cdecl]<void> fn = &Tick;
	Platform.emscripten_set_main_loop(new IntPtr(fn), 60, true);
}
// this does mean the app will never shutdown, but that can be resolved more 
// gracefully with a way to end the emscripten main loop, but I didn't do it for this test.

// the Tick() method also needs this attribute added:
[UnmanagedCallersOnly(CallConvs = new[] { typeof(CallConvCdecl) })]
private static void Tick()

GLSL shaders had to be slightly adjusted to work with v300, which just meant changing the first line in the vertex/fragment shaders to:

#version 300 es
precision mediump float;

Finally, the resulting dll must be named FosterPlatform.a and not libFosterPlatform.a for whatever reason.

Creating a Wrapper Application

This project linked above is a really good example of how to set up the project. I changed a few things but mostly it's the same as what they did. I changed the main game to a library application, removed its Main entry point, and called it from the custom wrapper program. That csproj ultimately looked like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <RuntimeIdentifier>browser-wasm</RuntimeIdentifier>
    <WasmMainJSPath>main.js</WasmMainJSPath>
    <OutputType>Exe</OutputType>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <RunAOTCompilation>true</RunAOTCompilation>
    <WasmBuildNative>true</WasmBuildNative>
    <RootNamespace>FosterWasm</RootNamespace>
    <WasmNativeStrip>true</WasmNativeStrip>
    <EnableAggressiveTrimming>true</EnableAggressiveTrimming>
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>full</TrimMode>
    <!-- This is to basically disable globalization to exclude icudt.dat (1.5MB) and reduce size of dotnet.wasm -->
    <InvariantGlobalization>true</InvariantGlobalization>
    <ValidateExecutableReferencesMatchSelfContained>false</ValidateExecutableReferencesMatchSelfContained>
  </PropertyGroup>
  
  <Choose>
    <When Condition=" $(Configuration) == 'Debug' ">
      <PropertyGroup>
        <WasmEmitSymbolMap>true</WasmEmitSymbolMap>
        <EmccFlags>-sVERBOSE=1 -sMIN_WEBGL_VERSION=2 -Wbad-function-cast -Wcast-function-type -O2 -g3 -sINITIAL_MEMORY=128MB -sMAXIMUM_MEMORY=2048MB -sALLOW_MEMORY_GROWTH=1 -sASYNCIFY_STACK_SIZE=10000000</EmccFlags>
      </PropertyGroup>
    </When>
    <When Condition=" $(Configuration) == 'Release' ">
      <PropertyGroup>
        <EmccFlags>-sMIN_WEBGL_VERSION=2 -Wbad-function-cast -Wcast-function-type -O3 -g3 -sINITIAL_MEMORY=128MB -sMAXIMUM_MEMORY=2048MB -sALLOW_MEMORY_GROWTH=1 -sASYNCIFY_STACK_SIZE=10000000</EmccFlags>
      </PropertyGroup>
    </When>
  </Choose>

  <ItemGroup>
    <WasmExtraFilesToDeploy Include="index.html" />
    <WasmExtraFilesToDeploy Include="main.js" />
    <NativeFileReference Include="FosterPlatform.a" />
    <NativeFileReference Include="SDL2.a" />
    <WasmFilesToIncludeInFileSystem Include="$(ProjectDir)..\Assets\**\*.*" TargetPath="Assets\%(RecursiveDir)\%(Filename)%(Extension)" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\Source\Source.csproj" />
  </ItemGroup>

</Project>

Thoughts

All told this wasn't too bad, and I think we could support it, likely with a separate example project that has a custom wrapper like I described above and pre-build SDL2 and FosterFramework libraries. I don't have much time this month to iterate on this but as a proof of concept it's cool!

[javaarchive]

So MAIN_THREAD_EM_ASM_PTR was added last October.
https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3147---100923
and the latest I can find in the dotnet runtime repository references some version in March ( 03/14/23 )
https://github.com/dotnet/runtime/blob/v8.0.1/src/mono/wasm/emscripten-version.txt
So I'm guessing what happended here is dotnet is trying to pin an older version of emscripten itself, but newer SDL2 using that macro makes it only work on newer versions of emscripten not avali in current dotnet.