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

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

References

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 .

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?

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.

, 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

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.

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

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.

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

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)

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