I don't think more than 2 phones had issues with VBOs and I believe
they have been resolved (at least the Cliq problem was resolved.) I
think they are safe to use unless reported otherwise and then you
could just check the model of phone and not use them on that one
device. It's easy to write a model data class that holds buffers and
is responsible for loading VBOs and binding to buffers or VBO ids and
drawing. I do that.
To determine if a device has VBO support, you have to parse the GL
version string and if it's 1.1 or greater or there exists
vertex_buffer_object extension, you can use them, unless it's an
original model of CLIQ, but those have been updated so you maybe don't
need to worry about it.
I still have bad touch lag problems on 1.5/1.6 but they are resolved
in 2.x. I do Thread.sleep(20) at the end of my onTouchEvent but it
doesn't help as much as I'd like it to. I still get a bad FPS drop.
I use javax.math.Vector3f all over the place. I never allocate in
main loop code, though. If a class requires vector math, I usually
instantiate a few aux vectors like this:
private Vector3f vAux1 = new Vector3f();
private Vector3f vAux2 = new Vector3f();
public boolean checkSomeCollision(Sphere s, AABB box) {
Vector3f direction = vAux1;
direction.set(...
direction.sub(...
I have a robust system in now and have found that just a few aux
vectors works with any collision detection or physics algorithm I've
used so far. You don't need a fancy pooling solution and in fact, one
would most likely require more cycles to work with and manage, but if
you really want efficient code you'll have to move it into native
anyway and then you get the luxury of a vector struct and operator
overloading which makes the code a lot easier to work with.
On Jan 15, 12:17 pm, Michael <[email protected]> wrote:
> Hi Guys,
>
> That's a nice list Philip. Just a couple of questions about it.
>
> When you say RBGA_8888 and ALPHA_8 are you talking about the pixel
> format of the gl context? What is the benefit of one over the other?
>
> I had input problems until I put a wait in my onTouchEvent, but I was
> wondering how the notify in onDraw helps?
>
> What do you mean by the on demand drawing?
>
> I had great trouble trying to get a stable frame rate even with all
> the things listed, but my problems appeared to have been caused in
> part by the rotation bug in 1.5. I occasionally got a good frame rate,
> but then other times didn't. That's one reason I started using VBO's,
> just to speed things up. As soon as I got 1.6 I could easily get a
> decent frame rate.
>
> It sounds like VBO's are broken on a lot of the newer phones so maybe
> I should pull them out and see how it runs. With a bit of tweaking I
> should be able to switch VBO's on and off in my code easily, so maybe
> I could target individual phones if they really help with performance.
>
> My code currently doesn't use Vector objects due to the gc involved
> when they are created and destroyed. Anyone found a nice way of
> getting round that?
>
> Cheers,
> Mike
>
> On Jan 14, 11:34 pm, Philip <[email protected]> wrote:
>
>
>
> > My experience so far:
> > - Create your textures in power of two and make sure you scale and
> > clip them to the right ratio when you draw.
> > - Don't stick to RBGA_8888 when you can do ALPHA_8 (text rendering)
> > - Do whatever you can do in OnSurfaceCreated before you get called in
> > OnSurfaceDraw
> > - Avoid the GL11 context cast. Some things won't work e.g glColor4ub
> > will compile but not work.
> > - Balance your calls of enable and disable for each component draw
> > your call into your scene graph.
> > - Pre-allocate your nio buffers
> > - Use DrawElements but for the simplest shapes of one vertice
> > - Test on as many devices as you can. Just don't settle for the
> > emulator e.g. non power of twos work on emulator but not on the phone.
> > - If you can then use the on demand drawing.
> > - Use the trick of putting a wait in the onTouchEvent call for 20ms
> > and a notify in your onDraw to reduce the deluge of motion events you
> > have to process. You can bypass onTouchEven and use a lower call to
> > save some cycles as well.
> > - Use texture atlas as much as you can e.g. to draw score and text or
> > animations
> > - Disable the fancy rendering options (DITHER_TEST etc...) Unless you
> > crave a realistic rendering on textures.
> > - If you draw in 2D, then disable the DEPTH_TEST
> > - Don't forget the Bitmap.recycle() call when you are done binding
> > your textures.
> > - Avoid Object creation destruction (PointF Rect) in your rendering
> > routines. GC calls will slow down your frame rate.
> > - Preload your textures extensively. don't wait until you draw at the
> > last minute to bind your textures. The lag is noticable if you do so
> > it's better at app start up time.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
