WVGA800 and WVGA854 for games

by Warren » Sat, 03 Oct 2009 03:44:07 GMT


Sponsored Links
 I have developed a game for android that really needs to have a
480x320 resolution.  I have considered trying to alter the game to
work with different resolutions, but this would be very difficult if
even feasible. I know of at least one phone from Motorola that will
have a WVGA screen. I loaded my game in the new 1.6 emulator with a
WVGA screen and the game was scaled up to fill the screen with a black
bar of unfilled space on the right.

I'm happy to see that the application scaled up, but I wish it didn't
have a black bar on the side. I am also anxious to see how the scaling
performs. My game needs every bit of CPU it can get.

I assume others of you have apps that rely on 320x480 screens. They
might rely on them for a reason, like mine, or it may be that you
haven't gotten around to designing for multiple screens yet.  At any
rate, how do you plan to deal with other screen sizes? (There are QVGA
phones coming soon too.)  I'm trying to decide the best way forward.

Thanks,
Warren
--~--~---------~--~----~------------~-------~--~----~



WVGA800 and WVGA854 for games

by Dianne Hackborn » Sat, 03 Oct 2009 04:18:15 GMT


 Fwiw, as a general rule, I would hope that a device that has a high
resolution screen is correspondingly beefier in power.  Even ignoring that,
though, you can expect HVGA devices to have varying performance
characteristics.

On thought I have is to view Android more like the desktop world, where if
needed you give the user some ability to adjust the rendering features of
the app to improve its performance on their device.  And longer-term, I
imagine that having built-in knowledge about various existing devices to
automatically select those options will be used, again like on the desktop
with graphics cards.  (I do realize that this is more problematic in the
mobile space since getting access to particular devices is more difficult
than getting different graphics cards.)

Another interesting wrinkle is that in density compatibility mode, the
Surface behind a SurfaceView is kept at the HVGA resolution and scaled up
(or down) by the compositor as it is drawn to the screen.  So if you are
doing rendering in that, you are still dealing with an HVGA size buffer.  We
have actually seen this have better performance than an app that is running
in non-compatibility, since the scaling is likely less work than rendering
all of the complicated scene inside of the surface view.  I believe you can
do the same thing outside of compatibility mode by setting the SurfaceView's
surface to a fixed size that is smaller than the actual view itself, giving
you something equivalent to the desktop approach of running at a lower
resolution than the user has set for their normal screen.






-- 
Dianne Hackborn
Android framework engineer
hack...@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails.  All such
questions should be posted on public forums, where I and others can see and
answer them.

--~--~---------~--~----~------------~-------~--~----~


Sponsored Links


WVGA800 and WVGA854 for games

by Beowolve » Sat, 03 Oct 2009 16:57:38 GMT


 > I'm happy to see that the application scaled up, but I wish it didn't

I don't think scaling will be a problem with performance. Newer
devices with bigger screens will most likely have more cpu power
anyway so I will just ignore this fact *g*. But like for desktop
applications, we have to create flexible applications that can handly
multible resolutions. No way arround that I guess.

good luck

Andy
--~--~---------~--~----~------------~-------~--~----~



Other Threads

1. Disable context menu not working ... bug?

Wasn't sure if it when this occurred  - just noticed it yesterday when I was
doing something else.  It seems to me that it should not allow a click -
matching the behavior of the main menu.  From a user's perspective, they may
think they clicked on something that should do something ... so it may
confuse the user.

Jason Van Anden
http://www.bubblebeats.com
http://www.twitter.com/bubblebeats







--~--~---------~--~----~------------~-------~--~----~

2. Launching share option in menu

Hi

I'm trying to make a 'share' option in menu, just like in the gallery
application.
I am using the following code:

 MenuItem item2 = menu.add(0,0,0, "Share");
        item2.setOnMenuItemClickListener(new
MenuItem.OnMenuItemClickListener() {
            public boolean onMenuItemClick(MenuItem item) {
                Intent intent = new Intent(Intent.ACTION_SEND, null);
                File f = new File
(Environment.getExternalStorageDirectory()+"/Ania.jpg");
                intent.setData(Uri.fromFile(f));

                startActivity(Intent.createChooser(intent,"Share a
picture or sth"));
                return true;
            }
        });

When i press the Share button in the menu i get "No applications can
perform this action".
What am I doing  wrong? (im working on a real device not the
emulator).

regards
Lukas Mosdorf
--~--~---------~--~----~------------~-------~--~----~

3. How does Gallery's "Send" Intent Work?

4. how to create our own BorderLayout

5. Run application at device startup:

6. MapView handling KeyEvent.KEYCODE_DPAD_CENTER

7. How to animate a drawable inside an App Widget?