Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Experiments: Allegro + Emscripten.

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Experiments: Allegro + Emscripten.
Max Savenkov
Member #4,613
May 2004
avatar

Sorry for late answers, everyone, I've been busy for a while.

EDIT: I'm researching this some more, and ya, it is kind of cool. You said games can't be ported as-is, what does that mean? What kind of changes are involved?

I wrote about this before, but I'll repeat it here: because of nature of JavaScript, you can't write endless loops.

Most Allegro games are structured like that (simplified):

main()
{
    init();
    while( !exit )
    {
         do_game_stuff();
    }
    cleanup();
}

In JS, you'll have to replace endless loop with a call to emscripten_set_main_loop, which will set it up so browser will call your frame function whenever it's going to draw a frame. The code, therefore, will look like this:

#SelectExpand
1frame_func() 2{ 3 do_game_stuff(); 4} 5 6main() 7{ 8 init(); 9 10 // if the last argument is 1, this call will not be finished until 11 // the game stops (via call to emscripten_cancel_main_loop), so the 12 // cleanup code after it won't be executed too early. 13 emscripten_set_main_loop( frame_func, 0, 1 ); 14 15 cleanup(); 16}

If your game is set up in this way, it will be very easy to port it, only a small change required. But if you have multiple nested endless loops, like Cosmic Protector demo, for example, then you're in trouble. Such code would be very troublesome to port:

#SelectExpand
1 2void doMenu() 3{ 4 while( !exitMenu ) 5 { 6 al_wait_next_event( &queue, &event ); 7 ... 8 } 9} 10 11void doLevel() 12{ 13 // A lot of other nested stuff. 14} 15 16void doGame() 17{ 18 if ( doMenu() ) 19 { 20 doLevel(); 21 } 22 23 doRestartTransition(); 24} 25 26main() 27{ 28 init(); 29 while( !exitGame ) 30 { 31 doGame(); 32 } 33}

Max, here's the console output when I run it on my laptop :

Oh, yes, indeed it can't initialize OpenGL. Windows laptops aren't known for good OpenGL support, unfortunately.

News:
For the last few days, I've been busy with one task only: compiling FreeType for Esmcripten. This was the worst piece of experience with a combination of open-source software I've had in a long while. Anyway, I have a result. Namely, ex_ttf running in browser. Take your time to enjoy, I've sweated for it :)

If you want some details (and even if you don't), I'll oblige. What went wrong: everything. For one, FreeType is the only Allegro dependency I know that absolutely HAS to use ./configure and does not have even a 3rd-party CMake file (this saved me with Ogg/Vorbis and libpng).

You can't run ./configure script in Windows, of course, unless you use MinGW or cygwin. Unfortunately, they do not help in this case, because we're cross-compiling for a system that is unknown to ./configure (and therefore we can't easily specify it via --host=tiple). This leads to a problem whenever ./configure tries to compile a native executable and run it (for FreeType, there are around 3 such calls).

The only way I found was to completely remove this checks from ./configure. As you may know, editing a ./configure script by hand is not a job for weak of heart. Anyway, I've done it and it didn't help me much. Now I had a Makefile, but it was a broken one. I suppose that was because it was generated by MinGW, but used by Emscripten's Python scripts, and they couldn't agree on slashes/backward slashes. Or something. At this point, I gave up on compiling FreeType on Windows and decided to try to compile in under Linux instead (here's a magic of JavaScript: I could easily use resulting file under Windows!).

I had two distros installed in VirtualBox: Mint 12 and Mageia 2. Both quite old, from my previous attempts at compiling pet projects for Linux (successful, but ultimately abandoned). I've downloaded and compiled all necessary tools... And hit a brick wall. In both distros, clang compiler was broken! It could not find some gcc libraries (libgcc.a and some others), because it tried to use hard-coded paths or something like that. There were bugs filled in both distros' trackers, but they weren't conclusively resolved.

To cut the story short, I've deleted both VMs and installed one with KUbuntu. After that, it was only a matter of few hours to compile Clang with fastcomp support (which is needed for emscripten, but isn't in upstream Clang yet) and then finally compile FreeType.

So there you have my story of woe and troubles.

Game Jam I was porting Allegro for begins tomorrow, so I do not expect to have much free time to post new examples here or port features, or for anything, really, but I promise to be back after that with sources and a patch for GIT version of Allegro.

Trent Gamblin
Member #261
April 2000
avatar

Thanks for the explanation. That's not too bad of a restriction. It's good to structure your code like that anyway. It might be hard to make a game that has both web and desktop versions that share the same code... if you started out with the intention of making a web-based game then both would work but it's not ideal. Anyhow, I think this is pretty cool...

EDIT: I don't think it's a good idea to put in Allegro git right now. I think we need a feature freeze for 5.2, then we can consider it for 5.3.

Elias
Member #358
May 2000

Nah, just let's put it into git, that's what it is for. We're very far away from 5.2 after all, at least a few years.

But only if the code is clean of course. Last thing we need is any more code where someone just made something work quickly instead of doing it properly and at least documenting what everything is for.

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

Gassa
Member #5,298
December 2004
avatar

Good luck at the Game Jam!

Max Savenkov
Member #4,613
May 2004
avatar

EDIT: I don't think it's a good idea to put in Allegro git right now. I think we need a feature freeze for 5.2, then we can consider it for 5.3.

Elias said:

Nah, just let's put it into git, that's what it is for. We're very far away from 5.2 after all, at least a few years.

But only if the code is clean of course. Last thing we need is any more code where someone just made something work quickly instead of doing it properly and at least documenting what everything is for.

I'll get the patch ready anyway, so it could be applied now or later. I'll need to clean up code some, and fix build system. But I was hoping that maybe if it was in git other people would help to fix things I don't know how to fix (like usage of vertex arrays and newly-discovered absence of support for mipmap generation - which SHOULD be there, so there is a problem with detection of OpenGL extensions somewhere, I think). Of course, I'll defer to community judgement on the exact moment of inclusion into git.

Gassa said:

Good luck at the Game Jam!

Thanks!

Trent Gamblin
Member #261
April 2000
avatar

We can have 5.2 out within months if anybody would help with it. This is definitely not a 5.2 feature if you ask me, but Peter is the release manager so it's up to him. I most definitely don't want to maintain this feature.

That said, what you mention about "working quickly" is definitely right and this doesn't work well at all. I get 400 FPS in the worst parts of Skater in a real program and 20 FPS with this. The whole thing is entirely a hack (running C code compiled to JavaScript) and should be considered much lower priority than a stable 5.2 release.

Max Savenkov
Member #4,613
May 2004
avatar

I actually agree that this is not for 5.2. As far as I understand, the main focus for 5.2 was support for mobile platforms (especially Android), and there is no need to take away manpower from it (such as it is). Emscripten support certainly isn't ready for prime-time right now.

As for 5.2... Could anyone point me to List Of Things That Absolutely Have To Be Done For 5.2? I've checked out some bugs in tracker, but I'm not sure how to help.

I'm quite good at debugging things, no so good at architecture.

beoran
Member #12,636
March 2011

Here's the planned features for 5.2, although they're not completely set into stone:

http://wiki.allegro.cc/index.php?title=Allegro_roadmap

As for this Emscripten port, it is a hack but it's a potentially useful one. We can import it on an "experimental-emscripten" branch of the 5.2 develop branch and leave it in the repo like that for future reference. Then we can get started on the real 5.2 work.

Edit: sorry to bring this up again, if you work on Windows and/or OSX, then please help me with the port of the force feedback (haptics) to those platforms. I'll send you a free haptics enabled joystick for testing and to reward your efforts if you do. You could take a look at the SDL haptics implementation and adjust that to the Allegro internals and API requirements.

Arthur Kalliokoski
Second in Command
February 2005
avatar

I rebooted to Mint, FF28 worked ok (video noticeably choppy but not irritating, sound choppy, 30'ish FPS, used about 20Mb memory), then I tried Chrome 34. Chrome took a minute to actually start downloading, then the download rate became rather sparse and erratic. I noticed both cores were just about maxed out, one was Chrome itself and the other didn't associate to a process so it was some kernel thing. Killing Chrome left one core still grinding, killing FF brought CPU down to normal. Then starting up Chrome to try it without FF running brought up a "He's dead, Jim" out of memory error even though the system monitor thing said I was only using ~1 of the 2 gigs memory I have. I tried it one more time in FF without Chrome and the CPU went back down to normal after closing the skater tab.

TL;DR Chrome ran out of memory.

“Throughout history, poverty is the normal condition of man. Advances which permit this norm to be exceeded — here and there, now and then — are the work of an extremely small minority, frequently despised, often condemned, and almost always opposed by all right-thinking people. Whenever this tiny minority is kept from creating, or (as sometimes happens) is driven out of a society, the people then slip back into abject poverty. This is known as "bad luck.”

― Robert A. Heinlein

Max Savenkov
Member #4,613
May 2004
avatar

My GameJamGAMM entry. It's yet in early stage (as of 24.04.14), and there is not much gameplay :)

Also, I've hit a bug with TTF handling (different font sizes do not seem to work and the last letter of text seems to be chopped of sometimes).

Development period ended, final build uploaded. Check it out! There are some bug already, but I hope nothing too critical... Developing an RPG in 7 days of which I had only 2 to work full-time was an... interesting exercise. I do not have hight hopes of winning (other projects offer much better visuals, at least, and far more casual-friendly gameplay; I might overdid hardcore a bit, or, to say the truth, borked up the balance some), but it's all right. At least, I have tested some of my gameplay ideas. Next week: back to Allegro Emscripten development!

A small update: With help from FreeType and Emscripten developers, I have found a fix for error in drawing TTF fonts. This is a problem with FreeType which was found about a year ago (function signatures do not match, but C compiler allows this; Emscripten, not so much), but still hasn't been fixed in current version. It's quite easy to fix with a simple patch. Which means I can continue my work on the rest of the port.

 1   2   3 


Go to: