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 <rbgrn....@gmail.com> 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 <roc...@gmail.com> 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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
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.
No comments:
Post a Comment