Jump to content

  • Log In with Google      Sign In   
  • Create Account


Seabolt

Member Since 26 May 2010
Offline Last Active Mar 06 2014 02:35 PM
-----

Posts I've Made

In Topic: Is it possible to render from another thread without OpenGLES

06 March 2014 - 02:36 PM

PBOs have some scattered support from my initial research, and isn't reliable.


In Topic: Is it possible to render from another thread without OpenGLES

06 March 2014 - 12:32 PM

That's what I was worried about. Currently the tech I'm using has the resources tightly coupled to the graphics initialization. And I'm out of time to change such an expansive architecture.It seems like anything I do will be a hack and will not be reliable. It alright there are other, less robust ways of showing a loading screen. Thanks!


In Topic: [ANDROID NATIVE ACTIVITY] Resume message is followed by window destruction

16 February 2014 - 08:21 PM

Hm... it's possible. I'm using native activity, so I'm not using any intents but I might be causing something similar when resuming.

 

Currently I can reproduce the issue by sleeping the screen and waking it up. I'm already releasing opengl resources and recreating them, and it will pause and resume correctly 90% of the time. 

 

Here's some of the output I get prior to the crash:

 

D/audio_hw_primary(  180): adev_set_parameters: exit with code(-2)
V/threaded_app( 8167): Resume: 0x728fae18
V/threaded_app( 8167): activityState=11
I/ACE     ( 8167): [ENGINE] Received Command 11...
I/ACE     ( 8167): [ENGINE] Command APP_CMD_RESUME
D/SurfaceControl(  526): Excessive delay in unblankDisplay() while turning screen on: 241ms
E/BufferQueue(  177): [com.ace.engine/android.app.NativeActivity] dequeueBuffer: BufferQueue has been abandoned!
W/Adreno200-EGLSUB( 8167): <DequeueBuffer:544>: dequeue native buffer fail: No such device
W/Adreno200-ES20( 8167): <gl2_surface_swap:43>: GL_OUT_OF_MEMORY
W/Adreno200-EGL( 8167): <qeglDrvAPI_eglSwapBuffers:3518>: EGL_BAD_ALLOC
W/Adreno200-EGL( 8167): <qeglDrvAPI_eglSwapBuffers:3525>: EGL_BAD_SURFACE
V/threaded_app( 8167): NativeWindowDestroyed: 0x728fae18 -- 0x730334e0
 
All the ACE tags are my application.

In Topic: Android NDK touch coordinates

17 December 2013 - 10:32 PM

Okay, after a fair bit of searching; the issue is that the screen was using density pixels, (dp), which are a relative coordinate. If you add this line to your manifest: 

	<supports-screens android:anyDensity="true" />

Then it will no longer apply the DPI conversion and your touch coordinates will come in a screen pixels.


In Topic: Android NDK touch coordinates

17 December 2013 - 04:25 PM

That's actually interesting, it was based on what the initial size of the screen that I was given by the device. I honestly have no idea what the resolution should be. All I know is that when I create a screen and resize it to be 1920x1080, my coordinates are coming in 550. Here's a print of what my touch information is:

 

x=958

y=199

xPrecision=0.5833

yPrecision=0.56

xOffset=0

yOffset=0.


PARTNERS