If your game is not a very time sensitive, you may as well use ImageViews for tiles - then you will get honest touch events from them.
If you are using SurfaceView , there is Callback surfaceChanged - there you will get hones resolution and can determine size and position of yout tiles > On Mar 19, 2:37 am, Rocco <[email protected]> wrote: > 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.
