Awesome info about the available scaling methods for the CAEAGLLayer. I'll add a menu to Retinasizer to allow switching between pixel-doubling, default, and trilinear modes. Nearest would give you == the look of the 3GS (+more performance) Trilinear would give you enhanced. That's a beneficial application is it not? I appreciate feedback from developers because I am only trying to provide a service to game fans disappointed in how poorly their favorite game looks on their next gen device. I don't want to argue about implementation woes on a per-game basis. My instructions are valid as to how simple Apple have made it to activate Retina graphics support. Obviously that's the minimum work required.
You're correct. "Nearest" mode will provide a screen that looks EXACTLY like that of the 3GS (once you've taken that bug with the Layer's contentsrect into account) and faster performance than the default "Linear" filter. Trilinear should give an improved upscaling experience, but at some additional performance penalty over the Linear filter. Anyway, interesting project you have going on... As long as the game in question was polygon based (rather than pixel art sprites) and never pushing the bounds of the GPU and CPU too badly this type of experimentation could be fun. The results will never be as good as someone purposely designing their game for the retina display (high resolution textures for example), but for many people it would be "good enough"
a little blurry on this as well (I am just art and design, not coder) our game uses cocos2d and all sprites are called from a couple of 512x512 texturemaps. the UVs are hard-coded in. if we wanna use retina display and double the size of these maps, will the (admittedly "nasty") @2x method be all that is needed, or will it require re-inputting new UV points? also things are pretty tight already, how much of a performance hit in general can we expect this to take? thanks for your help!
cocos2d does not use the @2x files. there is a current beta build avaiable where riq implemented his own method of retina support. previously it was up to the coder itself to handle the different resolutions and assets since you are using an older version of cocos2d either you let your coder implement your own method of support retina resolution and handling such files(like we did because well at that time that was the only solution) or you adopt youre code to the new version of cocos2d (which is still in beta, no stable release) as for performance, well that really depends on what you've been doing before you can find more information on the hole thing at the cocos2d website
I see - thank you for clearing it up. So no "easy" solution, but I'd rather not have it be a mystery and waste time doing the asset development. Maybe we can get it in there someday
Did the @2x graphics impact performance, or cause a big increase in file size? Or is there a better way to do it if you're working with UIImages? The OpenGL code looks dandy and should be useful
The @2x images are only used on the retina-capable devices and they are quite a bit faster, so I didn't see any performance issue. The file size jumped a LOT though. Previous version was about 9MB and current version is 19.1MB.
Interesting to know about the nearest neighbor filtering bug. I was wondering why that didn't work. I'll have to give it a try. Also, you do realize that trilinear filtering has absolutely no effect on upscaling, and only does anything when downscaling right? Probably all you are doing is forcing it to generate the mipmap levels when it only uses the largest one anyway.
Honestly, I have no use or interest in linear or trilinear filtering either for up or downsampling, so I cannot say if one looks better than the other. I can definitely confirm the Nearest filter and the bug as I detailed above, because I needed crisp edges for my 2D pixel art games (Spirit Hunter Mineko and Rogue Touch EX)
I tried kCAFilterNearest and contentsRect with my game and it did look better, but the contentsRect change seemed to cause random delays of 5-10ms per frame. Between that and the iPad problems it doesn't seem worth using.
I'm surprised that no-one's mentioned how the iPad affects all this. If you're creating a Universal app, then you have to consider this as well. The iPad will most likely require the @2x images, yet the built in support for '@2x' is ignored on an iPad. Also, be ware that the '@2x' trick doesn't work everywhere, just with the 'UIImage imageNamed:' method. Often in an OpenGL based app you won't want to use 'imageNamed' as it caches a copy of the image (wasting precious memory). And it doesn't work with PVR textures either... I'd suggest making a small wrapper / macro around anywhere you load images and handle the iPad case properly.
I'm surprised that the ipad doesn't use Retina graphics when you hit that 2x button. Given that the necessary support is baked in to 4.2.
