31
General discussions / SFML Mobile Issues
« on: May 25, 2013, 06:46:27 pm »
Hi Laurent (and others). Sonkun and I have been working on an Android port of SFML, and some of the issues we're seeing are going to be issues for iOS as well, so I thought we could at least talk about them to try and figure out a good direction to take.
First, OpenGL ES does not support redering quads (only triangles, lines, and points). This requires the vertex buffers for sprites to be different. For individual sprites (where only one quad is drawn per draw call), a triangle strip can easily be used without increasing memory consumption. For "grouped" sprites (where multiple quads are drawn in a single draw call, like sf::Text), GL_TRIANGLES will have to be used. Would you prefer to continue using glDrawArrays, or would you prefer to optionally switch to glDrawElements and use indexed draw arrays? I'm assuming you'll want to stick with glDrawArrays (I think it'll save 8 bytes per quad), but I wanted to try and get your (and others) input.
I thought I had more things to bring up, but I can't think of anything else. If I do, I'll post here. I know I and others are eager to contribute to SFML, and hopefully this will help us better collaborate.
First, OpenGL ES does not support redering quads (only triangles, lines, and points). This requires the vertex buffers for sprites to be different. For individual sprites (where only one quad is drawn per draw call), a triangle strip can easily be used without increasing memory consumption. For "grouped" sprites (where multiple quads are drawn in a single draw call, like sf::Text), GL_TRIANGLES will have to be used. Would you prefer to continue using glDrawArrays, or would you prefer to optionally switch to glDrawElements and use indexed draw arrays? I'm assuming you'll want to stick with glDrawArrays (I think it'll save 8 bytes per quad), but I wanted to try and get your (and others) input.
I thought I had more things to bring up, but I can't think of anything else. If I do, I'll post here. I know I and others are eager to contribute to SFML, and hopefully this will help us better collaborate.