Allegro.cc - Online Community
Post Reply

Allegro.cc Forums » Allegro Development » Lest compile allegro 5 with wasm for web games

rss feed Print
Lest compile allegro 5 with wasm for web games
dhia hassen
Member #16,240
March 2016

WebAssembly (abbreviated Wasm ) is a safe, portable, low-level code format designed for efficient execution and compact representation. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so can be employed in other environments as well.
c/c++ code can be compiled to wasm and run on web browsers , unity engine has an export wizzard for wasm
this is what wasm capable of https://www.youtube.com/watch?v=3w5AM6uWwYk

opengl calls are converted to webgl , sdl library is exported to wasm , are there any aims to do so with allegro , i will be glad to participate on this ;D ;D ;D

SiegeLord
Member #7,827
October 2006
avatar

There is a patchset for getting Allegro to work with emscripten, see this thread https://listengine.tuxfamily.org/lists.liballeg.org/allegro-developers/2014/06/msg00023.html. I imagine wasm would be similar. The key sticking point was Allegro's use of threads, but it wasn't that bad in the end I thought.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

beoran
Member #12,636
March 2011

I think this is a great idea if it could be incorporated cleanly into Allegro. The web browser is an important platform these days. Too bad I can't offer much in the way of assistance...:P

Elias
Member #358
May 2000

Note that the SDL port of Allegro already allows running Allegro 5 games in the browser: http://allegro5.org/html5/ex_draw_bitmap.html

So if the goal is to run your game in the browser with the least effort, that would be the way to go :)

--
"Either help out or stop whining" - Evert

Edgar Reynaldo
Member #8,592
May 2007
avatar

Elias
Member #358
May 2000

Well, SDL2 supports more platforms than Allegro5, so an SDL2 driver for Allegro5 makes sense while the other way around would not.

--
"Either help out or stop whining" - Evert

Edgar Reynaldo
Member #8,592
May 2007
avatar

Chris Katko
Member #1,881
January 2002
avatar

They basically do the same thing, a thin wrapper around the big ticket libraries like OpenGL/DirectX and system/window handler code. So I imagine a wrapper translation layer would be almost trivial to make in a weekend or two--just translating the (mostly) equivalent structures with different names.

Disclaimer: I'm NOT under-valuing the work the awesome devs put into Allegro. Merely compared to the armies of coders it takes to write say, OpenGL, WPF, etc.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Mark Oates
Member #1,146
March 2001
avatar

OK, this is amazing.

Dude, the fullscreen is 🔥

I want a piece of this so where should I start? Would it be best to start learning SDL or should I work with the Allegro emscripten approach?

Are there things like joystick support, MIDI support (through https://webaudio.github.io/web-midi-api/), and audio?

Elias
Member #358
May 2000

I want a piece of this so where should I start?

Unfortunately it's some time ago I last played with it [1]

But I want to revisit it after I'm done with porting Allegro's Android build from ant to gradle.

--
"Either help out or stop whining" - Evert

dhia hassen
Member #16,240
March 2016

I am very glad that the FPS is 60 , even SDL2 didnt easly had that hight FPS on web , by the way , you can even pass emscripten and compile to native web assembly and run it outside emscripten sandbox with even much heigher FPS XD , actually nothing to work on to establish that , we will just need to compile with the new emscrptin and chooce wasm flags .

Mark Oates
Member #1,146
March 2001
avatar

Another pie-in-the-sky dream I have is to find some way to automate the building of Allegro projects. The steps would be something like this:

  • Create an AllegroPlanet project.

  • Link the project to an open GitHub repo.

  • AllegroPlanet would clone and build the project for multiple platforms.

  • Links would be available for download.

With emscripten, this could taken one step further and the projects could be hosted and played on the browser! :o

Eric Johnson
Member #14,841
January 2013
avatar

Would it not be more advantageous to instead create a version of Allegro specifically built in JavaScript for use on the Web? I played my hand in this a few months back by creating a JS library that mimicked the functionality of Allegro (dubbed "allegro5.js") and even used it to make a game. It abstracts canvas calls through function names mimicking Allegro 5. It's far from perfect, and it's a little different than Allegro 5 in C, but it's a proof of concept. Thoughts?

Mark Oates
Member #1,146
March 2001
avatar

Nice! That almost feels like classic Allegro 4. Do you have any plans for it? Like, event queues and stuff like that?

dhia hassen
Member #16,240
March 2016

By time , game engines are avoiding javascript for web and going for wasm , if you guys want something promising it is better to build with wasm and not rewtire with javascript

Eric Johnson
Member #14,841
January 2013
avatar

Nice! That almost feels like classic Allegro 4. Do you have any plans for it? Like, event queues and stuff like that?

I'm not sure how to replicate Allegro 5's event queue system accurately in JavaScript, but I would like to. It is for this reason that accessing keys is done in a way more reminiscent of Allegro 4 than 5.

I actually haven't touched the code in several months. My goal with it was to replicate/mimic the functionality of Allegro 5 as closely as I could, but ran into some snags. There are several aspects of Allegro and C that simply do not make sense or is nearly impossible on the Web in JavaScript. For example, bitmap tinting is a breeze on desktop in C, but it is too slow to be done in real-time in JavaScript. I wrote a function that creates tinted bitmaps in JavaScript, but it is only really usable if done before starting the game loop, and even then it adds many seconds to loading time even for small bitmaps.

Being unsuccessful in making a one-to-one translation of Allegro 5 in JavaScript, I decided to devote my time to making my own game-making library in JavaScript separate from Allegro. It's called "Momo" and is on GitHub. It's not at version 1.0 just yet, but I've made a few games with it already.

If there's an interest in creating a dedicated JS version of Allegro, then I would gladly resurrect my attempt, or would devote my time to help develop someone else's rendition. :)

Chris Katko
Member #1,881
January 2002
avatar

, bitmap tinting is a breeze on desktop in C, but it is too slow to be done in real-time in JavaScript.

Is it really? Wow. You'd think that be a very basic feature... it's not like HTML5/Chrome/etc isn't running on a videocard capable of drawing tens of thousands of transformed, textured polygons a second...

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Eric Johnson
Member #14,841
January 2013
avatar

Is it really? Wow. You'd think that be a very basic feature... it's not like HTML5/Chrome/etc isn't running on a videocard capable of drawing tens of thousands of transformed, textured polygons a second...

What I said is true if using the canvas API. Through the use of shaders, you could probably pull it off in WebGL, but not otherwise, and not easily. As far as vanilla JS + canvas API is concerned, the only way I've managed it is to pre-compute the tint before the game loop, but even that's slow. But maybe someone more knowledgeable in JS than me would know a workaround.

Edit
I spent several hours today trying to tint bitmaps in real time in JavaScript and actually made some progress!

{"name":"DJqkmUFWsAANA5Q.jpg:large","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/4\/74493f03c51f33aeb2cb245cbbc95ecd.jpg","w":1600,"h":900,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/4\/74493f03c51f33aeb2cb245cbbc95ecd"}DJqkmUFWsAANA5Q.jpg:large

The above renders two bitmaps: the original (yellow one) and a version tinted in red. It runs in real time with no frame rate issues, and even supports transparency! :D I'm really excited about this, because my previous attempts would average ~4 FPS, which prompted me to create them before starting the game loop, but no more! It still has a few bugs, but hopefully I can get those sorted out soon. ;D

Sebastian Krzyszkowiak
Member #14,084
February 2012
avatar

Just in case someone wants to play with it: I have rebased the SDL+Emscripten patches against current master (and my GLES pull request) and successfully compiled some of my Allegro 5 games with it: https://github.com/liballeg/allegro5/compare/master...dos1:emscripten

Instructions copy'n'pasted from my personal notes, for Arch Linux:
yaourt -S emsdk
sudo emsdk update
sudo emsdk install latest
emsdk activate latest

cd /usr/lib/emsdk
source ./emsdk_env.sh

(building Allegro:)
emcmake cmake .. -DCMAKE_BUILD_TYPE=Release -DWANT_MONOLITH=yes -DWANT_EXAMPLES=no -DWANT_TESTS=no -DWANT_DEMO=no -G Ninja -DCMAKE_INSTALL_PREFIX=install

(sometimes fails on some cmake check, but running it twice helps...)

ninja install

Then link your code with resulting file: install/lib/liballegro_monolith-static.a using flags such as "-s USE_SDL=2 -s USE_ZLIB=1 -s USE_LIBPNG=1 -s USE_FREETYPE=1 -s USE_OGG=1 -s USE_VORBIS=1 -s FULL_ES2=1". "-s TOTAL_MEMORY=<memorysize>" option might also be useful (in bytes, must be a multiple of 16MB).

It's still very quick'n'dirty, but works for basic experiments :) Should work with WASM backend too (add "-s WASM=1" to flags when compiling your game), but I haven't tested it yet (doesn't work with my engine, which uses MAIN_MODULE and SIDE_MODULE options that don't play nicely with WASM just yet).

Elias
Member #358
May 2000

Do you have a link to try one of those games in a browser?

--
"Either help out or stop whining" - Evert

Sebastian Krzyszkowiak
Member #14,084
February 2012
avatar

https://dosowisko.net/boiledcorn/libsd.html
https://dosowisko.net/blinddate/blinddate.html

Those of course are by no means complete ports, just quick experiments. Boiled Corn has some glitch with input (the throw power wraps when you press and hold space too long) on SDL platform that I have yet to investigate (on regular Allegro it works fine); The Blind Date sometimes draws two mouse cursors; and both hang on loading instead of drawing the loading screen (so if it hangs on a intro logo, just wait until it loads). Otherwise they seem to be playable for me :) (aside of random memory corruption happening from time to time randomly between rebuilds... needs to be investigated what's the culprit)

It's still asm.js though, not Web Assembly.

[edit]
I've updated post above with cleaned up branch and simpler instructions, enjoy! :)

beoran
Member #12,636
March 2011

I think that with some more polishing this should be added to allegro5 proper. Portability to the web is a popular feature for game libraries these days, even if performance is not so great.

Sebastian Krzyszkowiak
Member #14,084
February 2012
avatar

Forgot to mention: audio streaming doesn't work there (which is kinda expected due to its usage of threads). Emscripten has some experimental pthreads support, but it also doesn't play nicely with other options I needed, so I haven't tested it. In the end I've stubbed audio stream functions to work with audio samples under the hood and that was enough for my own needs, but probably won't cut it for everyone :P In case someone's interested: https://github.com/dos1/libsuperderpy/blob/master/src/emscripten-audio-stream.c

Other that that, this Emscripten patch requires my GLES rework to avoid lots of #ifdef _EMSCRIPTEN_ in OpenGL code. I'm by no means GL expert, so any help with reviewing, testing and fixing this PR would be appreciated! :) https://github.com/liballeg/allegro5/pull/826

beoran
Member #12,636
March 2011

Hmm, seems the lack of threads on emscripten is a bit of a blocker there... Perhaps we should wait after all until that gets sorted out.

Edit: looks like the browser makers are planning some hairy stuff to allow background workers and audio...

https://webaudio.github.io/web-audio-api/#AudioWorklet

Post Reply
Go to: