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

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Sun 15 Jun 2014 12:09:50 PM Max Savenkov wrote:
> I've done more profiling with debugging and profiling information
> enabled (-g4 -profile), and I'm positive that the main culprit is
> Primitives addon. You see, every time we use vertex array, Emscripten's
> OpenGL ES 2 emulation has to create a temporary vertex buffer (and then
> dispose of it). The main rendering code, which draws bitmaps, uses just
> one big vertex array, and therefore emulation has a small impact on
> performance. But take a look at GameDraw in game.c: it calls
> al_draw_prim many, many times every frame. For every such call,
> emulation layer has to create a vertex buffer and copy data from vertex
> array into it. The worst part is the code that draws water, but Skater
> uses Primitives extensively. So I think it is not a very representative
> code.
> 
> I can run some synthetic test later tomorrow to see how much primitives
> and bitmaps we can draw before noticeable drop in FPS on my machine (I
> have and older Core i7 CPU and GeForce 560 GPU, so it's moderately
> powerful, even though it's already 3 years old). But I really would
> appreciate if someone could compile a game that uses bitmaps exclusively
> and see how its performance goes. If bitmaps' performance is acceptable,
> then it is possible to create high-performance games with JavaScript
> port by avoiding plain Primitives functions (but you can use versions
> that take a pre-created Vertex Buffer, I guess; that should be VERY
> effective).
> 
> I understand the concern about adding a new platform which will have to
> be tested and supported. Then again, if it leads to more users and/or
> contributors for Allegro, it could worth everyone's while. But only time
> can show if this is true. The problem is, if this port will only be
> available on my site (which gets about 5 hits a day), it will surely
> stagnate and die. I would accept the idea of JavaScript port being a
> separate entity (at least for now, until it proves to be (un)popular)
> and me being the only maintainer, but I would like it to get some
> exposure, to lure potential users and contributors. So if it is decided
> not to include my port into the main repo, could it at least get a
> visible link on Allegro sites?

I'm personally in favor of it so long as we have a maintainer for it long 
term. I think ports are good to have, but if they are without a maintainer for 
a major release or two, they should be pulled.

> 15.06.2014 0:26, Daniel Leslie ?????:
> > I just profiled this on my sluggish laptop, an older E350 machine, and
> > nailed around 8fps on average.
> > 
> > I'm not too familiar with profiling HTML5, but the main culprits
> > appear to be:
> > 
> > 56% in WCF__flushMessageQueue()
> > This is an internal, and only around 1% was lost to call-outs. My
> > uneducated guess is that there's a /tonne/ of message handlers
> > registered that it's iterating through, or an equally enormous amount
> > of unhandled messages.
> > 
> > 16% in _glDrawArrays()
> > This is in skater_r.js.
> > 
> > -Dan
> > 
> > 
> > On Sat, Jun 14, 2014 at 12:32 PM, <beoran@xxxxxxxxxx
> > 
> > <mailto:beoran@xxxxxxxxxx>> wrote:
> >     This is a very nice beginning. I am in favour of already adding this
> >     to the development branch of allegro, or to a separate branch, to keep
> >     Max's good work safer from getting lost.
> >     
> >     On 6/14/14, Max Savenkov <max.savenkov@xxxxxxxxxx
> >     
> >     <mailto:max.savenkov@xxxxxxxxxx>> 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.
> >     > 
> >     > Downloads & Further info:
> >     
> >     > Pre-compiled version:
> >     http://zxstudio.org/projects/allegro/emscripten/allegro-git-ems-bin.zi
> >     p
> >     
> >     > Modified sources:
> >     http://zxstudio.org/projects/allegro/emscripten/allegro-git-ems-src.zi
> >     p
> >     
> >     > (Some) compiled dependencies:
> >     http://zxstudio.org/projects/allegro/emscripten/allegro-git-ems-deps.z
> >     ip
> >     
> >     > Skater example:
> >     http://zxstudio.org/projects/allegro/skater/skater_r.html
> >     
> >     > Release post:
> >     http://zxstudio.org/blog/2014/06/14/testing-release-allegro-javascript
> >     -port-emscripten/>     
> >     > Porting your Allegro game to JavaScript with Emscripten:
> >     http://zxstudio.org/blog/2014/06/14/porting-allegro-game-javascript-em
> >     scripten/
> >     
> >     
> >     ----------------------------------------------------------------------
> >     -------- 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
> > 
> > --------------------------------------------------------------------------
> > ---- 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

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx