Hey Robert, Thanks so much for your reply! I think you might be right that this IS in fact a scaling issue. I'm sure I can run some tests by actually drawing a dot at the actual screen coordinates and comparing where I expect it to land. I got the jist of the issue right away when you mentioned it but I also appreciate the additional suggestions.
Now I just have to drum up a couple thousand bucks for the rest of the android phones :-). Rocco On Mar 18, 10:48 am, Robert Green <[email protected]> wrote: > Rocco, you're experiencing basic 2d scaling dilemma. There are > several ways you can go, each with its compromises. > > The gist of it is that your game will need to work correctly on > screens ranging from 320x240 to 854x480 if you want to support every > android device. If you take off the qvga screens, you still need > 480x320 (G1) to 854x480 (Droid). > > You should decide if you will always show the same game to every size > screen. If so, you'll want to set a target resolution (say 480x320 if > you're landscape on a G1) and use that as a scaling factor to get the > correct display on a different sized screen. At that point, your game > world will need to operate as if it's always that resolution. You > will need to scale the vital game components, such as player pieces, > enemies, projectiles, anything collideable, really. > > If you don't care about consistency across devices, you at least need > consistency with your input. When you calculate the touch vector from > down, move to up, you will want to scale that so that the physics in > the game are consistent. > > I always use a reference width (when portrait) or a reference height > (when landscape) that looks like this: > int referenceWidth = 320; > float drawScale2d = actualWidth / referenceWidth; > float inputScale2d = referenceWidth / actualWidth; > > Use inputScale2d to get a consistent screen input value across devices > (swiping "10" pixels will always be 10 pixels even when the actual > device is 15, because you scaled.) > > Use drawScale2d to make objects draw to the same dimensions as they > would have on a lower resolution screen. If you're in opengl it's > just a projection you use, but if using a Canvas you can actually set > the matrix to use that and then draw. That will make it fairly easy > to get the desired scale. > > The stuff I'm talking about doing is density-independent, that is, it > won't matter what density the screen is because the goal of a portable > game is to give a consistent experience across multiple devices. > That's all you need to do that. > > Hope this helps. Test on many devices. > > On Mar 17, 2:16 pm, Rocco <[email protected]> wrote: > > > Hi, > > > I'm writing a simple tile based game using a canvas and a 5X5 grid of > > tiles. To determine if a tile is clicked I look at the MotionEvent > > supplied by onTouch. I get the coordinates when MotionEvent.event is > > ACTION_UP and translate to tiles. This works great on the emulator > > but when I touch on a device the actual coordinates of the touch > > register higher than I'd expect as a end user. > > > I'm wondering what strategies people have used to get a closer to > > "expected" result. Do you use a simple Y offset? Do you average the > > coordinates over the life of the touch? Do you use other methods? > > > Thanks! > > > Rocco -- 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 To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
