Saturday, July 10, 2010

Universal App - Technical Details

Back again... I've been hard at work upgrading the engine to handle multiple resolution issues properly, since universal apps must deal with 480x320, 960x640 and 1024x768. Most of the systems in the engine jwn systems  (just-whats-needed)  and it turned out the view system was a nest of hardcoded view sizes.  I've got it working fairly well now, and I've had some requests to talk over some technical issues, so tonights blog will be mostly boring technical facts to do with how I handle the universal app problem.

Firstly,  Magelore will be a universal app - which means one download will work on iPhone, iPhone4 and iPad. This means the download will include high definition (2x resolution) artwork that will be used on iPhone4 and iPad. All the apps I've purchased so far for my iPad have been specific "HD" apps that only run on the iPad. I can only guess why this is currently, though I can think of a few factors at play. Currently, you can get away with $5-$11 for an iPad app, but its hard to get more than $1 for an iPhone app.. So packaging iPhone and iPad together would mean you either get no iphone sales, or you get poor return on iPad sales.  My answer to this is that I may release a low-def version of the game that is iPhone only if I have to... There's also a possiblility the game will be free with in-app purchases, so initial sales are not important - I want it in as many hands as possible.

So, as a universal app, I need to support the 3 resolutions. I don't want to have to completely layout the UI 3 times,  especially since iPhone and iPhone4 are the same screen size and aspect ratio, it seems more appropriate to make the writing and buttons clearer than smaller.  For iPhone4, everything can be identical to the iPhone, just using double resolution art. So I've set the orthographic projection size for both of these to 480x320. No code has to change for the iPhone4 version.

However, for iPad, you have to deal with a different aspect ratio of 4:3 instead of 3:2.  Anyway you do it, some UI will need to have a different co-ordinates. Also, the distance between buttons is physically different with a much bigger screen, so its desirable to move some buttons around to reduce the amount the players will need to move their hands during play. So for iPad, I've gone with ortho co-ordinates of 512x384. This has lots of advantages. Without altering the map renderer,  we get slightly more map view area, which is nice,  but not so much that its a different game (due to being able to see enemies much further away).  It's also very important to stick with ortho co-ordinates that are a multiple of the hardware pixels. This way we still get pixel perfect rendering of fonts and sprites. I ended up spending 3 days getting the font rendering just perfect so all resolutions display their fonts cleanly. As a test, you can see in the image below that the 'i' and the 't' have perfect clean edges - no stretching or bilinear filtering artifacts.


The next problem was how to get the game rendering with higher definition sprites. My current sprite pipeline is to load a psd, and each layer becomes a sprite. Another layer can be used to define the "hotspot" of the sprite (also known as the pivot point or handle). Adding a double size sprite in my pipeline would just make them doublesized on screen.  There's a lot of solutions to the problems, but I'll just outlay what mine was without going into pages of reasons. The engine now appends a "_hd" to the filename and tries to load that first.  If we are NOT in highdef mode,  that file is downsized to half size for the low def version.  If the "_hd" file is not found,  the regular file is loaded instead.  For any "_hd" file (that is not downsized), the resulting Image and Sprites are marked as highdef and are rendered at half size.  The same system is in place for fonts. I use "BMFont" from AngelCode to generate my fonts. With high def, I can make the fonts a little fancier and they are still readable. In lowdef mode, I've gone for fairly boring fonts, preferring to make sure they are easily readable.

Here is a sample of how the extra resolution adds to the quality of the graphics.  Note that I haven't added highdef versions of the tileset yet.


Since most of my UI system will go through the universal info screen,  I've redesigned that to work of percentages rather than actual co-ordinates. That means it only shows slightly more information on the iPad than the iPhone.  Also, it means the art work is quite geometric (rendered boxes and gradient) rather than intricate artwork. I'm not sure if this detracts from the overall production values, so it may change in the final version of the game, but for now it is quite function.


Finally, here is a shot of the same scene on iPod, iPhone4 and iPad. To be honest they are screen shots from the PC version running in "compatibility" mode (I can put ipod, iphone4 or ipad on the command line and it emulates the correct backbuffer and viewport sizes).

iphone

iphone4

ipad

Thats all for now. I've also added icebolts and the ability to freeze enemies, or slow them. I've still got a little work to do - I need to convert the magic absorption stats to magic resistant stats so they can be used to resist freezing or cold effects. Once thats all in I'll do a new gameplay video. Hopefully I can get back to adding content now and less engine work.

p.s. if you have any questions or topics you'd like me to discuss, please add a comment below or email me.

No comments:

Post a Comment