Retina Resolution Graphics?

This was discussed in the earlier betas, but now that beta 12 works on all the iPhone resolutions properly, I'd like to ask about the progress now.

How can we make a game which runs with retina graphics (ie. double the resolution) on an iPhone 4 and with "normal" resolution graphics on an iPhone 3/3gs?

In the .zip files which MMF exports to there is a resource folder with retina graphics such as "Default@2x", however the other game images are not in there (someone mentioned they were embedded in the cci?) and so I can't see how to make this work.

yeah, it would be amazing to be able to use 2 sets of graphics but at the moment all the graphic resources are encrypted in the cci...for whatever reasons.

this is one of the great features of the iOS, being able to have two sets of graphics so they look good on both device resolutions, and not all scaled and blurry from auto scaling.

And it's an important aspect too. Having your game run with good graphics on both resolutions is a big selling point. Many people with iPhone 4s will complain if a game is autoresized and blurry.

As it currently stands, is there a point in making a game with 960x640 resolution in the MMF Runtime? Do they run on iPhone 3/3gs? I haven't tested that yet.

> Do they run on iPhone 3/3gs? I haven't tested that yet.

And the Ipad? Do they run on it?

A 640x960 game is resized (by half) when it is played on a non retina display. So yes you can have hires games.

but can we use our own graphics for the halved version? resizing high res stuff sometimes doesn't look too great

Firstly, what RhysD says is right, we can't rely on the resizing method of the engine to always be the best option.

Secondly, surely resizing a 640x960 game to 320x480 is a lot of strain on a 3g/3gs CPU? Or is this done once beforehand for all graphics instead of in real time?

It certainly works in Ipad and 3nd gen and 2nd gen terminals, but the game is very slow when scale. I tried it on my devices.

It's likely to be difficult to have more than one set of graphics for each object as this concept is not currently supported by MMF. You can clone an app at a new size which you could then update but this leaves you with two separate apps.

I don't know what the nice answer is to this, if there is one that is practical. I could imagine that one possible solution could be to make a tool that would read in two iphone projects, one as the master and one that contains the scaled down version of the graphics, and then to somehow merge the two. The question to ask is creating a tool practical? And it would be a nightmare for developers to maintain two identical MMF projects.

So I don't see any easy answer unless something inside MMF changes to support graphic mode sizes, or if there is a better idea for graphic substitution.

You could clone your app with half the size as Andos says, and then just import it at the end of the application, customize the graphics if you want, and at runtime jump to the first frame of the second application on low res iPhones.

Not ideal, but I don't see a better way if you want a unique app that works on different devices with different resolutions.

The thing is, can we know at runtime which device model is executing the game?

Is true BHGames, we can not identify what type of device is.

But I think that this should be seen more in the future, sales of iPhone and iPod retina display are very large, and I think in the near future no one will have lower resolution devices. Annex a table showing the evolution of the installed base of iPhone.

http://img819.imageshack.us/img819/1...ntasiphone.png

Also this year comes the new iPad possibly add a new resolution. In conclusion what I mean is that it is important to me and I think for all the Iphone Exporter works well and also to support higher resolutions and of course have support for the iPad with 1024 * 768. On both platforms we have a very important market niche.

I hope that Yves and Francois and Clickteam entire team involved in this work in support of the iPad.

I don't know if this is a ridiculous suggestion, but what if we created animations prefixed with "@2" and MMF would automatically choose those instead of the normal ones?

For example your active object would have its "Stopped" animation, and then for higher resolution it automatically uses "@2Stopped" wherever it is supposed to use "Stopped". The only problem is that the user would have to be responsible for having the same number of frames in their animations (@2Stopped/Stopped) for consistency, and also backgrounds aren't accounted for with this method.

Alternatively, Yves' solution of a frame clone works... even if it's not ideal. But as BHGames said - we still can't tell what device we're running on, can we?

Also for the iPad, in some cases or type of games, we could just change the screen size to 1024x768 at runtime without modifying the size of the frame and the virtual size. But this is currently not allowed for the iphone.

You keep the same graphics and the same coordinates logic; you just allow the camera to see more areas of your level (in comparison with smaller devices).

No need to clone the game and adjust it only for the Ipad. Again, this would work for some type of games.

Yes, but no support for the iPad, although we can run that resolution is to 1X/2X.

I was just thinking aloud :)

Quote:

---

can we know at runtime which device model is executing the game?

---

Francois or Andos are porting the Mobile Utilities object that should allow you to retrieve the screen size, so yes you can.

Quote:

---

I hope that Yves and Francois and Clickteam entire team involved in this work in support of the iPad.

---

Francois and Andos are fixing bugs on iPad. Also in beta 12 when you create a new application and select an iPhone build type, 1024x768 has been added to the list of resolutions in the "please select an iPhone resolution" dialog box.

Quote:

---

Originally Posted by Yves

Francois or Andos are porting the Mobile Utilities object that should allow you to retrieve the screen size, so yes you can.

---

Great :)

If we do go down the road of cloning a frame, does only the frame that is loaded consume memory? Or is there some overhead (besides file size) of having duplicated frames, even if one isn't used?

> Francois or Andos are porting the Mobile Utilities object that should allow you to retrieve the screen size, so yes you can.

Great! One question: say that my game has a virtual size and frame size of 1024x768 but the game's screen size is set to 480x320, if the game is run on the Ipad, will the front buffer be mapped 1:1 with the backbuffer? (perfect situation) Or will it still draw a 480x320 buffer and then scale it to 1024x768 (worst-case scenario)?

Great Yves!!!

Right now I test an application in the Ipad to 1024 * 768 ...

Only the current frame takes up memory.

We are investigating a few different solutions to this problem about doing HD graphics for iPhone4. I have a few ideas that might work.

Not promising that it will be implemented or anything - but I would like to hear you out on this idea:
You develop your game for iPhone4 with HD graphics. At runtime(load time) the graphics will automatically get downscaled to iPhone3 size. That way you only need to make the game once for the high resolution while it will look good on the low resolution screens.
There is one disadvantage to this though: You cannot make any specially optimized graphics for the lower resolution as they would be automatically generated.
What do you think of this?

BHGames: It would scale.

Is perfect, but when downscaled, the game is very slow in Iphone 3G and Ipod Touch 2nd.

> BHGames: It would scale.

Any chance that we can change full screen size at runtime to 1024x768 so that it doesn't scale it?

BHGames: I don't know yet. It would maybe give some other problems down the line. We'll discuss it.

Koji_Kabuto: Yes right now it is very slow because all the textures are not scaled down. Big textures drawn to a small area can get very slow. Small textures drawn to a large area is very fast.

> We'll discuss it.

Thanks for considering it. :)

Thanks Andos.

I certainly did not work at all in resolution 1024 * 768, not even a blank frame, has anyone tried it?

Get an application running on the IPAD to 1024 * 768, but gives many problems, the main areas that touch both of the sprites, such as fire button joystick 1 and 2 do not work, I think the problem is because there is no resolution change is real but as an Iphone HD application running at that resolution.

I think the support should be native to the ipad, but unaware of the complications it brings to Clickteam.

depending on how the graphics are named when exported (can a dev confirm if they use the active/backdrop names for filenames?)

is there any chance xcode will automatically pick a graphic if we clone the active/backdrop in the frame/library and rename it with the "@2x" extension?

so, I have an active called "player", it gets exported as "player.png" in the encrypted .cci

I then make a clone of the active "player" and delete it from my scene (remains in my library). I then rename the active to "player@2x" and import my retina graphics to replace the normal sized ones it already contains.

this "player@2x" gets exported as "player@2x.png" and from what I understand, is this all xcode needs to recognise that it uses that resource for retina display?

No that would be too simple. Changing the name of the object does not have any effect.

And discovered the problem at 1024 * 768 resolution, and none other than the iPad not recognized, before I wrote that the buttons on the joystick does not work, but if they do, the problem is that the screen recognizes only 960 * 640 then if you tap near the bottom or sprite if it works, it is as if the screen out of register. I guess this is a bug because the exporter does not generate content for the iPad, but for the Iphone. Furthermore when in 1024, the application has black edges and is not full screen.

We are working on the ipad issues right now...

IMHo, there may be three options -to manually set/select by the developer- when a game is created with a lower size and different aspect ratio:

a) full screen scale up (changes the aspect ratio),
b) scale up with no change (letterboxed), and
c) keep the original size but change the screen size to map 1:1 with the IPad's (like changing the FOV of the 2D camera with the same aspect ratio as th original).

Great Francois!!!

So is there an official solution to this? Is something being worked on so that we can make our one game run on multiple devices with different resolutions?

Not in the current version, sorry. But you Can create your game in retina résolution, and it will be resized for 320x480...

Quote:

---

Originally Posted by Andos

Only the current frame takes up memory.

We are investigating a few different solutions to this problem about doing HD graphics for iPhone4. I have a few ideas that might work.

Not promising that it will be implemented or anything - but I would like to hear you out on this idea:
You develop your game for iPhone4 with HD graphics. At runtime(load time) the graphics will automatically get downscaled to iPhone3 size. That way you only need to make the game once for the high resolution while it will look good on the low resolution screens.
There is one disadvantage to this though: You cannot make any specially optimized graphics for the lower resolution as they would be automatically generated.
What do you think of this?

---

Any word on this? It would certainly help with the file size that comes with importing and switching to a frame with SD resolution.

Well, it has been implemented and it works. The graphics and downsized on a smaller display.
So you can create your app for the best resolution, and it will happily display on all models.
You now have some new display-setting properties which allows you to define how the app will be shown on the device.

Thanks Francois but is this the method that Andos was talking about? 960x640 with smooth resize option is really slow on my test 3GS and I would rather not have 2 versions of the app. Resize before runtime/at loading time would be great.

to be honest the 3GS is already 4 generations back at this point, and as great as being able to accommodate it would be your going to limit yourself on the current design lineup.