I'm of the same opinion as Nobu Games, it might be a concurrency issue.
Canvas works because it runs on the UI Thread.
Edvinas, try this (in your sample):
// replace x and y with a single volatile variable or use synchronized
private volatile long mCoords;
//...
public boolean onTouch(View view, MotionEvent motionEvent) {
float x = motionEvent.getRawX();
float y = motionEvent.getRawY();
mCoords = ((long) Float.floatToIntBits(x) << 32) |
Float.floatToIntBits(y);
return true;
}
public void onDrawFrame(GL10 gl) {
//...
long coords = mCoords;
float x = Float.intBitsToFloat((int) (coords >>> 32));
float y = Float.intBitsToFloat((int) coords);
//...
}
Sexta-feira, 2 de Agosto de 2013 20:20:03 UTC+1, Nobu Games escreveu:
>
> Hi Edvinas,
>
> I need to ask again, because I think that may be the cause of the delay:
> how do you communicate the touch events to your rendering thread? Because
> Android can bombard your UI thread with lots of touch events in no time.
> But your rendering thread needs to "peek" before updating the game state in
> regular intervals into the current state of touch input. It's your game
> loop / rendering thread that needs to dictate the rhythm in order to
> synchronize the "whole experience".
>
> What I do in my game is the following:
>
> 1. Touch input event handler receives all motion events on UI thread
> ---> converts motion event data into a custom data structure and puts it
> into one queue that belongs to UI thread
>
> 2. Simultaneously the game loop / render thread updates the game state and
> checks for input first:
> ---> It requests the data from touch handler in a thread safe manner
> (synchronized)
> -------> Touch handler internally swaps motion data queue A with a
> secondary motion data queue B
> -------> Touch handler returns queue A to game loop
> ---> Game loop / render thread processes queue data and recycles all
> motion data structures (so they can be re-used in order to avoid garbage
> collection activity)
>
> And that repeats like this and these two queues get always swapped. That
> way you let your game loop determine the pace.
>
> On Thursday, August 1, 2013 4:30:57 AM UTC-5, Edvinas Kilbauskas wrote:
>>
>> OK, I did that. And yes. It doesn't have the delay anymore! But the
>> problem is... It's Canvas. I don't need canvas, it doesn't fulfill my
>> needs. I need OpenGL.
>> What the hell could be wrong? This is REALLY strange. OpenGL ES 1.0 has
>> delay, ES 1.1 has delay, ES 2.0 has delay. Canvas - no delay!
>> This should be other way around, because as far as I know canvas uses
>> software rendering, while OpenGL uses hardware, which should be way faster!
>> Any more ideas?
>>
>
--
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
---
You received this message because you are subscribed to the Google Groups
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
