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