meta user
network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 10 months |
| seen | May 18 at 16:20 | |
| stats | profile views | 8 |
|
May 18 |
awarded | Analytical |
|
May 18 |
awarded | Informed |
|
May 16 |
answered | Android game loop's effect on cpu/battery usage - unexpected results |
|
May 16 |
answered | Android Loop : Draw Loop : How to pull off smooth FPS? |
|
May 3 |
comment |
Formula for converting ratio of current device to target device You can see it in a GLSurfaceView implementation here; it's essentially the same computation, but not as concise: code.google.com/p/android-breakout/source/browse/src/com/… |
|
Apr 24 |
comment |
Where to run logic update in openGL ES? Example of a game that uses this structure: code.google.com/p/android-breakout . Some discussion about the one-vs-two thread approaches is in the supporting docs, and also here: stackoverflow.com/questions/14077403/… |
|
Feb 1 |
comment |
Limited Screen Switching Count Memory Issue On the Dalvik VM side, garbage is discarded when necessary. Manually invoking the GC isn't necessary for correctness. The only time it's really useful to do so is to control the timing of GC pauses. |
|
Jan 30 |
comment |
Limited Screen Switching Count Memory Issue The "force close" dialog is generally put up by the failing app itself, when a Java-language exception lands in the global default uncaught exception handler. In the event of a native crash, that's not possible and the app just disappears, but you will get a full crash trace in "logcat". Watch the logcat output as it scrolls by, and capture just the part that begins when you start the last screen transition before the crash and stops after the process is dead. The native stack backtrace may give you some idea of where things are going wrong. |
|
Jan 29 |
comment |
Limited Screen Switching Count Memory Issue Your logcat output appears incomplete. For example, in the first one, it shows the tail end of an exception in process 11707, then some GC logs from 12963. The second shows some GC logs from 13772. None of the GC messages indicate any sort of failure or problem -- those are normal messages from a Dalvik VM. There is no indication that you're running out of memory in the logs. The native crash in the 3rd set of output is interesting but you didn't include any of the registers or call stack. |
|
Jan 23 |
answered | Android OpenGL ES RENDERMODE_WHEN_DIRTY implementation |
|
Jan 23 |
comment |
How to dispose of OpenGL resources cleanly on Android If you're using GLSurfaceView, you don't really need to do anything -- it does it all for you. It actually discards everything whenever the activity is paused, which is good to know when figuring out where to allocate stuff, i.e. you want to create all your GL programs in onSurfaceCreated(). See code.google.com/p/android-breakout for an example. |
|
Jan 8 |
awarded | Teacher |
|
Jan 8 |
answered | Code structure in Android 2D game |
|
Dec 14 |
comment |
Which version of OpenGL for Android? An Android implementation of Breakout, developed specifically as an example of using OpenGL ES 2.0 for a 2D game: code.google.com/p/android-breakout |
|
Jul 23 |
awarded | Supporter |
