I personally wouldnt mind if my future iphone (got a 3GS now) was a HVGA phone with OLED, super ultra 3D-accelleration, mkv-supporting, x/h264-rescaling-decoding-resizing-enabled and so on..

The problem is that i need to jailbraik my iPhone to make most of it, so if it gets harder and harder with new versions, ill go over to Android. But even on that platform i would like to see a standardisation when it comes to resolution (preferably to HVGA, but i could settle for a bigger one, as long as it becomes a STANDARD!)

Then there’s screen size… Apple can’t have it both ways. Either they’re set at 480×320 forever, or they’re going to have the same issues of adaptation to new resolutions. Only, this isn’t known from the beginning, while with Android, it was.

So one way or another, the iPhone is going have “you suck” problems going forward. If they can’t match the higher resolution screens that EVERY other high-end phone is using, bad move. If they do go to that screen, now apps become even more segregated.

Or maybe, like Android, iPhone apps also use this amazing new invention called AN OPERATING SYSTEM. You don’t assume screen size, you ASK about screen size, and make simple adjustments accordingly. This has been done on personal computers for several decades now.. don’t ya bet that at least a few “phone” developers were present for that party, too?

It may well be that I am misinterpreting. I was picking up on the use of the Droid (WVGA) and Hero (HVGA) as examples Fake Steve used and how applications will scale between them. I have no idea how they would scale within WVGA or whatever hardware type is used. I was also looking at the screenshots posted from Jeff that show a QVGA screen and, judging by the 854 at the end of the window title, a WVGA screen. It’s a moot point anyway, Google have said themselves that apps will scale to a point – http://developer.android.com/guide/practices/screens_support.html – thanks to Dalvik.

@David

I’m only starting out in OpenGL ES myself. I’ve used Direct X a bit in college a few years back where I had fun setting the render resolution to be higher than screen resolution in a friends code :) My original comment – poorly written as it was and based on limited exposure – was intended towards 2D games and whether they’d translate well across the hardware types.

Since the marketplace will filter apps for you it shouldn’t be a problem. I’d hope that they wouldn’t assume someone to know what type of screen they have though, not everyone who uses android is will be that tech-savvy! :D

Apart from that you can chose to use one or more hardware input types. Every Android has a touch screen, and most have accelerometers.

The only real choice you have to make is wether or not to support a hardware keyboard only when creating games.

I don’t claim to know the ins and outs of OpenGL ES, but I do know that this is not a problem in OpenGL. In OpenGL, you specify how the camera maps to the screen at initialization, then everything from there on out pretty much boils down to placing pretty triangles in 3D space. So, if you wrote NDK code to initialize OpenGL ES, and if you chose to hard-code 320 and 480 into the initialization, then you’ll have to go back and query the screen size before initializing. If you did it right to start with, though, the process should be relatively painless, boiling down to shuffling around the GUI a bit on the longer aspect ratios.

@Others

As long as you stay in the Java VM (and don’t hard-code screen resolutions or place things with pixels), then there should be very little to worry about.

If you make high-res images that scale well, you may not even have to duplicate art for your app. Just include the high-res art and let Android automagically scale it down for you.

Finally, I think the real worry with fragmentation is with games and media apps that take advantage of special-purpose hardware like the GPU, signal processors, etc. that are included on the OMAP and Snapdragon processors. These apps simply won’t work on ARM 11 processors, or they’ll chug along at 2-5 FPS. Developers of 3D apps will segment into two groups. One will build multiple levels of detail in hopes of allowing Cortex-based processors to see the world in all it’s miniaturized beauty, while allowing our slower brethren to watch a pixelated, flattened rendering of the same world to keep their framerate up. The other group will just build beautiful apps that only run on high-end processors. The question becomes, just how many triangles can you push through a general purpose arm 11 processor? According to Qualcomm, you can render about 4 million triangles per second on a MSM720x (vs. 14 million on an omap and 22 million on a Snapdragon). At this speed ratio, it becomes relatively easy to quarter the number of triangles – a good decimator should be able to take your high-res objects built for snapdragon and build medium and low-res versions automatically that will work well for OMAP and ARM 11 processors, respectively. This change along with resizing textures can be the only changes needed to port from one platform to another.

I guess all in all I’m saying… you can run Crysis on integrated video, but who would want to? Let the games fragment the market. Maybe it will push the phone manufacturers to include good processors. If all the most popular games require Cortex/Snapdragon processors, then any phone that is marketed towards gamers will have one.

The biggest issue I see with all of this is, you can’t really test the Cortex GPU in an emulator. The solution for developers is: get a phone with a high-end processor as your personal phone and test the high-end content with it, and use the emulator as a good stand-in for the baseline experience on arm 11 hardware.