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

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.

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

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

That smacks of irony.

Where's the Allegro5 port of SDL2????

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

Please clarify - does it let you write SDL code that translates to Allegro? Or does it translate the Allegro code to SDL?

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.

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?

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.

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 .

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!

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?

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

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

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.

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"}

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! 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.

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).

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

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!

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.

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 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

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