cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   eshirt
   Member

   I've converted my 0.8.1 game to 0.99.5b3 with support for Retina graphics and the iPad. It's fully Universal in that I have assets specifically for the iPad, and I'm not just displaying the Retina-sized game on the iPad.

   I'm wondering what everyone's thoughts our on app size. My app came in at around 9.5MB in version 1. Now it's sitting somewhere around 60MB due (mostly) to all of the new assets (for example, I've got 3 game maps that are 2x the iPad screen size, around 4MB each). I've run all my PNGs through PNG Genie, btw.

   My game is free, I'm not worried about sales per-se. But I don't like to restrict people from downloading my app over the cell network. I'm not even close to getting within the 20MB limit, so it may be a moot point, but I was just wondering how others have handled this with their games.

   Has anyone else had a game update that pushed them over the 20MB limit? Did it significantly impact your downloads?

   Posted 1 year ago #
2. 

   DonomaGames
   Member

   I cross the 20mb limit with an update a few months ago with Sniper Strike. From the data, I was pretty sure that it did not impact sales because I didn't notice a decrease. However, recently I found a way to chop 2.5mb from the binary and bring it below 20mb again. Sales are budging higher slightly.

   What I failed to consider originally was the size of the iPad market. iPad sales were probably making up for any decrease on the iPhone side so I probably lost 10% for months. From now on, I'm going to try everything I can to keep the binary under 20mb. I believe it matters.

   I chopped a further 3mb from the binary by switching from PNGs to JPGs. For some images and at certain qualities, JPG look just as good as PNGs and are only a fraction of the size. Going forward, if that isn't enough, I'm going to look at hosting high res files for users to d/l when/if they want those textures.

   Posted 1 year ago #
3. 

   Verisutha
   Member

   I think ours is running the the 80MB range now.. That is just normal, and retina. We are planning on doing a custom version specifically for the iPad.

   We have thought about setting up so the hires was an optional download. Although we have not done so you. It would drop our IPA below the 20MB size.

   Posted 1 year ago #
4. 

   Ben Kraus
   Member

   One way you could decrease app size is by using PVR textures instead of PNG's . . .

   Posted 1 year ago #
5. 

   eshirt
   Member

   @Verisutha - yeah, I figured 60MB for a universal (standard, retina, plus iPad) game wasn't that unusual.

   @Ben Kraus - can you elaborate? What kind of space savings can I expect? 20%? 50%? I've heard that quality decreases significantly with PVR, so I've never looked into it. These backgrounds need to be fairly high quality.

   Posted 1 year ago #
6. 

   Tim Knauf
   Member

   I just did a test on a 1024x1024 spritesheet. I produced a PVR with PVRTexTool and ensured that the PNG was optimally compressed using OptiPNG. The PVR came out at 524,340 bytes and the PNG came out at 808,170 bytes.

   However, most of the time you can really only consider PVR for photo-realistic style images. It leaves noticeable compression artifacts on drawings with crisp edges and flat colour.

   Where PVR is really good is if you need to save texture memory on the device. A 1024x1024 image will only take up 512kb of texture memory, rather than 2Mb (or 4Mb for an RGBA8888 image).

   Posted 1 year ago #
7. 

   eshirt
   Member

   Thanks Tim. Unfortunately the background is a football field - plenty of straight lines and crisp edges. I doubt that converting to PVR is going to get my 60MB game down to 20, but I'll keep it in the back of my mind just in case.

   I'll do a test just for the heck of it and look at the results. Who knows, maybe the compression won't be a factor.

   Posted 1 year ago #
8. 

   Dragyn
   Member

   One way you can try to cut down the graphic footprint is to use textures that can be re-used, instead of a full screen. Depending on how detailed/varied your football field is, you might consider using a seamless texture for the repeated pattern of the field (a single strip on one five-yard section, for example), then you can use the same texture over and over to build the field, and make the other elements (like the yardage numbers) as separate images you put over the top of the grass/lines texture. Not knowing your graphics in detail, it's hard to say if this would even be possible, but re-using graphics where possible is a great way to reduce your file size footprint. Also, if those reused textures are all on the same sprite sheet, it is still a single OpenGL call to draw them all, so you might actually get better draw performance on the iPad.

   Posted 1 year ago #
9. 

   JonKean
   Member

   For the non sprite sheet graphics, you could include just a single high res image and on the first app run generate the two lower resolutions (saving them off in the local document store).

   Posted 1 year ago #
10. 

    eshirt
    Member

    @Dragyn - Yeah, when I originally designed the fields, I wish I had taken that into consideration, but it was way before I knew that I'd have to have 3 different sizes. :) For now, I'll have to deal with one large image, but I'll certainly consider that next time I build a game.

    @JonKean - that's an interesting approach. If I understand correctly, you mean that the .ipa package would only include the -hd png files, then a one-time method is called on first launch that resizes them? I think this is definitely something to be explored (when I have more time :) ) but the only concern I would have is the possible confusion over calling some sprites from the local documents directory and some from the app bundle. I don't think the automatic Retina support in cocos2d would work with that as it is now.

    Thanks for the input - if anyone else has any experience or suggestions, I'd love to hear them.

    Posted 1 year ago #
11. 

    JonKean
    Member

    @eshirt yes, just the hd images in the ipa. Could resize/save all images on first start, or resize the images as their requested (might watch out for stuttering). Request textures through some helper method that figures out where the file is backed at, and only use the textures you create through that method (instead of passing in image file names to Cocos objects, since the auto retina support wont work as you mentioned). Alternatively could just modify Cocos to support it directly (would be much easier to implement, but then you have more work upgrading to newer versions of Cocos). I planned on doing this a few months ago, but was able to squeeze enough space from other places.

    Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.