Just wondering why not android.opengl.GLSurfaceView

[Ted Malaska]

Just wondering, what are the main differences from the
com.replica.replicaisland.GLSurfaceView and the
android.opengl.GLSurfaceView.

Why would I use one or the other?

[James Luzwick]

Chris talks about this in the Javadoc of his GLSurfaceView class.  Here is a snippet of what he says.

"Typically you use GLSurfaceView by subclassing it and overriding one or more of the View system input event methods. If your application does not need to override event methods then GLSurfaceView can be used as-is. For the most part GLSurfaceView behavior is customized by calling "set" methods rather than by subclassing. For example, unlike a regular View, drawing is delegated to a separate Renderer object which is registered with the GLSurfaceView using the {@link #setRenderer(Renderer)} call."

He might also refer to this decision in a blog post, I forgot if he did or not.

-Jim

[Bart Hirst]

I think he also discusses this on the Google I/O Presentation

[Chris Pruett]

Basically, I hacked up the original GLSurfaceView to solve a very specific problem: I wanted to go to different Activities within my app without throwing all of my OpenGL state away.  The major change was to separate the EGLSurface from the EGLContext, and to throw the former away onPause(), but preserve the latter until the context is explicitly lost.  The default implementation of GLSurfaceView (which I didn't write, by the way), throws all GL state away when the activity is paused, and calls onSurfaceCreated() when it is resumed.  That meant that, when a dialog box popped up in my game, closing it incurred a delay because all the textures had to be reloaded.  

You should use the default GLSurfaceView.  If you must have the same functionality that mine has, you can look at mine.  But doing what I did exposed all sorts of awful driver bugs in some handsets (see the very long comments near the end of that file), and you can avoid all that mess by just using the default one.

Chris

[Ted Malaska]

thanks for the response.

ok one more question. I see you used PNG image format. When I save
an image in gimp as PNG the image doesn't render on my droid. I'm
guessing this has to do with compression.

So my question to you is what tool did you save your images in and if
it was gimp how do I save the images so they'll work for the droid?

Thanks

[Bart Hirst]

I had a similar problem here.  Make sure your PNG's are powers-of-2 pixels on each side.

[Ted Malaska]

Crazy, I just figured it out. This may be common knowledge to a
opengl guy buy this is my first time with opengl.

The images have to be the right dimensions or they don't work on the
droid.

Like 16x16, 32x32, and 512x512 work. But 24x24 and 320x480 don't.

Can some one enlighten me on why this is?

Thanks

[Chris Pruett]

As Bart says, the dimensions of each side of every image must be a
power of 2. 16, 32, 64, 128, 256, 512, 1024, etc. Those that are not
might render (it's up to the driver what to do in that case) or might
fail. So make them all sized correctly and you should be good.

Chris