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

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


Could Primitives addon use the same VBO we use for bitmaps rendering? We could stuff all primitives into it and draw them all in the same call as bitmaps, which would get rid of both allocations and multiple calls to drawBuffers. I'm not an OpenGL expert, but this should work, shouldn't it?

16.06.2014 15:17, Trent Gamblin пишет:

On top of that, the problem with primitives still needs to be fixed, now that we’re relatively sure that’s what slows Skater down.

 

Thanks,

Trent

 

From: Trent Gamblin [mailto:trent@xxxxxxxxxx]
Sent: June 16, 2014 5:04 AM
To: 'Allegro Development'
Subject: Re: [AD] Allegro _javascript_ port using Emscripten (First version complete)

 

It’s nice that everybody is all for adding it, but no good that nobody wants to maintain it. Nobody is even willing to check the patch so until someone steps up to do that and someone also steps up to maintain the port long term, it shouldn’t be added.

 

Thanks,

Trent

 

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

 

I've compiled Cosmic Protector. I get steady 60 FPS with it. Check it out here:

Profiling version with debug info: http://zxstudio.org/projects/allegro/cosmic_protector/cosmic_protector_p.html
Optimized version: http://zxstudio.org/projects/allegro/cosmic_protector/cosmic_protector_r.html

I had to rip out main menu (because it had nested endless loops I had no patience for right now), but the rest of code is unmodified save for the FPS counter.

re: maintainer: in short term, I'm, of course, can be a maintainer for this port. In longer term, I'm not a "library" kind of guy, though, I much prefer working on games than on middleware (unlike lots of programmers I know, who could spend years polishing an engine or GUI library without ever finishing, or even starting a game). I can try to stick around for longer (I never was a maintainer for a part of open-source project before, so I don't know I have persistence).

15.06.2014 16:26, Trent Gamblin пишет:

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



 



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

 

 



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