Re: [AD] Allegro JavaScript port using Emscripten (First version complete)

[Max Savenkov <max.savenkov@xxxxxxxxxx>]

> Either way, I'd prefer for this to be done without touching the core.

Well, we can have an independent VBO for primitives inside addon, I
guess. But I don't know if one will be enough, or if we need to have a
pool of them, or something.

> One part I don't understand are the changes to the audio addon. Why is
> the thread emulation you coded into the core not sufficient? What are
> the OpenAL changes for?

Thread emulation is not sufficient because I need to store per-thread
data to make streaming work. I'm not sure how to do it otherwise.
Actually, I think I can use my thread emulator there, but I will still
need an additional array to store streaming data.


> Additionally, the way you've done the time/timer etc (by literally
> copying files over) is just terrible. Can none of it be refactored to
> use the system driver abstraction?

I'll look into it. Maybe I was in too much of a hurry when I was doing it.


> In terms of the main loop... is there no main-addon-powered abstraction
> that can be made there? E.g. the Allegro main would register the thread
> emulator dispatch loop as the main loop which would then call the user
> main? Overall, even with this it's very sad that emscripten will force
> people to rewrite their code like that.

Oh, how I wish there was something to be done here! But I just don't
see the way presently. Registring a thread won't work. It will call
user's main EVERY FRAME, which is not at all what user expects.

Hmm... You know what? It seems like JavaScript has corutines. I missed
that feature when I was looking for it the last time, it seems. I'm
not sure if it can really help us here (may require a modification to
Emscripten itself, because it is not corutine-based), but I'll try to
see if I can make things better. Looking at
http://syzygy.st/javascript-coroutines/, I guess it'll have to work
something like this:

allegro_main()
{
    emscripten_set_main_loop( allegro_frame, 0, 1 );
}

ES_ASM( var main_corutine = create_corutine( _user_main ); ) // Here's
some magic, because we will have to guess JavaScript name of user_main
function to create a corutine from it (?)

allegro_frame()
{
    ES_ASM( main_corutine.send() );
}

void main() // renamed to user_main()
{
    while( true )
    {
          al_flip();
    }
}

void al_flip() // actually, in implementation, but for berevity, here
{
     ... do Allegro stuff
     ES_ASM( yield );
}

I'm writing this from work and have no way to test it right now (so
the code above probably doesn't even compile). I'll check it out when
I get home. The main problem I see is we will need to create corutine
from user's main function. But maybe we don't event need that, now
that I think about it! OK, I'm confused right now. I'll get back to
you when I have done some testing. If this works, it will simplify
things so greatly...

2014-06-18 1:57 GMT+04:00 SiegeLord <slabode@xxxxxxxxxx>:
> On 06/14/2014 05:11 AM, Max Savenkov wrote:
>> Here's a result of my work for the last two months: a port of Allegro
>> to JavaScript via Emscripten. Patch for the latest Git version is
>> attached. The port isn't fully complete, but it has most of
>> functionality working, so I decided to present it to community for
>> testing and to generate interest.
>
> One part I don't understand are the changes to the audio addon. Why is
> the thread emulation you coded into the core not sufficient? What are
> the OpenAL changes for?
>
> Additionally, the way you've done the time/timer etc (by literally
> copying files over) is just terrible. Can none of it be refactored to
> use the system driver abstraction?
>
> In terms of the main loop... is there no main-addon-powered abstraction
> that can be made there? E.g. the Allegro main would register the thread
> emulator dispatch loop as the main loop which would then call the user
> main? Overall, even with this it's very sad that emscripten will force
> people to rewrite their code like that.
>
> These are just the first few things I noticed as I glanced at the code.
> As I have get more free time, I'll look over it some more.
>
> -SL
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers