Sorry your browser is not supported!

I apologize for this being a broad question.

Anyways, I like using the Virtual Resolution system because it gives me precise control over how my app is displayed. As I am going to be developing this app almost exclusively for iPhone/iPad, I only have a few resolutions I need to be concerned about.

640x960 (1.5 ratio)(iPhone < 5)
640x1136 (1.67 ratio)(iPhone 5)
768x1024 (1.33 ratio)(iPad < 4)
1536x2048 (1.33 ratio)(iPad 4)

I'm using the code from here http://forum.thegamecreators.com/?m=forum_view&t=200753&b=41, and I'm targeting 640x960. When I test on iPad, the objects are too big on screen and appear off of the bottom of it.

Unless I'm mistaken, shouldn't it fill up to the bottom of the screen and leave more space on the sides (due to the wider aspect ratio on the iPad)?

Which code are you using? can you post a sample

(I posted some of the code on there just need to see if anything is different in your use)

Also, what version of AppGameKit are you using (v1076 or v1088)?

And, are you seeing this behavior through a Player (if so, what version and where did you get it) or by directly running it on your devices?

I'm doing this all on my Windows PC. I change the setup file to reflect a different screen size (320x480, 384x512). As for setting sprite size, I've been doing:

//start of app
VirtMin = 640.0

//setup sprites, should be 256x256 in size
SetSpriteSize(x, .4 * virtMin, .4 * virtMin)

Now as for positioning them, that's where I'm confused. Let's say I want a bar at the top of the screen that's the width of the screen but 96 pixels tall.

SetSpriteSize(y, virtMin, .15 * virtMin)
SetSpritePosition(y, 0, 0)

Would this be the way to do it? And if I wanted to 'flow' around it, set an object below it based on the higher objects position + height?

Ideally, with the difference in resolutions, I'd like the top/bottom of the screen to remain constant size (menus, input, ads) and the sprites I'm placing in the middle of the screen shrink/grow to available space.

The code looks about right, but I'd set things up in advance;

But I go a step further and use constants where possible;

I use the name SPRITE_DIV as a reminder that this is the sprite size as a division of the VIRT_MIN, so if at a later time I change the resolution used within the game, I know that this value will change too.

When I plan the game layout, I look for shortcuts

The first question I ask myself is "is it square?"

Games that play well in a square are great because I can simply make the game area VirtMin x VirtMin and use other stuff to pad the other areas.

Then if the orientation of the device changes, the game area does not need to be adjusted, I just moved the other stuff around to match the new shape.

This came in handy in my snake clone;

eg. In portrait;
- the ad is placed at the top
ad_height = virtMin * ( 50.0 / 320.0 ) ' Scaled Ad
ad_height = 50.0 ' Native Size Ad
- the game area is full width, square and below the ad
game_top = ad_height
game_bottom = ad_height + virtMin
- the mini map is below the game area and also square (handy)
map_size = virtMax - game_bottom
- the touch pad width is remaining area to the right of the mini map
pad_size = virtMin - map_size
- .. and also square
pad_top = virtMax - pad_size
- ..making it overlap the game slightly, which leaves a small area for counters and assorted bits
- the score and objectives are placed over the game screen.
- depth, a couple of transparent sprites and the touch pad overlap are used to mask obvious boundaries.

A similar system is used for landscape, with the exception that (because of the shape of the ads) to keep the game area as large as possible the ad is over the game area at the bottom. As a result the mini map and pad are slightly larger.

The game area is positioned using offsets, so the positions of the bulk of the sprites remain unchanged even though the display is a different shape.

The mini map is created from main game screen with a different offset and zoom using setscissor. The only thing that changes is the scissor coordinates.

For this game, VirtMin was used solely for positioning of things on the display plane, the game itself operated on the world plane - which is completely independent.

Game graphics were scaled with viewZoom so their size in relation to the device was handled by the zoom calculation not the sprite size.

That is - the sprites were a fixed size and VirtMin was used in the zoom calculation to scale them to suite the device.