OpenGL ES: Using Shortlike Datatype for UVCoords

Sage
Posts: 1,482
Joined: 2002.09
Post: #16
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.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #17
Trig lookup tables and using the CPU to do the GPUs work... we've hit a development regression. Smile
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #18
Haha, so true! LOL 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.
Quote this message in a reply
Member
Posts: 446
Joined: 2002.09
Post: #19
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.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #20
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.
Quote this message in a reply
Member
Posts: 95
Joined: 2009.09
Post: #21
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.
Quote this message in a reply
Member
Posts: 95
Joined: 2009.09
Post: #22
Sorry to dig up an old thread, but I didn't want to start a second one on the same topic.
Since I'm really trying to maximize fps now, I am thinking about texture-coordinates as shorts/chars again.

Sadly it doesn't really work, I think I'm missing something.

I did:
  • change the interleaved array type to short
  • scale up the float * 1024 and floorf the result into a short (integer) when calling addVertex
  • glMatrixMode(GL_TEXTURE) and glScale (1/1024,....)
  • glTexCoordPointer(2, GL_SHORT, sizeof(iVertex3D), &_interleavedVerts[0].uv);
Do you see where I could have missed something while changing from float to short?
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #23
(Jul 17, 2010 11:54 AM)Bersaelor Wrote:  [*]glMatrixMode(GL_TEXTURE) and glScale (1/1024,....)

Are you actually using 1/1024 or 1.0f/1024.0f?
Quote this message in a reply
Member
Posts: 95
Joined: 2009.09
Post: #24
(Jul 17, 2010 12:07 PM)PowerMacX Wrote:  
(Jul 17, 2010 11:54 AM)Bersaelor Wrote:  [*]glMatrixMode(GL_TEXTURE) and glScale (1/1024,....)

Are you actually using 1/1024 or 1.0f/1024.0f?

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.
Quote this message in a reply
Member
Posts: 95
Joined: 2009.09
Post: #25
(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.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #26
(Jul 20, 2010 12:24 AM)Bersaelor Wrote:  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.

The post you responded to was a spam bot, a "smart" (read:annoying) one that copies previous posts.

In this case... it copied your own post from earlier in this same thread Rasp
http://www.idevgames.com/forums/thread-4...l#pid62990
Quote this message in a reply
Member
Posts: 227
Joined: 2008.08
Post: #27
Haha, made my day.
Quote this message in a reply
Member
Posts: 95
Joined: 2009.09
Post: #28
(Jul 20, 2010 06:41 PM)Oddity007 Wrote:  Haha, made my day.

Oooops, I answered my own post ? Wacko

So that is the result when you work till 2 am...
Quote this message in a reply
Post Reply