Problem with RETAINED Mode on iPad3

When using RETAINED mode I run into a strange problem.
Parts of the screen (the ones thatt are not updated in draw() get overwritten and
squeezed from graphics of other parts of the screen.
The only mode that seems to work is LANDSCAPE when not FULLSCREEN.
All other display modes show that bug.
Any solution, workaround for that?

Unfortunately we haven’t found a solution to this yet. It seems to be a problem with OpenGL’s retained backing mode on the iPad retina display.

Edit: I can confirm this is a bug with the iPad retina display and iOS 5.x. I’m going to check iOS 6 to see if the bug still occurs there.

Edit 2: Appears to be fixed in iOS 6. Unfortunately that’s not due out for a while!

Hi, when working with retained mode Another strange thing happens, also on non retina devices (iPad2): if I enable moive capture and i use commands like line() ecc. the y axis get mirrored.

Thanks for reporting this. I only have an iPad 1 and have spent the last week happily adding special effects by switching to RETAINED and messing with alpha levels @-) , which obviously would have been a nightmare on release day!

Thank you Simon for the detailed analysis. Hope iOS6 will arrive soon.
I’ev recognized as well that in Codea i didn’t get the full resolution of
the Retina display as well. HEIGHT and WIDTH are the same as on older devices.
Is that a bug with the display as well or can thet be fixed by CODEA?

@Doc that is correct behaviour. It ensures you get the same behaviour across all displays. Elements are drawn at double resolution on retina displays, but the logical canvas size is the same.

Your display is rendered at 2048x1536 but the logical resolution is 1024x768.

The image class works the same way. Codea internally manages your images at high resolution so you don’t have to worry about it.

I’m new to the Apple world. I had the idea that when a device provides me with a higher resolution I should be able to use it in my programs. If I cannot address and
set pixels in that resolution it’s not of any use. Maybe an upscaled image can be
makde look better by applying some antialiasing on a higher resolution displays, but that’s a very indirect way. I wish I could use that higher resolution for my programs and graphics.

@Doc you can most certainly address pixels in the full resolution. Just set your positions to half-pixels, they translate to full pixels in retina resolution (and half-pixel offsets in non-retina).

(E.g. logical screen location 512.5, 300.5 will really be pixel 1025, 601 on your retina device.)

I think you misunderstand how it works.

All your graphics are rendered in 2048x1536 resolution.

If you render ellipse(0, 0, 200) it will really be rendered at 400 pixels in diameter. It will be the same size as it is on a non-retina iPad, however, because that device is half the density. It will appear much sharper on a retina device.

This is actually the way all retina iOS development works. Even native Objective-C development treats retina devices with their “logical” resolution. It makes perfect sense, because that way you get equivalent layouts on both devices, but your retina devices can produce much more detail.

If you have custom graphics, Codea will automatically load “@2x” versions of the graphics if they are available. This allows you to create high-detailed artwork for retina displays, while maintaining full compatibility with non-retina devices.

(Edit: by the way, I wouldn’t advocate using half-pixels in your retina display apps because they will lie on half-pixel boundaries when run on non-retina devices. This looks bad and is really unnecessary.)

Thank you for all the details. As I said, I’ve never developed on any iDevice or Mac.
It’s the first time I came across any ‘half pixels’. My head is trained to that
anything on a display is just ‘integers’. Guess I’m getting old :slight_smile:
Still a waste of resources to me, they use ‘float’ numers and arithmetics for basic
2D graphics. Of course, it has some advatages as you mentioned.

.@KilamMalik I’m not sure. Hopefully Apple releases an update for iOS 5.x that resolves this issue on retina displays, but it is entirely in their hands.

I suspect you could make a tron-like game without a retained backing store. It would be more complex, but you could have the tron bikes leave a trail built out of a mesh.

Ok, maybe the problem is not as big as only ipad 1 will be excluded from ios 6. but retained mode will work there :slight_smile:

I fear a long trail will be slow even with meshes. Is there any possibility to draw in a screen sized image and then render that each frame fast enough? I tried and got 3 fps, but maybe I did it wrong.

I think meshes will be fine even if you get tens of thousands of triangles on screen.

We’ll be improving the render-to-image speed, but if anything I would recommend drawing to a smaller image (half or quarter resolution) and then upscaling it.

right, opengl should be able to render that in time. I think I have an idea what caused it to be slow. I will give it another try.

should i open a render to image speed ticket? didnt find one yet.

@Simeon, is there any chance this gets fixed in ios 5 too? I plan to create a tron like game as my first app store post where I dont have a solution other than retained mode. i know that ios 6 will be out soon, but there will be some people who dont update for some time. Is the bug maybe gone when I compile this as ipa finally? I would like to not work in retained mode, but all my tries were too slow.

I’ve opened the issue here https://bitbucket.org/TwoLivesLeft/codea/issue/198/improve-setcontext-speed

With mesh(), make sure you allocate the entire mesh with all its vertices at 0,0, then construct your path with the vertices in the pool as you go. This prevents re-allocation.