109
edits
User:Joel Reymont/Android Notes: Difference between revisions
→Android Notes
Joel Reymont (talk | contribs) |
Joel Reymont (talk | contribs) |
||
| Line 10: | Line 10: | ||
= Android Notes = | = Android Notes = | ||
== Drawing and input from native code == | |||
Via Jack Palevich... | |||
Input is done by subclassing a view, and override the various input methods. Make sure your view can get focus, using setFocusableInTouchMode(true);
Otherwise you won't get input events. You could use any View class as your base class, but I suggest that you subclass GLSurfaceView because that makes it easier to use OpenGL graphics for drawing. | |||
Probably the fastest way to get output from native code is done using OpenGL ES, which is newly available in NDK 1.6. Create a texture the size of the
screen ( it has to be a power of two on each side, so 512 x 256 if your screen is 320 x 240.) Then update the texture and render it to the screen as a screen aligned quad. | |||
For native OpenGL ES APIs the drawing surface is implicit in the thread. For Quake, GLSurfaceView's rendering thread sets up the context and calls the | |||
QuakeView's Renderer, which calls the native code, which makes the native GL calls. | |||
Because the context is implicit in the thread, there's nothing that needs to be passed between Java and native code. | |||
The downside of this approach is that you can't wrap the native GL calls as easily as you can wrap the JSR 239 Java OpenGL APIs. It's sometimes useful | |||
to wrap the GL APIs to keep track of the matrix stack, or log debugging messages, or check for error messages. | |||
== Building Android on Snow Leopard == | == Building Android on Snow Leopard == | ||