[emscripten] Web build #1776

ololoken · 2025-06-05T17:55:25Z

I'm working on wasm port.
Demo is available here https://turch.in/rttr/index.html

Right now it's not playable. As emscripten do not support socket listen in web environment.
And I need good advice: how do you (settlers freaks) see implementation of local connection without sockets?

Flamefire

Interesting approach. I added some comments on the changes if you want to continue with this.

Of course I need to ask for the motivation of this. Besides it clearly being a nice experiment on current capabilities.
E.g. I notice that it is already quite sluggish in the main menu. So why not using the regular builds given that we have performance issues for large maps with that already?

And I need good advice: how do you (settlers freaks) see implementation of local connection without sockets?

I think this would be an incredible effort possibly making the (regular) code much less maintainable. For now we can consider all games non-local/multiplayer for the purpose of the core logic.
Decoupling this means we would have 2 almost completely separate control flows that would need testing and being unable to detect and debug multiplayer issues using the regular flow.
I'd rather not do that.
Is there really no other way?

Flamefire · 2025-06-06T07:02:35Z

CMakeLists.txt

 set(rttrContribBoostDir ${CMAKE_CURRENT_SOURCE_DIR}/contrib/boost)
 if(EXISTS ${rttrContribBoostDir} AND IS_DIRECTORY ${rttrContribBoostDir})
    set(BOOST_ROOT ${rttrContribBoostDir} CACHE PATH "Path to find boost at")
+    if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")


Common pitfall: This could get double-extended. Just omit the dollar sign

Suggested change

if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")

if (CMAKE_SYSTEM_NAME MATCHES "Emscripten")

Flamefire · 2025-06-06T07:05:41Z

CMakeLists.txt

 if(EXISTS ${rttrContribBoostDir} AND IS_DIRECTORY ${rttrContribBoostDir})
    set(BOOST_ROOT ${rttrContribBoostDir} CACHE PATH "Path to find boost at")
+    if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
+        set(Boost_INCLUDE_DIR "${rttrContribBoostDir}/include" CACHE PATH "Path to find boost at")


Not required: BOOST_ROOT is enough. Possibly should be replaced by Boost_ROOT though.

Flamefire · 2025-06-06T07:06:17Z

CMakeLists.txt

 option(RTTR_USE_SYSTEM_BOOST_NOWIDE "Use system installed Boost.Nowide. Fails if not found!" "${RTTR_USE_SYSTEM_LIBS}")
-
+if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
+set(RTTR_USE_SYSTEM_BOOST_NOWIDE ON)


Verify indents

Suggested change

set(RTTR_USE_SYSTEM_BOOST_NOWIDE ON)

set(RTTR_USE_SYSTEM_BOOST_NOWIDE ON)

Flamefire · 2025-06-06T07:07:03Z

external/CMakeLists.txt

+if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
+else ()


Avoid those here and down, also correct indent for next line

Suggested change

if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")

else ()

if (NOT CMAKE_SYSTEM_NAME MATCHES "Emscripten")

Flamefire · 2025-06-06T07:08:38Z

extras/audioDrivers/SDL/AudioSDL.cpp

 }

-const char* GetDriverName()
+const char* GetAudioDriverName()


This breaks the interface, see

s25client/libs/s25main/drivers/DriverWrapper.cpp

Line 110 in ec289ff

auto GetDriverName = dll.get<GetDriverName_t>("GetDriverName");

Flamefire · 2025-06-06T07:29:51Z

libs/s25main/drivers/VideoDriverWrapper.cpp

    return Initialize();
 }

+bool VideoDriverWrapper::LoadDriver()


See suggestion for Audiodriver

Flamefire · 2025-06-06T07:31:44Z

libs/s25main/drivers/VideoDriverWrapper.cpp

        renderer_ = std::make_unique<DummyRenderer>();
    if(!renderer_->initOpenGL(videodriver->GetLoaderFunction()))
        return false;
+#ifndef __EMSCRIPTEN__


For if-else rather use the non-inverted, i.e. start with #ifdef __EMSCRIPTEN__

Flamefire · 2025-06-06T07:33:54Z

libs/s25main/ogl/OpenGLRenderer.cpp

 bool OpenGLRenderer::initOpenGL(OpenGL_Loader_Proc loader)
 {
-#if RTTR_OGL_ES
+#if defined(RTTR_OGL_ES)


This should be set, shouldn't it? Using #if instead of #ifdef allows us to detect misspellings so we should keep it

Flamefire · 2025-06-06T07:35:06Z

libs/s25main/ogl/OpenGLRenderer.cpp

-#if RTTR_OGL_ES
+#if defined(RTTR_OGL_ES)
    return gladLoadGLES2Loader(loader) != 0;
+#elif __EMSCRIPTEN__


Shouldn't this be ifdef similar to other places? If so I guess it is easier to put at the top as ifdef and elif RTTR_OGL_ES here

Flamefire · 2025-06-06T07:37:32Z

libs/s25main/ogl/glArchivItem_BitmapBase.cpp

+#include "SDL/SDL.h"
+#include "SDL/SDL_opengl.h"
+#else
 #include <glad/glad.h>


Can't glad work with emscripten? This is repeated so often even though there is no other change so I'd think it should work using the same method as glad can handle e.g. OpenGL ES already

It can work, at least latest versions claims support of emscripten. I just didn't find good reason for myself to keep glad.

Well I'm asking because of maintainability: We are using glad to support all platforms without additional ifdefs.

I understand, will check glad for option to migrate back to glad, right now there is problem runtime gl function resolution.
BTW about networking I see the first packet from server to client is ping 0x01, 0x02, 0x01, 0, 0, 0, right? How does handshake routine look like?

The Handshake is quite simple:

Server sends player id to client on connect: GameMessage_Player_Id https://github.com/Return-To-The-Roots/s25client/blob/master/libs/s25main/network/GameServer.cpp#L848

Client answers with own version: https://github.com/Return-To-The-Roots/s25client/blob/master/libs/s25main/network/GameClient.cpp#L417

Server confirms the version: https://github.com/Return-To-The-Roots/s25client/blob/master/libs/s25main/network/GameServer.cpp#L929

ololoken · 2025-06-06T18:54:25Z

@Flamefire well, motivation is to get original fill and look. First I ported widelands, playable version is here https://turch.in/widelands/ . But it's a bit different game... Besides, it's cool to have version of the game which doesn't require download and install, it just works right now and here in browser.
Yes there are performance issues, wasm is executed in 32bit vm with jit, but I think it's not a big problem as machines gets faster(slower than before, but steady) and wasm vm soon may get fat performance boost with upcoming updates.
I will go through comments later and add fixes. First I want to consider workaround for network problem. I agree that adding of custom logic for local game is bad idea in matter of maintenatability. There few options I can try: it's time to write own websocket-tcp/udp proxy, hack libwebsocket.js to make virtual peer connections for localhost.

ololoken · 2025-06-08T15:17:19Z

Well, experiment with hacking of libsock.js was successful + I had to slightly modify game network code: recv messages in complete chunks, without waiting for any additional blocks.

But @Flamefire you are right, ingame performance is too poor even with aggressive optimisations. Do you have any ideas how to fix that?

Farmer-Markus · 2025-06-09T09:09:45Z

It seems like you have the same problem with the graphics/shadows as my Android port of rttr. Do you know why this happens? Would help me a lot :D

Flamefire · 2025-06-09T09:38:01Z

But @Flamefire you are right, ingame performance is too poor even with aggressive optimisations. Do you have any ideas how to fix that?

TBH: The core code isn't exactly optimized for performance. There are a lot of indirections and virtual calls leading to pointer-chasing and poor branch prediction.
But the code has to work at all and be easy enough to follow to verify it is always in sync for all players. I.e. the simulation must be in lock-step which was the main focus with performance being "good enough" except for large maps and road networks where the pathfinding starts to be a bottleneck.

I don't think there is an easy way to fix this without rewriting a lot of the code which then might reintroduce especially all the async bugs we fixed over the years. Although there are some targeted optimization opportunities like one recently fixed in the pathfinding code: #1734

ololoken · 2025-06-09T09:38:06Z

It seems like you have the same problem with the graphics/shadows as my Android port of rttr. Do you know why this happens? Would help me a lot :D

There must something related to textures format/internal format. I'm looking at TerrainRenderer and something tells me that 99% of its code can be done by shaders.

Flamefire · 2025-06-09T09:50:26Z

There must something related to textures format/internal format. I'm looking at TerrainRenderer and something tells me that 99% of its code can be done by shaders.

I started with introducing shaders a long time ago but never got around finishing it. My first point was about handling player textures by the shader instead of the bitmap class. I.e. have the shader combine the main texture and color the masked overlay.

And yes the TerrainRenderer is mighty tricky. There are a few tricks already used to make rendering as efficient as possible grouping stuff. A lot might also be gained by caching part of the scenes. E.g. the terrain is static as long as the view isn't scrolled or height levels are adjusted. I introduced listeners to make this feasible but again didn't get around using them for this especially due to the existing code complexity

ololoken · 2025-06-09T14:04:18Z

Well, if I had planning a renderer for terrain there must be one big texture atlas with terrain sprites, generated texture with tiles indexes from atlas + gl program which accepts both 2d samples and by pixel copies atlas sprites to it's onscreen positions using mapping from indexes texture. Then in same way apply gl program to render dither between terrain connections water/land greenland/winter etc. Then gl program to render roads, then objects.
Not sure when, but I will try to implement it.

Flamefire · 2025-06-09T15:37:43Z

Well, if I had planning a renderer for terrain there must be one big texture atlas with terrain sprites, generated texture with tiles indexes from atlas + gl program which accepts both 2d samples and by pixel copies atlas sprites to it's onscreen positions using mapping from indexes texture. Then in same way apply gl program to render dither between terrain connections water/land greenland/winter etc. Then gl program to render roads, then objects. Not sure when, but I will try to implement it.

We have the texture atlas already. The textures are given as positions/triangles inside that. That's actually inherited from S2.
One major point would also be support for animated textures: Water uses multiple parts of the texture and in some terrains there is e.g. lave doing that too.

If you get some minimal program working just for the terrain textures and transitions that includes the animation I'd be very curious to see that :-)

Farmer-Markus · 2025-06-16T16:17:49Z

It seems like you have the same problem with the graphics/shadows as my Android port of rttr. Do you know why this happens? Would help me a lot :D

There must something related to textures format/internal format. I'm looking at TerrainRenderer and something tells me that 99% of its code can be done by shaders.

I've fixed the shading issues. I don't know if this works for your web port but here are the changes(just the few in the terrain renderer)

https://github.com/Farmer-Markus/s25rttr-android/blob/main/patch%2Fs25client.patch#L2207

ololoken · 2025-06-16T16:31:55Z

@Farmer-Markus awesome, I will try. Currently my only progress is ruining of terrain rendering completely and attempt to show at least something.

ololoken · 2025-06-22T08:21:47Z

What I'm working on:

precision highp float;
attribute vec2 aVertexPosition;

uniform mat3 projectionMatrix;

varying vec2 vTextureCoord;

uniform vec4 inputSize;
uniform vec4 outputFrame;

vec4 filterVertexPosition (void) {
    vec2 position = aVertexPosition * max(outputFrame.zw, vec2(0.)) + outputFrame.xy;

    return vec4((projectionMatrix * vec3(position, 1.)).xy, 0., 1.);
}

vec2 filterTextureCoord (void) {
    return aVertexPosition * (outputFrame.zw * inputSize.zw);
}

void main (void) {
    gl_Position = filterVertexPosition();
    vTextureCoord = filterTextureCoord(); // get texture coord
}

and main magic happens in fragment shader

precision highp float;
varying vec2 vTextureCoord;
uniform vec4 outputFrame;
uniform vec4 inputSize;

uniform sampler2D uAtlas; // really big texture with all loaded sprites
uniform vec2 uAtlasSize; // it's size
uniform vec2 uTileSize; // for now supports only fixed tile size
uniform vec2 uOutSize;// "real" output size

uniform sampler2D uMapping; // texture where we store in "zw" vec2 coords of sprite in atlas
uniform vec2 uMappingSize; // mapping texture size
uniform vec2 uBackgroundSize; // background size in map points
uniform vec2 uBackgroundOffset; // background offset in pixels

void main () {
    // copy current pixel color from atlas using mapping texture

    vec2 uv = vTextureCoord/outputFrame.zw*inputSize.xy;//remap to [0..1] as output depends on "inner" tileset
    vec2 tileAtlas = uTileSize/uAtlasSize;
    vec2 screenTile = (uv*uOutSize+uBackgroundOffset)/uTileSize;

    vec2 tileCoord = floor(screenTile); //  index in mapping sample 
    vec2 tileInnerCoord = fract(screenTile)*tileAtlas; // relative coords

    float mappingIndex = tileCoord.y*uBackgroundSize.x+tileCoord.x;
    float mappingY = floor(mappingIndex/uMappingSize.x);
    float mappingX = mappingIndex-mappingY*uMappingSize.x;
    vec2 shapeCoord = vec2(mappingX, mappingY)/uMappingSize;
    // here we finally found x,y of sprite in atlas texture 
    vec2 tileAtlasCoord = 255.0*texture2D(uMapping, shapeCoord).xy*tileAtlas;
    // finally output pixel color using 
    gl_FragColor = texture2D(uAtlas, tileAtlasCoord+tileInnerCoord);
}

nothing really to show yet, but I fill that it might and will work.

ololoken · 2025-06-24T01:43:23Z

Looks better, runs faster. Will perform some cleanups, add save/load functionality and update PR I think my changes will affect native app performance as well.

Flamefire · 2025-06-24T07:03:02Z

Looks better, runs faster. Will perform some cleanups, add save/load functionality and update PR I think my changes will affect native app performance as well.

Great work! I also assume it will improve the native app.

Did you get the animations for water and lava working with the shader?
If so can you factor out the changes to the rendering to a PR separate from the emscripten changes? Besides having more manageable PRs/changesets I'm not fully convinced about emscripten. So for me that would depend on how intrusive the changes required are and of course what @Flow86 thinks about it.

But as mentioned: I'd really love to have a shader based renderer in any case

Spikeone · 2025-06-24T08:04:39Z

Looks better, runs faster. Will perform some cleanups, add save/load functionality and update PR I think my changes will affect native app performance as well.

Great work! I also assume it will improve the native app.

Did you get the animations for water and lava working with the shader? If so can you factor out the changes to the rendering to a PR separate from the emscripten changes? Besides having more manageable PRs/changesets I'm not fully convinced about emscripten. So for me that would depend on how intrusive the changes required are and of course what @Flow86 thinks about it.

But as mentioned: I'd really love to have a shader based renderer in any case

I'd love shader based renderer, maybe that'd help improving the lightning and would be closer to the original :)

…Arrays with glBegin/glEnd

ololoken · 2025-06-24T10:35:30Z

ok, maybe my update will be a bit disappointing, but I overestimated my dev capabilities to impose such significant refactoring like rendering via gl program.
The good stuff is that I noticed bottleneck in rendering loop while I was trying. And replacement of glDrawArrays with glBegin/glEnd did the magic. Minimum of changes with great result, I like it.

Regarding emscripten, there are a lot of bits to do. It requires lwebsocket.js library patching + you need standalone html/js project to run the build. In other words far from PR candidate.

Flamefire · 2025-06-24T11:04:24Z

The good stuff is that I noticed bottleneck in rendering loop while I was trying. And replacement of glDrawArrays with glBegin/glEnd did the magic. Minimum of changes with great result, I like it.

Sounds great! What exactly was that bottleneck?

As for that replacement: I'm actually surprised by that. The immediate mode (glBegin/glEnd) puts more stress on the CPU with the additional driver calls and is deprecated in OpenGL 3 and removed in OpenGL ES and partially(?) in OGL 3.1
I have found reports that glDrawArrays was not faster than immediate mode with explanations that this likely happens in environments doing software rendering, i.e. processing of the OpenGL pipeline is done partially/mostly on CPU so you don't gain much by batching the calls.

Especially as we have users using OpenGL ES we can't switch back to immediate mode.

However having this identified as a bottleneck is still very useful as it means we can improve our usage in this area, e.g. by not transmitting the data on every call but storing it server-side/on GPU.
We should benchmark the difference and see where / which objects benefit most of the change and see how to optimize those using the new API.

ololoken · 2025-06-24T11:23:59Z

Well in my case I got performance improvement 5-6 fps (with empty map) -> 45-50fps (very tight road graph) after migration to immediate mode.
Will try to check gl4es library internals, I'm using it as replacement of glad for emscripten build.

Flamefire · 2025-06-24T11:27:01Z

I guess we need to check if this is the same for the native builds or if the difference isn't there or opposite of the emscripten build.

Maybe there is some emulation of the OpenGL 3 APIs in the library onto the immediate mode pipeline?

ololoken · 2025-06-24T11:36:43Z

Definitely there is emulation https://github.com/ptitSeb/gl4es/blob/a744af14d4afbda77bf472bc53f43b9ceba39cc0/src/gl/gl4es.c#L246

…how loading/please wait popup while this operation is performed

ololoken added 9 commits May 30, 2025 22:22

[emscripten] initial build

5210d7e

Merge remote-tracking branch 'origin/master'

a0601e8

[emscripten] modularize; emscripten main loop

5a27507

Merge remote-tracking branch 'origin/master'

b3a76ad

Merge remote-tracking branch 'origin/master'

79e8ea5

[emscripten] link drivers statically

4d138dc

[emscripten] runnable build

34b2223

[emscripten] lua build

f233505

[emscripten] revert some cmake changes

b3c124f

Flamefire reviewed Jun 6, 2025

View reviewed changes

ololoken added 2 commits June 7, 2025 14:15

[emscripten] fix some review comments

11f89b6

[emscripten] more review comments fixes

5a36ad6

Merge remote-tracking branch 'origin/master'

deca7c1

[emscripten] sync persistance store on save game; replace slow glDraw…

98fd863

…Arrays with glBegin/glEnd

ololoken added 3 commits June 25, 2025 01:08

[emscripten] hide some ui stuff not applicable in web

4ddac87

Merge remote-tracking branch 'origin/master'

5443372

[emscripten] require js wrapper that idbfs sync required: allows to s…

666d680

…how loading/please wait popup while this operation is performed

	if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
	if (CMAKE_SYSTEM_NAME MATCHES "Emscripten")

	set(RTTR_USE_SYSTEM_BOOST_NOWIDE ON)
	set(RTTR_USE_SYSTEM_BOOST_NOWIDE ON)

	if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
	else ()
	if (NOT CMAKE_SYSTEM_NAME MATCHES "Emscripten")

[emscripten] Web build #1776

Are you sure you want to change the base?

[emscripten] Web build #1776

Uh oh!

Conversation

ololoken commented Jun 5, 2025

Uh oh!

Flamefire left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ololoken commented Jun 6, 2025

Uh oh!

ololoken commented Jun 8, 2025

Uh oh!

Farmer-Markus commented Jun 9, 2025

Uh oh!

Flamefire commented Jun 9, 2025

Uh oh!

ololoken commented Jun 9, 2025

Uh oh!

Flamefire commented Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ololoken commented Jun 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Flamefire commented Jun 9, 2025

Uh oh!

Farmer-Markus commented Jun 16, 2025

Uh oh!

ololoken commented Jun 16, 2025

Uh oh!

ololoken commented Jun 22, 2025

Uh oh!

ololoken commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Flamefire commented Jun 24, 2025

Uh oh!

Spikeone commented Jun 24, 2025

Uh oh!

ololoken commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Flamefire commented Jun 24, 2025

Uh oh!

ololoken commented Jun 24, 2025

Uh oh!

Flamefire commented Jun 24, 2025

Uh oh!

ololoken commented Jun 24, 2025

Uh oh!

Flamefire commented Jun 9, 2025 •

edited

Loading

ololoken commented Jun 9, 2025 •

edited

Loading

ololoken commented Jun 24, 2025 •

edited

Loading

ololoken commented Jun 24, 2025 •

edited

Loading