Hi,
I’m trying to use SDL2.0 to develop android applications.
Here are my source code to get touch position:
SDL_PollEvent(&event);
int x, y;
switch (event.type) {
case SDL_FINGERDOWN:
x = event.tfinger.x;
y = event.tfinger.y;
break;
…
}
But event.tfinger.x and event.tfinger.y are not the right positions.
Actually I get two numbers that are too large.
I try to debug native code in Eclipse, and I find a function called
SDL_SendFingerDown runs strangely.
The two parameters of SDL_SendFingerDown, xin and yin are the correct
coordinates. But things become strange during stepping in these two
line:
x = (Uint16)((xin+touch->x_min)(touch->xres)/(touch->native_xres));
y = (Uint16)((yin+touch->y_min)(touch->yres)/(touch->native_yres));
x and y are very large numbers that not associated with the correct
Coordinates. It seems that the values in x and y are the values of
event.tfinger.x and event.tfinger.y. So I guess it’s the problem of
these two lines.
I don’t know how these two lines works. Can anyone tell me the
meaning of the variables in these two lines? Or any other ideas to
solve this problem?
Thanks,
Adolfans
2012/9/7 Adolfans <a.dol.fans at gmail.com>
Hi,
I’m trying to use SDL2.0 to develop android applications.
Here are my source code to get touch position:
SDL_PollEvent(&event);
int x, y;
switch (event.type) {
case SDL_FINGERDOWN:
x = event.tfinger.x;
y = event.tfinger.y;
break;
…
}
But event.tfinger.x and event.tfinger.y are not the right positions.
Actually I get two numbers that are too large.
I try to debug native code in Eclipse, and I find a function called
SDL_SendFingerDown runs strangely.
The two parameters of SDL_SendFingerDown, xin and yin are the correct
coordinates. But things become strange during stepping in these two
line:
x = (Uint16)((xin+touch->x_min)(touch->xres)/(touch->native_xres));
y = (Uint16)((yin+touch->y_min)(touch->yres)/(touch->native_yres));
x and y are very large numbers that not associated with the correct
Coordinates. It seems that the values in x and y are the values of
event.tfinger.x and event.tfinger.y. So I guess it’s the problem of
these two lines.
I don’t know how these two lines works. Can anyone tell me the
meaning of the variables in these two lines? Or any other ideas to
solve this problem?
Thanks,
Adolfans
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Are you using a recent checkout of SDL? I uploaded a fix for a rotation
issue with Android that may be what you are experiencing.
http://hg.libsdl.org/SDL/rev/2ed5671bc5e0--
Gabriel.
Thank you Gabriel. You remind me that I fogot to update
SDLActivity.java. But the problem remains. The positions are still
not correct. By the way, the two parameters of SDL_SendFingerDown, xin
and yin, are not the real coordinates any more.
2012/9/8 Gabriel Jacobo :>
2012/9/7 Adolfans <@Adolfans>
Hi,
I’m trying to use SDL2.0 to develop android applications.
Here are my source code to get touch position:
SDL_PollEvent(&event);
int x, y;
switch (event.type) {
case SDL_FINGERDOWN:
x = event.tfinger.x;
y = event.tfinger.y;
break;
…
}
But event.tfinger.x and event.tfinger.y are not the right positions.
Actually I get two numbers that are too large.
I try to debug native code in Eclipse, and I find a function called
SDL_SendFingerDown runs strangely.
The two parameters of SDL_SendFingerDown, xin and yin are the correct
coordinates. But things become strange during stepping in these two
line:
x = (Uint16)((xin+touch->x_min)(touch->xres)/(touch->native_xres));
y = (Uint16)((yin+touch->y_min)(touch->yres)/(touch->native_yres));
x and y are very large numbers that not associated with the correct
Coordinates. It seems that the values in x and y are the values of
event.tfinger.x and event.tfinger.y. So I guess it’s the problem of
these two lines.
I don’t know how these two lines works. Can anyone tell me the
meaning of the variables in these two lines? Or any other ideas to
solve this problem?
Thanks,
Adolfans
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Are you using a recent checkout of SDL? I uploaded a fix for a rotation
issue with Android that may be what you are experiencing.
http://hg.libsdl.org/SDL/rev/2ed5671bc5e0
–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
2012/9/7 Adolfans <a.dol.fans at gmail.com>
Thank you Gabriel. You remind me that I fogot to update
SDLActivity.java. But the problem remains. The positions are still
not correct. By the way, the two parameters of SDL_SendFingerDown, xin
and yin, are not the real coordinates any more.
Yes, the SDLActivity was modified to send a float value between 0 and 1 for
each axis, not the real coordinates. This mimics what the iOS backend does,
so the touch coordinates range becomes independent of the device
orientation.
To get the real screen coordinates you have to normalize the value to the
screen width/height, what I do in my code is something along these lines…
real_touch_x = finger_event.x * screen_width / 32768–
Gabriel.
2012/9/8 Gabriel Jacobo :> 2012/9/7 Adolfans <@Adolfans>
Thank you Gabriel. You remind me that I fogot to update
SDLActivity.java. But the problem remains. The positions are still
not correct. By the way, the two parameters of SDL_SendFingerDown, xin
and yin, are not the real coordinates any more.
Yes, the SDLActivity was modified to send a float value between 0 and 1 for
each axis, not the real coordinates. This mimics what the iOS backend does,
so the touch coordinates range becomes independent of the device
orientation.
To get the real screen coordinates you have to normalize the value to the
screen width/height, what I do in my code is something along these lines…
real_touch_x = finger_event.x * screen_width / 32768
–
Gabriel.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
It works! finger_event.x * screen_width / 32768 gives me the real
coordinates. Thank you very much Gabriel :). I think this usage should
be added to wiki.
In the function SDL_SendTouchMotion, xin and yin( the float value
between 0 and 1) are multiplied by 32768 to get a Uint16 value. I
think 65535 will be better than 32768 as Uint16 is unsigned:).