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

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


Primitives is in an addon and bitmap drawing is in core, so at the least
it would require some extra infrastructure. SiegeLord probably knows more
about it than anyone else.

Thanks,
Trent

On Mon, June 16, 2014 12:37 pm, Max Savenkov wrote:
> 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
>> <mailto: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
>>     <mailto: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
>>         <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.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
>>
>>
>
> ------------------------------------------------------------------------------
> 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







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