I'm new to the site and also iOS developing as well, but I have experience with other developing platforms.
I have been studying and playing around with the TweeJump source code and I want to update it to Retina graphics, I have made my own but I'm not sure how to implement them properly. Does doing this cut off support for non-retina iPhones?
Some of the images are in a sprite, which I'm not familiar with.
If I just change all the images to high resolution ones, what problems will arise and how can I resolve them?
Please excuse my beginner knowledge. I will really appreciate ANY help you can offer.
Regards.
Updating your game to support Retina display is easy if you have the original non-rasterized (e.g vector) graphics for the images. Just export the graphics as twice as large as the SD images and append -hd (or -ipadhd for iPad) to the part of the filenames before the extension. Just make sure your app delegate calls [[CCDirector sharedDirector] enableRetinaDisplay:YES] and you are good to go.
Does doing this cut off support for non-retina iPhones?
Absolutely not. As long as you retain the SD images.
Some of the images are in a sprite, which I'm not familiar with.
You mean "spritesheet"? This is one of the situations where you need to have access to the original vector graphics for each individual sprite. Plus, you need to use a spritesheet editor in order to generate the HD version of the spritesheet. I recommend TexturePacker.
If I just change all the images to high resolution ones, what problems will arise and how can I resolve them?
Make sure to retain the SD versions as well. One of the problems that may arise is if you have a spritesheet with the size of larger than 1024 x 1024 for the SD version. The HD version will have size larger than 2048 x 2048 which OpenGL ES 1.1 cannot support. You would need to break the spritesheet into more pieces or convert to OpenGL ES 2.0 (i.e. convert to cocos2d-iphone 2.x).
Related
I am writing an android game with Libgdx. I want the possibility to port it to iOS in the future. I read some comments that all image assets need to be sized in multiples of two for iOS. Is this true for all assets/textures and do the width and height need to be the same, ie: 256 X 256 or is 256 x 128 OK?
I am pretty sure that iOS supports any size, as I never heard that there's a need to transform downloaded images to other sizes to show them.
I know for sure that I never encountered an Android phone that does not support any texture size. I had my game released with different texture sizes for a year without problems until I switched to using a TextureAtlas. That's what I would recommend you, too.
If you are using Scene2d.ui and a Skin, just use SkinComposer to create your TextureAtlas. If you don't use Scene2d.ui, you can use TexturePacker GUI.
For my SpriteKit game I am using a single pdf vector graphics for my SKSpriteNodes rather than many png sprites for all device resolutions for every entity in the game. the benefits of not having to worry too much about the graphics of the game have dramatically helped but my question is simple, would using vector graphics be a bad idea performance wise?
Wait, you are NOT using a PDF as texture for the SKSpriteNode
Instead you are probably using a PDF into the Xcode Asset Catalog right?
In this case, first of all this is a really good idea and it does NOT impact the performance of your game.
Infact when you load a PDF image into the Xcode Assets (and you set the Scale Factors to Single Vector), you are not using the PDF into your app or game.
As soon as you compile the app, Xcode automatically generates the PNG versions for the several resolutions.
E.g. if you game does support any device running iOS 9 then Xcode
automatically generates the 1x, 2x and 3x PNG (bitmap) images from your
original PDF (vector).
Another great benefit of this approach: if in the future Apple does release a device with a 4x pixel density, Xcode will likely be updated to support that and you'll just need to recompile your app to automatically generates the 4x images.
Answer
So the answer to your question is: NO. The PDF image will not impact your game performance simply because the game is not using the PDF, it's using the PNG instead (even if you can't see it).
I am developing a cocos2d game. I need to make it universal. Problem is that I want to use minimun amount of images to keep the universal binary as small as possible. Is there any possibility that I can use same images I am using for iphone, retina and iPad somehow? If yes, how can I do that? What image size and quality should it be? Any suggestion?
Thanks and Best regards
As for suggestions: provide HD resolution images for Retina devices and iPad, provide SD resolution images for non-Retina devices. Don't think about an all-in-one solution - there isn't one that's acceptable.
Don't upscale SD images to HD resolution on Retina devices or iPad. It won't look any better.
Don't downscale HD images for non-Retina devices. Your textures will still use 4x the memory on devices that have half or even a quarter of the memory available. In addition, downscaling images is bad for performance because it has to be done by the CPU on older devices. While you could downscale the image and save the downscaled texture, it adds a lot more complexity to your code and will increase the loading time.
There's not a single right answer to this question. One way to do it is to create images that are larger than you need and then scale them down. If the images don't have a lot of fine detail, that should work pretty well. As an example, this is the reason that you submit a 512x512 pixel image of your app icon along with your app to the App Store. Apple never displays the image at that size, but uses it to create a variety of smaller sizes for display in the App Store.
Another approach is to use vector images, which you can draw perfectly at any size that you need. Unfortunately, the only vector format that I can think of that's supported in iOS is PDF.
I'm writing an iPhone app that is quite heavy on GPU memory. Some of the textures are created procedurally by the app, which means that I cannot compress them to PVRTC to decrease their on-GPU size (and thus memory).
Does anyone know of a library that does this?
The closest I found was PVRTexLib ( http://www.imgtec.com/powervr/insider/powervr-pvrtexlib.asp ) but that is for MacOSX, and not iOS.
I found this question which is similar : Convert .png to PVRTC *on* the iPhone but they took it to a different direction (on why you shouldn't want to do it).
However, my app uses OpenGL so I do benefit greatly from being able to use PVRTC.
Does anyone know of such a library?
PVRTexTool from Imagination includes an SDK and a pre-compiled library for a number of platforms, including arm. That should be linkable to an iPhone executable.
https://community.imgtec.com/developers/powervr/tools/pvrtextool/
However, maybe more interestingly, can you write shaders that re-map the colors as needed? You don't need to re-compress the texture, or change the bits of it at all, if you can apply the function you need in a shader.
In case you are familiar with the Flixel game engine, open sourced here:
https://github.com/ericjohnson/canabalt-ios/tree/master/flixel-ios
How would you go about adding support for retina graphics? Like retina sized textures.
I tried adding #2x atlas pngs and they seem to load, however I guess the offsets will be incorrect as specified in the atlas plist. Changing the plist (load retina atlases for retina devices) with correct offsets surely loads the graphics correctly, but the textures themselves generally shows up too big, and other problems seem to occur.
Progress update:
As noted above I'm creating separate texture atlases for high res graphics - I guess this would mean I would need to have a complete set of high res graphics (or none at all) to make things simple. This makes the graphics load correctly (or the offsets are incorrect of course if using lowres atlas plist)
When creating FlxSprite:s, I don't use the shorthand static creators, but the init* constructors, specifying the modelScale parameter using the device's scale (will be 2.0 for retina devices, 1.0 for other). With this the graphics also show up with correct size on screen no matter retina screen or not.
What's left is make the retina versions use the correct resolution because somewhere the texture itself seems shrunk, then sized up again producing a blurry, incorrect effect - not the original high res image. I'm guessing the last culprit is somewhere in SemiSecretTexture class...
Progress update again:
I was likely just wrong above. I think I found out how to do it. No need to set modelScale to 2.0... I might sort out the details and provide the answer later :-)
I guess there's no straight forward way to do this, but when you instantiate your class derived from FlxGame, don't use YES in the zoom parameter. For starters. Then you'll have to load different atlases for retina and non-retina. Not sure what happens with iPad support from there however. Then when loading textures for FlxSprites, you need to specify the "device scale", which would be 2.0 for retina devices - get it from [UIScreen scale]. This would make retina and non-retina work good for FlxSprite. Then FlxTileblock (and possibly other classes) is another story which I haven't solved yet.