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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Try compiling Cosmic Protector, it doesn’t use primitives for drawing.

 

Thanks,

Trent

 

From: Max Savenkov [mailto:max.savenkov@xxxxxxxxxx]
Sent: June 15, 2014 2:10 AM
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Allegro _javascript_ port using Emscripten (First version complete)

 

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?

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> 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> 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.zip
>
> Modified sources:
> http://zxstudio.org/projects/allegro/emscripten/allegro-git-ems-src.zip
>
> (Some) compiled dependencies:
> http://zxstudio.org/projects/allegro/emscripten/allegro-git-ems-deps.zip
>
> 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_-emscripten/
>

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



 



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/