OpenGL ES: Using Shortlike Datatype for UVCoords

AnotherJake Wrote:Also, at least for my 2D stuff, transforming on the CPU doesn't seem to be any different in performance than via the GL, except that batching seems to help, which of course requires CPU transforms.

If by 2D you mean drawing individual quads then no, messing with a matrix is not going to be much different in performance than transforming 4 individual 2 component vertexes. And 2D stuff usually has a few large polygons meaning that you have a much lower vertex to fragment ratio.

Haha, so true! By my way of roughly judging at least the first gen iPod Touch, it's somewhat similar in capabilities to what I recall my old 300 MHz Blue & White G3 with Rage 128 was like. So that was like losing about 10 years of computing power by stepping into the iPhone era.

I wouldn't bother with lookup tables or even worrying about doing too much trig - these devices seem to handle floating point math/trig just fine (or at least within reason - just remember they aren't desktop machines).

Anyone seeing slowdowns really needs to do some profiling. There are plenty of dumb things you can do to botch your FPS that are easy to fix, once you know where to look.

Frank C. Wrote:VBOs work with GLES 1.1 as far as I can tell, but they don't actually do much if anything on the iPhone (vanilla vertex array perform just as well). Not sure how much they help on GLES 2.

AnotherJake Wrote:My VBO code works on ES 1.1 but has never appeared to actually do anything.

longjumper Wrote:The performance of VBOs was bad on 1.1, I don't think there was any performance benefit over vertex arrays.

This is not a distinction between ES1 and ES2.

It is a distinction between MBX and SGX. VBOs will provide a performance win in either ES1 or ES2, on SGX.

Well thanks for the VBO clarification, as it is, I guess I'm not using them for now.

There is a huge speedup that I can still get from just changing the part of the interleaved array that really changed (like one floortile changed its color) and not redoing the whole array everytime something moved on the map.
I just have to be very careful about bugs there.

Also I wanted to remind you that I like to do 3D and not 2D so I'm not disagreeing with Skorche but stating that I have a different use-case in mind. My Game could be done in isometric style but I really came to like the way one is able to move the camera freely. I also didn't want to do another game using nicely drawn 2D-Sprites but use detailed 3D Models of units.
In the beginning I had some concerns about the Animation of anything in the geometry becoming very complex but the experience showed animation isn't really necessary. Its not supposed to be simulation of some real battlefield but a hex-based Boardgame with stiff units.

Well that was ok, but I had hardcoded the stride where I used vDSP to translate objects around. Since I changed the size, the stride changed to, so now I use

Code:

int stride = sizeof(iVertex3D)/sizeof(float);

Sadly, the change to short instead of float for uv only changed the size of iVertex3D from 36 to 32 and this only changed the performance by less then 10%.
To be more exact (maximum fps is 30, i capped it there to reduce battery consumption)

drawing 8000 vertices, FPS went up from 27 to 30

drawing 19000 vertices, FPS went up from 9.8 to 9,9

All my tests suggest, that once I draw more then about 15000 vertices, my FPS really begin to drop, especially with AA switched on. Below that border, switching AA off or on doesn't have any impact on fps.
So from this test I conclude the problem, that I face above 15k vertices, isn't connected to array size.

EDIT: Changing the type of the normals in iVertex3D to "short" did change FPS significantly,
it improved the fps for 19000 vertices from 9.9 to 14.5. Sadly it only moved the border up a little bit, at which I'm starting to draw at 9 fps, the border now seems to be around 21000 vertices.
EDIT2: Interestingly, once it crosses the border and drops to 9. fps, it doesn't really get worse. I can draw 27500 vertices at 9.5 fps too.

(Jul 19, 2010 10:39 PM)proximityinfotech3 Wrote: But what I don't get now is how to short the normals.
My biggest absolute value in any direction is 16, so since I have 32768 integers in the short-type , I multiply my vertex-coordinate-floats by 2048 and save them as shorts.

You probably want

Code:

glEnable(GL_NORMALIZE);

switched on. Since only the direction of normals is necessary and it would be unnaturally light in certain directions with normals longer than 1.