Man, it's making it SO much easier to code for multiple screen sizes, even if it is a pain to figure out at first.

This is exactly why I'm working on translating my game over to AGK. The other tool I was using would have required a lot of work and I was thinking that I would end up having to make a copy and change a bunch of settings.
This greatly reduces my need to do that and I can code knowing that my game will be portable to multiple devices.

Yes, the first time I used the percentage system it felt like learning a new language but very soon it all made sense and the benefits are great.

Rick

the benefits would come when you change screen resolution and put in new set of graphics for different platforms right?

if you just want to make a game for ios what's the advantage?

@bjadams - yah, but even without a graphics change, I'm finding it's helping me design for different devices. I'm using some square sprites, and I want them to stay square and fill only a square part of the screen, so I'm adjusting how big they are and where they are placed by percentages.

By iOS, do you mean iPhone, iPhone 4, iTouch, 4th generation iTouch, iPad, and the new higher-res iPad coming next year? Because they all have different screen sizes, and the percentage system can help with that.

But I'm using it because I want to release on Android, iOS, Mac, and Windows.

So does the virtual resolution system. That combined with setting the display ratio is my favourite method at the moment. It's good to have options and everyone will settle of their favourite.

Agreed. I use the virtual resolution with the (-1) ratio flag as well.

When I setup a project, in the setup.agc file, it defines the Screen Width and Height. If I use UpdateDeviceSize( w, h ) does it changes these values at runtime? My Goal is as with everyone else develop games that run on multiple devices and if I have like an iPhone 4 or iPad 4 I'd like to run it at the highest res possible.

You won't need to update the resolution in real time. The great thing about virtual resolution is that the engine scales everything for you. Most of the games I'm working on right now, are in landscape mode, with:

SetVirtualResolution( 1024, 600 )
SetDisplayAspect( 600/ 1024 )

I don't have to worry about the devices resolution, AppGameKit scales it all for you. This means that a game written for a netbook with 1024, 600 resolution as standard, will work on an iPhone and iPad with the same code and settings just by changing the setup.agc file.

For the iPhone, it will appear normally, but because the aspect ratio for the iPad is 4:3, the game will appear with black boarders on the top and bottom of the screen as if you were watching a widescreen movie on the iPad, something iPad owners (and I am one!) are pretty used too.

This method removes any issue with square sprites not looking square, and if the iPad's boarders don't please you, you can always write a HD version and an iPhone version, that's pretty mcuh in fashion and you potentially get two sales, I know I've bought the same program twice on more than one occasion because a HD version as turned up.

Mean while, netbooks, and most other tablets all use 1024x600 at the moment, making the iPad a bit of a freak.

Well, the game I'm making first is in portrait mode, and I'm designing for the iPad, since it has the biggest screen of my target devices. So... I'll try it with virtual resolution as well as percentage - if I make all the various size and postion paramaters variables, it won't take much to swap modes. The PC, Mac, and Notebook versions will just have to be in a portrait style window.

It's a really simple word game, so I think it's a good program to experiment with. On a game with a lot of code, I'm sure I would pick one method and stick with it.