Re: [AD] [AL] Some questions about Allegro graphics code.

[Replying to the alleg-developers list, not sure alleg-main is still active]

On Thu, Apr 17, 2014 at 8:27 AM, MaxEd <max.savenkov@xxxxxxxxxx> wrote:

|As some of you may know from forums, I've been working on making
Allegro work in browser by compiling it to _javascript_ with Emscripten. I
had some success and got Skater demo running, but there are a few things
in Allegro code that I had to prop up with crutches to make this work,
and I lack deeper knowledge about Allegro/OpenGL to fix them. So, if I
would be very grateful if someone could enlighten me on the following
points:

1) Default shader: when I look at the code for al_create_display, I see
that we first create backbuffer, then set it as target bitmap, and only
after it create default shader. This seems strange to me, because in the
end, we get backbuffer without attached shader (a shader is attached to
bitmap in set_target_bitmap). Because of this, graphics do not work at
all in browser, unless I call al_set_target_bitmap( al_get_backbuffer(
pDisplay) ); manually after creating display. Am I missing something
here? I do not understand why does this works on other platforms. The
only clue I have is that WebGL (browser's subset of OpenGL ES2) do not
support anything but programmable pipeline, so maybe it's the only
platform that REQUIRES backbuffer to have a shader? In that case, what
would be a proper fix to make Allegro set shader for backbuffer when
compiling with Emscripten?

Creation of the shaders was introduced in this patch by SiegeLord:

http://sourceforge.net/p/alleg/allegro/ci/db20612ef1132d18b36450ddd05a803cc519e1a0/#diff-9

I assume he simply forgot to add a call to al_use_shader. So yes, this needs to be fixed on all platforms. (Originally shaders were only an addon and al_create_display would not create them at all but the user did.)

2) As I mentioned above, WebGL is a subset of OpenGL ES 2 that only
supports programmable pipeline. It does not even HAVE fixed pipeline
functions, they are all missing symbols. Also, it does not support
drawing graphics via vertex arrays, only VBOs. Allegro, however, do not
use VBOs in OpenGL ES branch of code, even when programmable pipeline
(meaning ES2) is enabled. Fortunately, Emscripten provides emulation for
ES2 features missing from WebGL, so I can compile and run Allegro-based
programs. Unfortunately, that emulation comes with a performance
penalty. I do not have enough experience with OpenGL to write a new
branch of code specifically for Emscripten/WebGL with VBOs, and what's
more, I don't really want to make ogl_flush_vertex_cache any more
complex... So I am looking for an advice on what to do here (simple
using desktop OpenGL's branch does not work too).

The same is true for all OpenGL ES 2 ports, i.e. also Android and IOS (except those also have ES1 versions). I seem to remember adding VBOs myself at some point for ES2 - but I don't remember if that was ever committed or maybe reverted again.

How much is the performance penalty? I would assume it would be no bigger than if we "emulate" those features outselves.

Otherwise, I see no problem with having WebGL specific code paths.

3) Because _javascript_ lacks threads, I had to write a "thread emulator"
to make sound and timers code work. It simply runs thread's function at
the beginning of each frame, before the main program's function is run.
This means that I can't write endless loops inside thread functions, but
instead I should make them re-entrable in the sense that they should
store their persistent state elsewhere and not in local scope. So I had
to rewrite some functions in this way:

...

Will this be acceptable if I ever want for my code to be incorporated
into main Allegro codebase, or should I do it in some other way, like
writing separate functions for Emscripten (this will lead to code
duplication, but would make it somewhat easier to read that this
#ifdef-plagued monstroisity)? I've heard rumors that Mozilla wants to
enabled some kind of threading (not WebWorkers) in Emscripten, but I
can't imagine how they are going to do it... Until then, there is no
other way to emulate threaded code.

Hm, which functions in particular are affected? It might be cleaner splitting those into more sub functions and having one loop for each. So like:

#ifdef ALLEGRO_EMSCRIPTEN
void some_thread_func( ALLEGRO_THREAD *thread, void *arg )
{
while( al_get_next_event( &someQueue, &event ) ) {

some_sub_func();

}
}

#else
void some_thread_func( ALLEGRO_THREAD *thread, void *arg )
{
while( !threadStop ) {

some_sub_func();

}
}

#endif

That way there's less #defines scattered around. It depends a lot on the actual code though, so I don't know. Really would need to see your actual patch. I'm also not 100% sure I understand how exactly your events work without threads in the first place. In general, I do think this is acceptable though, I never thought we should rely on threads.

However, if Emscripten will implement C11 threads or pthreads in the near future, maybe worth waiting for that instead? But then, I think it's good to not delay things. And unlike the IOS or Android ports, an emscripten port would be very easy to run and debug by anyone, so I can see it being maintained and improved over time.