[android-developers] Function inlining
Hi!
I recently wrote a quick test that does this:
private static int test_f(int i) { return i * 42; }
...
int z = 41;
for(int i = 0; i < 1; ++i) { z = z*42; } // this loop runs
in X seconds
for(int i = 0; i < 1; ++i) { z = test_f(z); }// this loop runs
in 10*X seconds
The results of this tests imples test_f() is not being inlined, even
though it really is a prime candidate for it. It should also be
possible to do this inlining at compile time.
There seems to be no option to control optimization level of the
compiler in Eclipse, perhaps optimizations like these are left to the
VM?
Does the Dalvik VM do inlining of functions at all, or did it just
decide to not inline this specific instance?
Curious to hear a response from someone more familiar with the Dalvik
VM than me.
Best regards,
Viktor Linder
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Re: Function inlining
Ok.
On a related note, has anyone used a preprocessor of some sort and
managed to integrate it with Eclipse?
Best regards,
Viktor Linder
On 7 Okt, 18:32, Romain Guy wrote:
> There's no inlining at the moment.
>
>
>
> On Wed, Oct 7, 2009 at 6:31 AM, Viktor Linder wrote:
>
> > Hi!
> > I recently wrote a quick test that does this:
>
> > private static int test_f(int i) { return i * 42; }
>
> > ...
>
> > int z = 41;
> > for(int i = 0; i < 1; ++i) { z = z*42; } // this loop runs
> > in X seconds
> > for(int i = 0; i < 1; ++i) { z = test_f(z); } // this loop runs
> > in 10*X seconds
>
> > The results of this tests imples test_f() is not being inlined, even
> > though it really is a prime candidate for it. It should also be
> > possible to do this inlining at compile time.
>
> > There seems to be no option to control optimization level of the
> > compiler in Eclipse, perhaps optimizations like these are left to the
> > VM?
>
> > Does the Dalvik VM do inlining of functions at all, or did it just
> > decide to not inline this specific instance?
>
> > Curious to hear a response from someone more familiar with the Dalvik
> > VM than me.
>
> > Best regards,
> > Viktor Linder
>
> --
> Romain Guy
> Android framework engineer
> romain...@android.com
>
> Note: please don't send private questions to me, as I don't have time
> to provide private support. All such questions should be posted on
> public forums, where I and others can see and answer them
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~--~~~~--~~--~--~---
[android-developers] Creating 5:6:5 PNGs?
Does anyone know of a tool (preferably free/open source) for converting 24-bit PNGs to 16-bit? I have searched around a bit and it seems like PNG perhaps does not support 16-bit modes. If so, how do you package your textures to minimize load-time processing? All answers appreciated! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Crash in glDrawElements() using VBOs just after glBufferData()
I am having trouble with implementing VBOs for my game.
I get crashes at random when calling glDrawElements() directly after
glGenBuffers() / glBufferData().
The crashes disappear when I add printouts which leads me to believe
it might be a race condition between glBufferData() and
glDrawElements() of some sort.
Or I am doing something else that breaks it, but I can't see what.
Here's what I do:
...
gl.glEnableClientState(GL10.GL_VERTEX_ARRAY);
gl.glEnableClientState(GL10.GL_TEXTURE_COORD_ARRAY);
...
if(geometry not in cache) {
gl11.glGenBuffers(1, _temp_handle, 0);
_geo_id = _temp_handle[0];
// produce text geometry to scratch buffer (allocated with
ByteBuffer.allocateDirect())
int off = DynamicBuffer.allocate(_buf_size_floats);
TextProducer.create_geometry(_font, _text, DynamicBuffer._buffer,
off);
// upload geometry
gl11.glBindBuffer(GL11.GL_ARRAY_BUFFER, _geo_id);
DynamicBuffer._buffer.position(off);
gl11.glBufferData(GL11.GL_ARRAY_BUFFER, _buf_size_bytes,
DynamicBuffer._buffer, GL11.GL_STATIC_DRAW);
DynamicBuffer.deallocate_last(_buf_size_floats);
// set vertex pointer
gl11.glVertexPointer(3, GL10.GL_FLOAT, 0, 0);
gl11.glTexCoordPointer(2, GL10.GL_FLOAT, 0, _pos_size_bytes);
insert_in_cache();
} else {
... bind + set vertex pointer using existing VBO ...
}
...
gl.glDrawElements(); // <--- sometimes this call crashes, always after
buffer was just allocated/produced (ie the geometry-not-in-cache code
path)
...
gl.glDisableClientState(VERTEX...);
gl.glDisableClientState(TEXCOORD...);
Sometimes the call to glDrawElements() crashes. The crash only happens
when glDrawElements() is called right after the buffer has been
allocated and written (ie "geometry not in cache" is true).
The crash seems more common if the produced buffer is a few kb or more
in size.
If I insert a Log.d() call in between glVertexPointer3f() and
glDrawElements() the crash goes away.
I have double checked that the GL calls are not setting the error
flag, and I am not writing past any buffer limit or feeding incorrect
sizes etc to glBufferData(). Note that everything renders correctly
without artifacts up to the crash. The crash does not happen for the
same geometry all the time, a piece of geometry can be produced and
rendered correctly, then be re-produced and crash.
Before I make a minimal reproducible example, I thought I would ask
this group if anyone else
have experienced the same trouble when using a VBO right after call to
glBufferData()?
All answers appreciated!
/Viktor
PS.
This is the crash dump:
02-16 20:23:00.979: INFO/DEBUG(14143): *** *** *** *** *** *** *** ***
*** *** *** *** *** *** *** ***
02-16 20:23:00.979: INFO/DEBUG(14143): Build fingerprint: 'android-
devphone1/dream_devphone/dream/trout:1.6/DRC83/14721:user/gfh,test-
keys'
02-16 20:23:00.979: INFO/DEBUG(14143): pid: 17564, tid: 17580 >>>
com.mygame.mygame <<<
02-16 20:23:00.979: INFO/DEBUG(14143): signal 11 (SIGSEGV), fault addr
002df000
02-16 20:23:00.979: INFO/DEBUG(14143): r0 001b9c28 r1 002deff0 r2
0003 r3 001be178
02-16 20:23:00.979: INFO/DEBUG(14143): r4 002deff4 r5 001be17c r6
0044 r7 03ff
02-16 20:23:00.979: INFO/DEBUG(14143): r8 r9 001be170 10
0003 fp 001b9c14
02-16 20:23:00.979: INFO/DEBUG(14143): ip 0002 sp 44944d00 lr
8042b8dc pc 8043fdf8 cpsr 2010
02-16 20:23:02.669: INFO/DEBUG(14143): #00 pc 0003fdf8 /
system/lib/libhgl.so
02-16 20:23:02.669: INFO/DEBUG(14143): #01 lr 8042b8dc /
system/lib/libhgl.so
02-16 20:23:02.669: INFO/DEBUG(14143): stack:
02-16 20:23:02.679: INFO/DEBUG(14143): 44944cc0 000c
02-16 20:23:02.679: INFO/DEBUG(14143): 44944cc4 001b53d4 [heap]
02-16 20:23:02.679: INFO/DEBUG(14143): 44944cc8 001b39b0 [heap]
02-16 20:23:02.679: INFO/DEBUG(14143): 44944ccc 001b49b0 [heap]
02-16 20:23:02.679: INFO/DEBUG(14143): 44944cd0
02-16 20:23:02.679: INFO/DEBUG(14143): 44944cd4
02-16 20:23:02.679: INFO/DEBUG(14143): 44944cd8 001b3db0 [heap]
02-16 20:23:02.679: INFO/DEBUG(14143): 44944cdc 8043c1c0 /system/
lib/libhgl.so
02-16 20:23:02.679: INFO/DEBUG(14143): 44944ce0 001c3e78 [heap]
02-16 20:23:02.689: INFO/DEBUG(14143): 44944ce4 009c8330
02-16 20:23:02.689: INFO/DEBUG(14143): 44944ce8 001b9c08 [heap]
02-16 20:23:02.689: INFO/DEBUG(14143): 44944cec 001b39b0 [heap]
02-16 20:23:02.689: INFO/DEBUG(14143): 44944cf0 001b44ac [heap]
02-16 20:23:02.689: INFO/DEBUG(14143): 44944cf4 0005
02-16 20:23:02.689: INFO/DEBUG(14143): 44944cf8 df002777
02-16 20:23:02.689: INFO/DEBUG(14143): 44944cfc e3a070ad
02-16 20:23:02.689: INFO/DEBUG(14143): #00 44944d00 0400
02-16 20:23:02.689: INFO/DEBUG(14143): 44944d04 001c3e78 [heap]
02-16 20:23:02.699: INFO/DEBUG(14143): 44944d08 009cd330
02-16 20:23:02.699: INFO/DEBUG(14143): 44944d0c 001b9c08 [heap]
02-16 20:23:02.699: INFO/DEBUG(14143): 44944d10
[android-developers] Re: Crash in glDrawElements() using VBOs just after glBufferData()
S, vertexCount,
> GL10.GL_UNSIGNED_SHORT, 0);
> // clean up
> gl11.glBindBuffer(GL11.GL_ARRAY_BUFFER, 0);
> //gl11.glBindBuffer(GL11.GL_ELEMENT_ARRAY_BUFFER, 0);
>
> This code draws without indices but the commented code for indices is
> there.
> I use fixed point coordinates for verts, normals and UVs. You'd want
> to change that to floats for what you're doing.
>
> On Feb 16, 1:42 pm, Viktor Linder wrote:
>
> > I am having trouble with implementing VBOs for my game.
> > I get crashes at random when calling glDrawElements() directly after
> > glGenBuffers() / glBufferData().
> > The crashes disappear when I add printouts which leads me to believe
> > it might be a race condition between glBufferData() and
> > glDrawElements() of some sort.
> > Or I am doing something else that breaks it, but I can't see what.
>
> > Here's what I do:
>
> > ...
> > gl.glEnableClientState(GL10.GL_VERTEX_ARRAY);
> > gl.glEnableClientState(GL10.GL_TEXTURE_COORD_ARRAY);
> > ...
> > if(geometry not in cache) {
> > gl11.glGenBuffers(1, _temp_handle, 0);
> > _geo_id = _temp_handle[0];
>
> > // produce text geometry to scratch buffer (allocated with
> > ByteBuffer.allocateDirect())
> > int off = DynamicBuffer.allocate(_buf_size_floats);
> > TextProducer.create_geometry(_font, _text, DynamicBuffer._buffer,
> > off);
>
> > // upload geometry
> > gl11.glBindBuffer(GL11.GL_ARRAY_BUFFER, _geo_id);
>
> > DynamicBuffer._buffer.position(off);
> > gl11.glBufferData(GL11.GL_ARRAY_BUFFER, _buf_size_bytes,
> > DynamicBuffer._buffer, GL11.GL_STATIC_DRAW);
>
> > DynamicBuffer.deallocate_last(_buf_size_floats);
>
> > // set vertex pointer
> > gl11.glVertexPointer(3, GL10.GL_FLOAT, 0, 0);
> > gl11.glTexCoordPointer(2, GL10.GL_FLOAT, 0, _pos_size_bytes);
>
> > insert_in_cache();} else {
>
> > ... bind + set vertex pointer using existing VBO ...
>
> > }
>
> > ...
> > gl.glDrawElements(); // <--- sometimes this call crashes, always after
> > buffer was just allocated/produced (ie the geometry-not-in-cache code
> > path)
> > ...
>
> > gl.glDisableClientState(VERTEX...);
> > gl.glDisableClientState(TEXCOORD...);
>
> > Sometimes the call to glDrawElements() crashes. The crash only happens
> > when glDrawElements() is called right after the buffer has been
> > allocated and written (ie "geometry not in cache" is true).
> > The crash seems more common if the produced buffer is a few kb or more
> > in size.
> > If I insert a Log.d() call in between glVertexPointer3f() and
> > glDrawElements() the crash goes away.
>
> > I have double checked that the GL calls are not setting the error
> > flag, and I am not writing past any buffer limit or feeding incorrect
> > sizes etc to glBufferData(). Note that everything renders correctly
> > without artifacts up to the crash. The crash does not happen for the
> > same geometry all the time, a piece of geometry can be produced and
> > rendered correctly, then be re-produced and crash.
>
> > Before I make a minimal reproducible example, I thought I would ask
> > this group if anyone else
> > have experienced the same trouble when using a VBO right after call to
> > glBufferData()?
>
> > All answers appreciated!
> > /Viktor
>
> > PS.
> > This is the crash dump:
> > 02-16 20:23:00.979: INFO/DEBUG(14143): *** *** *** *** *** *** *** ***
> > *** *** *** *** *** *** *** ***
> > 02-16 20:23:00.979: INFO/DEBUG(14143): Build fingerprint: 'android-
> > devphone1/dream_devphone/dream/trout:1.6/DRC83/14721:user/gfh,test-
> > keys'
> > 02-16 20:23:00.979: INFO/DEBUG(14143): pid: 17564, tid: 17580 >>>
> > com.mygame.mygame <<<
> > 02-16 20:23:00.979: INFO/DEBUG(14143): signal 11 (SIGSEGV), fault addr
> > 002df000
> > 02-16 20:23:00.979: INFO/DEBUG(14143): r0 001b9c28 r1 002deff0 r2
> > 0003 r3 001be178
> > 02-16 20:23:00.979: INFO/DEBUG(14143): r4 002deff4 r5 001be17c r6
> > 0044 r7 03ff
> > 02-16 20:23:00.979: INFO/DEBUG(14143): r8 r9 001be170 10
> > 0003 fp 001b9c14
> > 02-16 20:23:00.979: INFO/DEBUG(14143): ip 0002 sp 44944d00 lr
> > 8042b8dc pc 8043fdf8 cpsr 2010
> > 02-16 20:23:02.669: INFO/DEBUG(14143): #00 pc 0003fdf8 /
> > system/lib/libhgl.so
> > 02-16 20:23:02.669: INFO/DEBUG(14143): #01 lr 8042b8dc /
> > system
[android-developers] Re: glDeleteBuffers crashes
I've also experienced this crash whenever calling glDeleteBuffers() on the emulator. On the phone (G1) it works. Since you seem to be doing dynamic geometry creation, it would be interesting to know if you also encounter this issue: http://groups.google.com/group/android-developers/browse_thread/thread/87827933dc7346c6 Best regards, Viktor Linder On 22 Feb, 22:20, Clankrieger wrote: > Hi, > > I tried to use VBO on 1.6 Android SDK and get a crash whenever I try > to give the VBO id free usingglDeleteBuffers. The issue has already > been filed here: > > http://code.google.com/p/android/issues/detail?id=4273 > > Is there any way of giving a VBO id free, then? Otherwise I'm afraid > that I can't use VBO because I might run out of graphics memory/buffer > IDs. > > Thanks! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: Crash in glDrawElements() using VBOs just after glBufferData()
To clarify, in the original example, no buffer is allocated. The call to "DynamicBuffer.allocate()" simply moves a position in a previously allocated buffer which is filled each frame - ie. an "arena allocator". DynamicBuffer.deallocate_last(size) simply moves the position back without destroying any memory. So it is not a gc issue. Also, while the buffer might get filled with "junk" it will still be valid floats of some sort, since the array is only written to from java. Best regards, Viktor Linder On 25 Feb, 20:08, Robert Green wrote: > Actually, let me clear something technical up. I just realized that > the OpenGL native side is using GetPrimitiveArrayCritical and not > GetDirectBufferAddress. I'm not sure why they decided to take that > route but I'm sure there was a good reason for it. The fact of the > matter is that while GPAC doesn't guarantee the actual array address > (it has the option to make a copy), it's most likely that it won't > make a copy and will instead hand over the actual array address. This > of course depends on the VM's implementation. The could have easily > implemented it to always use the actual address. Someone from that > camp would have to comment because I'm not going to dig through > Dalvik's source :) > > Read more about it > here:http://java.sun.com/j2se/1.3/docs/guide/jni/jni-12.html#GetPrimitiveA... > > That being said - all of what I talked about still stands. It's just > a different JNI function to get to it. > > On Feb 25, 12:39 pm, Robert Green wrote: > > > Let me explain something. Using directly allocated NIO buffers is a > > DIRECT LINK between Java and native. The pointer you get from (void > > *)GetDirectBufferAddress points to the exact memory that the Java > > buffer is using. The memory is not managed in Java on the heap like > > everything else. This is one of the few cases where you can write to > > natively accessible code that does not need to be copied to work on > > like an array does. > > > It's not a copy. It's the original buffer data that the native side > > sees. That memory will be freed when the Buffer's java object is GCed > > (from no more references.) It's safe to use that address so long as > > you're still holding on to a reference to the Buffer (in Java, not > > native. That native pointer is only as good as the java > > counterpart). In the context of OpenGL, the memory is needed during > > the GL bufferdata or GL array call and most likely during the draw > > call (As that normally needs to read from system memory, particularly > > with arrays) but I don't know if it needs it all the way to the end of > > the flush. One would have to ask why you'd be allocating/deallocating > > memory in a real time simulation, though :) Preallocation throughout > > the sim would be the ideal solution and that wouldn't have issues with > > invalidating memory before it's done being used. > > > Like Bob said, don't be creating new buffers all the time. In a > > dynamic system (where you don't know how many triangles you'll be > > drawing until visibility checks are done), make one the biggest buffer > > it ever needs to be and use however much of it you need to use for > > that draw. Most systems are relatively static, though, so all you > > need to do is preallocate for each unique 3d object and use transforms > > to do the dirty work. > > > I have a dynamic system for animations so I end up recalcing vertex > > positions, but that's a fixed size buffer so I never need to > > reallocate. I just process it in native code and it really works > > great. > > > On Feb 25, 11:30 am, Bob Kerns wrote: > > > > This would be a bug in the JNI code, which is responsible for > > > protecting from the GC any and all memory which it is using. Only it > > > can do so, because only it knows when it is done. > > > > That's unlikely, though. The the JNI API makes it impossible to get > > > your JNI code to get its hands on the data without protecting it from > > > the GC -- and even then, you may only get a copy, if the system feels > > > like doing that instead. Bugs ARE still possible -- you can free it an > > > then hang onto the data you no longer have rights to. > > > > But really, the only impact of holding onto a buffer on the Java side, > > > only to discard it next frame, is to make the GC work harder. If you > > > were to REUSE that buffer, however, you'd avoiding extra GC work. > > > > On Feb 25, 12:45 am,
[android-developers] Re: Crash in glDrawElements() using VBOs just after glBufferData()
Sure!
It doesn't really do very much, just a wrapper around a buffer.
frame_reset() is called once each frame.
public class DynamicBuffer {
private static final int BUFFER_SIZE = 32*1024;
private static final int SCRATCH_SIZE = 32*1024;
private static int _p = 0;
public static FloatBuffer _buffer;
public static float _scratch[] = new float[SCRATCH_SIZE];
static {
_buffer = Util.create_floatbuffer(BUFFER_SIZE);
}
public static int allocate(int size) {
int r = _p;
_p += size;
if(_p > BUFFER_SIZE)
throw new RuntimeException("Dynamic buffer overflow");
return r;
}
// will only deallocate the last consecutive sequence of allocated
blocks
public static void deallocate(int size) {
_p -= size;
if(_p < 0)
throw new RuntimeException("Dynamic buffer underflow");
}
// write to dynamic buffer at offset off (returned by allocate())
contents of buf at [buf_off,buf_off+buf_len)
public static void put(int off, float[] buf, int buf_off, int
buf_len) {
_buffer.position(off);
_buffer.put(buf, buf_off, buf_len);
}
public static void frame_reset() {
_p = 0;
}
}
public class Util {
...
public static FloatBuffer create_floatbuffer(int size) {
ByteBuffer bb = ByteBuffer.allocateDirect(size*4);
bb.order(ByteOrder.nativeOrder());
FloatBuffer fb = bb.asFloatBuffer();
return fb;
}
...
}
On 26 Feb, 00:49, Robert Green wrote:
> Viktor,
>
> Would you be willing to show a bit of your DynamicBuffer code so I can
> see what it's doing? It's hard for me to help when there's a black
> box in the middle.
>
> On Feb 25, 1:41 pm, Viktor Linder wrote:
>
> > To clarify, in the original example, no buffer is allocated. The call
> > to "DynamicBuffer.allocate()" simply moves a position in a previously
> > allocated buffer which is filled each frame - ie. an "arena
> > allocator". DynamicBuffer.deallocate_last(size) simply moves the
> > position back without destroying any memory.
>
> > So it is not a gc issue. Also, while the buffer might get filled with
> > "junk" it will still be valid floats of some sort, since the array is
> > only written to from java.
>
> > Best regards,
> > Viktor Linder
>
> > On 25 Feb, 20:08, Robert Green wrote:
>
> > > Actually, let me clear something technical up. I just realized that
> > > the OpenGL native side is using GetPrimitiveArrayCritical and not
> > > GetDirectBufferAddress. I'm not sure why they decided to take that
> > > route but I'm sure there was a good reason for it. The fact of the
> > > matter is that while GPAC doesn't guarantee the actual array address
> > > (it has the option to make a copy), it's most likely that it won't
> > > make a copy and will instead hand over the actual array address. This
> > > of course depends on the VM's implementation. The could have easily
> > > implemented it to always use the actual address. Someone from that
> > > camp would have to comment because I'm not going to dig through
> > > Dalvik's source :)
>
> > > Read more about it
> > > here:http://java.sun.com/j2se/1.3/docs/guide/jni/jni-12.html#GetPrimitiveA...
>
> > > That being said - all of what I talked about still stands. It's just
> > > a different JNI function to get to it.
>
> > > On Feb 25, 12:39 pm, Robert Green wrote:
>
> > > > Let me explain something. Using directly allocated NIO buffers is a
> > > > DIRECT LINK between Java and native. The pointer you get from (void
> > > > *)GetDirectBufferAddress points to the exact memory that the Java
> > > > buffer is using. The memory is not managed in Java on the heap like
> > > > everything else. This is one of the few cases where you can write to
> > > > natively accessible code that does not need to be copied to work on
> > > > like an array does.
>
> > > > It's not a copy. It's the original buffer data that the native side
> > > > sees. That memory will be freed when the Buffer's java object is GCed
> > > > (from no more references.) It's safe to use that address so long as
> > > > you're still holding on to a reference to the Buffer (in Java, not
> > > > native. That nativ
[android-developers] Re: Android OpenGL Game - App Architecture and Threading Logic
I understand that this is pseudo-code, so it probably does not reflect
your actual implementation, but I have two comments on this code:
* Depending on how the scheduler works, the GameLogicThread or the
Renderer thread may receive the lock two or more times in succession.
* The renderer and the game logic thread never execute in parallel, so
any time spent blocking in either thread is not used by the other. If
for instance the renderer thread would receive a list of things to
render from the game logic thread once each frame (and the game logic
thread takes care not to modify this data during its loop) this would
be achieved.
Best regards,
Viktor Linder
On 9 Apr, 18:03, Robert Green wrote:
> It's pretty easy to do this:
>
> I use a World to write to and read from for the two "sides." Makes
> networking nice too. My World has a simple lock. Only one thing can
> write to it or read from it at a time.
>
> in GameLogicThread:
>
> run() {
> while (!done) {
> // wait for renderer
> world.getLock(); // blocks
> update()
> world.releaseLock();
> }
>
> }
>
> in Renderer:
>
> onDrawFrame() {
> world.getLock(); // blocks
> draw()
> world.releaseLock();
>
> }
>
> On Apr 9, 3:27 am, Clankrieger wrote:
>
> > Hi,
>
> > I had a lot of difficulties getting the threading and app lifecycle
> > issues done, too. For my part, this was much more confusing than
> > getting the actual game done. ;)
>
> > The good thing is: you do not have to do too much for the render- and
> > logic-thread separation because most of the rendering time is getting
> > spent "outside" of your renderer's onDraw method. This is how I got
> > this done: The "Game" itself is owned by the glSurfaceView renderer
> > instance. the when the game starts (at onResume), I start an
> > updatethread that is very simple an does something like
>
> > while(bKeeprunning) {
> > synchronized(Game.sInstance) {
> > Game.sInstance.update();
> > }
> > Thread.sleep(50);
>
> > }
>
> > I have to add that my game logic is doing only this: logic. The world
> > gets simulated. This is done less than 10 times per second - this is
> > why I can have it sleep for 50 ms. sleeping is important here to give
> > the render thread time to do this (I don't remember the full method
> > signature, but I think you know what I mean):
>
> > onDrawGlFrame() {
> > synchronized(Game.sInstance) {
> > Game.sInstance.render();
> > }
> > Thread.sleep(5);
>
> > }
>
> > I defined the updatethread as class inside of the Renderer because it
> > is so small. This gave me a huge performance boost. Handling the app
> > lifecycle is less easy (at least for me).
>
> > On Apr 9, 3:09 am, Eddie Ringle wrote:
>
> > > Surprisingly, I don't seem to have issues with the OpenGL side of
> > > things (which is very unusual), but my problems stem from getting a
> > > clear idea for app architecture and a few other problems.
> > > Right now, most tutorials on the net just describe the render portion.
> > > I know that when I create a GLSurfaceView and hook a Renderer into it,
> > > it uses it's own thread for rendering.
>
> > > I want to do logic operations and other gameplay stuff (like moving
> > > characters and whatnot) in it's own thread as well. Can anyone explain
> > > a good approach to this? I'm guessing the two threads will have to be
> > > synchronized (do logic, render, repeat), and limited based on time so
> > > that it performs smoothly across different devices.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe, reply using "remove me" as the subject.
[android-developers] Data readable by two apps
Hi! Is it possible to share files between two apps? My scenario is this: I want to create a free/demo version of my game and a complete version. The player should be able to play the free version, then upgrade to the complete and continue where the free version ended - ie. the complete version would need to load a savegame created by the free version. All answers appreciated! Best regards, Viktor Linder -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Posting events to View
Hi! I have the following problem: My app has a thread that updates the game state. The app needs to make a change to the state of the View object, triggered by this thread. The documentation for View states that it should only be modified from the UI thread, and that a Handler should be used to place and handle events. Yet, there is a function post() in View where I can post a Runnable object that will execute in the UI thread without involvement of Handler. Can I not call this function from threads other than the UI thread?? I'm confused! Best regards, Viktor Linder -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Intermediaries for publishing on Android Market
Hi! I live in Sweden, and so cannot publish paid apps on the Android Market. Is there any company in a "publishing enabled" country which you can publish apps through (for ex. a percentage fee)? All answers appreciated! Best regards, Viktor Linder -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Emulator, forcing portrait mode
I have android:screenOrientation="portrait" set for my activity. Creating an AVD with resolution 800x480 and running my activity, the GLSurfaceView is created with dimensions 800x480 (ie. not rotated and width > height). I would expect it to be created with dimensions 480x800 and be rotated 90 degrees. Is this a bug in the emulator or am I wrong in my interpretation of android:screenOrientation? Best regards, Viktor Linder -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Free version of paid app
I recently published a game ("Deep Dagger" / http://www.gearupgames.se,
check it out! :) ) on Android Market and was thinking of creating a
free version.
I have a couple of questions:
In your experience, has a free version helped more people discover
your app?
Does the free version need to have its own package name? Any other
technical considerations?
All answers appreciated!
Best regards,
Viktor Linder
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
[android-developers] READ_PHONE_STATE and WRITE_EXTERNAL_STORAGE automatically required?
My app does not require the READ_PHONE_STATE and WRITE_EXTERNAL_STORAGE permissions (there's no clause about this in the manifest), but it seems they are implicitly added by the SDK when minSdkVersion is set to 3. Will the user on a 1.6 or higher phone be queried about these permissions when downloading my app from the market, or is it only when downloading it through the browser? This is a bit of a catch 22 - I support 1.5 and I want to reach this userbase, yet I do not want to scare potential users by requiring these extra permissions (which my app doesn't require; it doesn't write to the sd card nor use the phone function). Anyone in this group have experience dealing with this issue? All answers appreciated! Best regards, Viktor Linder -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: READ_PHONE_STATE and WRITE_EXTERNAL_STORAGE automatically required?
Indeed, this is how my uses-sdk clause looks like: Yet, the user is queried about the READ_PHONE_STATE and WRITE_EXTERNAL_STORAGE permissions anyway (when downloading from a direct link in the browser). The "project target" (set by the android tool when updating the project) is "android-4". Is there a difference in behaviour between downloading from the Market and the browser? Best regards, Viktor Linder On 22 Juni, 05:49, Dianne Hackborn wrote: > As usual, when new features are added or changes made, targeting the > platform version (or better) where that was done will turn off any > compatibility code in the platform for older apps. So if you use > android:targetSdkVersion="4", the platform knows that your app was written > after these permissions were added, so they don't need to be automatically > added for compatibility. > > See:http://developer.android.com/reference/android/os/Build.VERSION_CODES... > > > > On Mon, Jun 21, 2010 at 3:56 PM, joebowbeer wrote: > > Good coverage at: > > >http://stackoverflow.com/questions/1747178/android-permissions-phone-... > > > Apps targeting 1.5 will always request these permissions implicitly. > > > But what about apps *targeting* 1.6 whose minSdkVersion includes 1.5? > > > > > > On Jun 21, 1:27 am, Viktor Linder wrote: > > > My app does not require the READ_PHONE_STATE and > > > WRITE_EXTERNAL_STORAGE permissions (there's no clause about this in > > > the manifest), but it seems they are implicitly added by the SDK when > > > minSdkVersion is set to 3. > > > > Will the user on a 1.6 or higher phone be queried about these > > > permissions when downloading my app from the market, or is it only > > > when downloading it through the browser? > > > > This is a bit of a catch 22 - I support 1.5 and I want to reach this > > > userbase, yet I do not want to scare potential users by requiring > > > these extra permissions (which my app doesn't require; it doesn't > > > write to the sd card nor use the phone function). > > > > Anyone in this group have experience dealing with this issue? > > > > All answers appreciated! > > > > Best regards, > > > Viktor Linder > > > -- > > You received this message because you are subscribed to the Google > > Groups "Android Developers" group. > > To post to this group, send email to android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
