| Re: [AD] Usage of OpenGL buffers in main library and Primitives addon |
[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]
I'm continuing my port of Allegro to _javascript_ via Emscripten, and
ran into the following problem: WebGL does not support drawArrays and
drawElements with client data. Instead, you're supposed to always use
Vertex Buffer Objects and Index Buffer Objects.
Emscripten, a C++-to-_javascript_ toolchain, however includes emulation
for old way of doing things. It requires compilation with an
additional key and also lowers performance, but not in case of
Allegro, because Allegro can't really use VBOs and IBOs efficiently
with the current architecture.
It was easy enough to make Allegro use VBO in the main part of library
for WebGL, but Primitives addon is another matter. It was not written
with VBO usage in mind, and IBO are even worse. At least, ogl_extras
contain a global reusable VBO, which could be bound and filled with
data when user hasn't provided his own vertex buffer. But there is no
such global IBO, so I can't port draw_indexed_prim_raw to WebGL so
easily. Also, using VBOs is problematic with custom vertex formats,
because I'm missing some of needed information inside setup_state and
information about vertex format size outside it.
I'm unsure how to proceed here. On the one hand, I can just leave
things as they are. Then, all Allegro-based projects would require -s
FULL_ES2=1 compilation key. There is not a performance cost as far as
I can see, but I feel this approach to be inelegant, and also if
emulation code is ever removed or changed in Emscripten, Allegro users
will be out of luck.
On the other hand, I'm not prepared to take full responsibility for
re-engineering a part of Primitives addon, especially since I'm no
expert in OpenGL at all. It does not seem like a very complex problem
at the first glance, but I will need to decide where to create, store
and destroy Index Buffer Objects for indexed functions and how to
upload data for custom vertex formats. And carefully place #ifdefs as
to separate all that new code from parts that rely on fixed pipeline.
Should this code be WebGL specific, or used on all OpenGL ES2-like
platforms? So many questions to answer!
Anyway, I'm looking for a community guidance here. What should I do? I
would prefer to leave this problems for others and work instead on
parts of port that I feel more comfortable with, but then I will be
submitting an incomplete port later, which someone will have to fix,
and god knows how much time that will take, because it's not critical
presently.
| Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |