<< December 2014 | Home | February 2015 >>

Emscripten Websocket <=> Reddwarf Server

I’m in the process of porting my gamekit based engine via emscripten to javascript which works thanks to the ogre3d’s current version 1.10 pretty good (thanks to wolfmanfx for his efforts). I wrote a module for ois to handle the input (mouse/keyboard) not perfect,yet but sufficient for the first tests. Maybe I should have tried to use sdl instead but was not quite sure how to initalize events only.

Still thread- and socket-handling todo. Sockets compiled without any problem BUT they are mapped to websockets in the javascript world. Websockets are slightly different from normal tcp-sockets. The raw data is embedded into a framebased protocol after a http-handshake occured.

I guess there won’t be a problem if I would have had also a c++-server that I would want to compile to js as well (not sure if that is a realtistic scenario :D ). At the moment I’m using a java reddwarf-server(short:RDS and formerly known as sun’s gameserver project-darkstar) which was canceled at once as soon as oracle took over sun and which is obviously not build to accept websockets. Not sure if ws existed at these days at all.

I found a very good java-library which can handle websockets. First you specify a callback handler for different events like onConnectionOpen, onMessage, onWriteDemand and onClose and then you can just pump a ByteBuffer into the lib which handles the decoding and calls the relevant callbacks in which you “just” have to do the right things :D

The only problem is that I didn’t had too much knowledge of reddwarf-servers internal process. RDS is mainly build to be highly multicore but abstract this behaviour from the server-user. So the kernel is mainly build with lots of async-concepts which I first had to learn before I could really extend the server.

Basically there is one main concept of delegating completion-handlers which has a start-method and a completion method. Those are stacked together so that the handler on top only passes its data to the lower one when the resulting data is ready. e.g. there is one handler A to read from a tcp-channel and another one B which is coupled with A and once A has its result B gets informed and can process until its result is ready and can be passed to the next underlying handler.

I basically wrote one such handler that sits between the handler which reads raw data from a socket-channel and the one that reads the raw data until a rds-message is complete. My handler takes the raw data, first checks if it is a websocket at all, if not just pass the data one to one to the next handler, if it is a websocket, make the handshake to the client-websocket,pump all incoming data into the websocket-decoder and then pass this data to underlying handler.

Took me some effort, but first tests are now working. All the unsucessfull attempts were still valueable to get more insights into the server kernel.

Emscripten and libRocket

libRocket is one of my ui-systems and it actually did work with emscripten outofthebox for one exception. For some reason rcss was not able to parse em-based values into float-values. It took me a some time to realise that emscriptens sscanf-function sees “0.5em” in opposite to all other compilers tested yet as an invalid value. When parsing the e-character it expects obviously another value afterwards.

Actually I wonder why the other compilers did convert 0.5em to 0.5f without 2nd thought. I changed the libRocket code to remove the suffix on the sscanf-call and now it works.

Here is the pull-request:


Wood Games 3D is offline :(

Sadly I have to annouce that from now on my first and still my only released game baby Wood Games 3D has been taken offline. Meaning it is still playable but the online-functionality scores and competitions won’t work anymore. After the 3rd party onlinescore service scoreloop quit, I had to write an replacement server. Which actually did work but not stable enough. Changing the application to the new server also destablized the whole application and it was too time consuming to keep fixing, which prevents me to go on with my current projects.

I’m actually really sad to take this tough decision, but I promise Lox, the little red haired girl you play in the game, will be back!

Thanks to all 54.951 Players since 09/2011

Want to say good bye? https://play.google.com/store/apps/details?id=org.tt

The release trailer! Isn't it cute? :D

Trapped in Emscripten?

Just started trying to port gamekit to emscripten. Beyond other problems I struggled on swig generated lua-layer which threw a for me cryptic “trapped”-exception in the ‘SWIG_Lua_namespace_register’-function.

To make the long story short. Swig 2.0.11 created invalid code with int SWIG_Lua_namespace_register(..) function that did not return a value, which seemed to be the problem. Adding a return 1; manually at the two problematic function fixed the problem.

For a happy ending for this specific problem it was sufficient to upgrade to swig3.0.3…


Actually swig3 seems to have changed its way of how inhertitance is handled, which somehow broke inheritance of methods at all!? Using the swig-switch -squash-bases let you use the old way, but this brought back the emscripten-problems :D. Ok, there seems no way around to fix it in swig itself.


Very cool, posted a pull-request on the swig-changes and they got merged immediately :D

gamekit goes browser

Oh, wow! I’m a bit shocked that a very first gamekit-game showed up in my browser! After some struggles and still lots of work to do, but that motivates a lot just to see the beloved default-cube on screen.


<< December 2014 | Home | February 2015 >>