Optimizing Graphics(AutoBatch)

Optimizing Graphics(AutoBatch)
0

#21

I just can say - when I used another packed - got no problems with that images. It was old game made by cocos2d-iphone and SpriteBuilder created by Apportable. I used TP first but then just packed some pvr with build it packer. So for me it’s obviously packer problem and I know you not really try to fix this and believe that it’s not TP problem. It’s rare and sometime very specific for images. Also, some people subjectively can’t see that jitter. It’s required a lot of time even to make you start believe its happens. Also, I remember that adding some more images into spritesheet - so it’s just re-positioned sprites on the texture inside - gives better results after that, but still with some small jitter.


#22

You say that you can easily reproduce the issue. Why don’t you send me a project (please use dropbox or something else, send me the link to support/at/codeandweb.com) with some sprites, the .tps file and a simple scene that shows the problem. If the problem is something caused by a bug in TexturePacker you get 1 free lifetime licenses for TexturePacker, SpriteIlluminator and PhysicsEditor.


#23

how do you “unload a spritesheet” for previous level ? when some one goes on to level 2 and that has a new sprite sheet not the same one as level 1


#24

it’s possible to call common-spritesheet-0.png (for UI items) only once even though common UI items will be used on different scenes ??


#25

You have to keep track of the name of the sprite sheet, and when you no longer need it, call this:

SpriteFrameCache::getInstance()->removeSpriteFramesFromFile(spriteSheetFilename);

then you need to call:

Director::getInstance()->getTextureCache()->removeUnusedTextures();

Just make sure you understand how all of these work, otherwise you’ll run into other problems. Look through the source code for these methods, and learn how they work.


#26

I don’t understand what you mean. Once a sprite sheet is loaded, it stays in memory until it gets unloaded, so you can use any images in the sprite sheet at any time via the Sprite::createWithSpriteFrameName(…).


#27

sorry I meant if created the spriteframecache in menuScene(for UI items), will it be accessible from all my levels (like pause image, game over image , etc) i dont know if this is possible?


#28

There is no reason it wouldn’t be available, because as I mentioned in my previous post, it will stay in memory until it gets unloaded. Also, if you’re not sure if something is possible, try it, quite literally, write code to test the functionality, and at least then you can learn how it all works.


#29

“The maximum texture size for mobile devices should not exceed 2048.” what if I have a sprite sheet that is 2200 in height, and 960 in width ? would this not count as exceeding 2048 ? since the width is smaller than 2048 ? Im trying to fit in the background with 6 other real small images I have for my level, but not sure if it will cause it to crash on some android devices?


#30

This is also device specific also. More modern devices you can have larger sheets.


#31

Do you know if a background image that is 2200x960 .png would crash On a device that has a 2048x2048 texture limit?


#32

hmm, you know, I have never tried it. I set my spritesheet limits from the start to never grow past a supported size. Can you chunk up your spritesheet to stay under the size limits?


#33

the thing is I set my design resolution to (960, 1704) and my resolution policy is set to fixed_width, so I had to make the background taller than 1704 to fit iphoneX and galaxy S8’s but I’ve ran the app on some old small androids running 4.0.1 that have like 3.5" screen size and it didn’t crash so I think I should be good :slight_smile:


#34

The 2048 limit is for both width and height, meaning the max is 2048x2048, so 2200 x 960 will not work on any device that has that limit. As slackmoehrle mentioned, some devices allow for 4096x4096, but you would need to check for such devices, and use a separate set of resources for them to make sure your app still works for the 2048x2048 devices.


#35

As per my experience, for Android its vary as per devices. Some device will load such BG even though they had 2048 limitation, some wont.
But you should avoid such size of BG for 100% crash free game, if you are targeting those devices.


#36

@smitpatel88 @R101 do you guys know if any devices with those limitations so I could test ? By the way I’m not using a sprite sheet it’s just a png with that size 2200x960 not sure if it makes a difference ? I tested on a small android device that seems like it wouldn’t support that size and it just crops the image since I’m using fixed_width


#37

These were the phones android 4.0.1 & 4.1 about 3.5” screen and they didn’t crash I would assume they have a 2048x2048 limit


#38
Apple iPad 3			4096
Apple iPad 2			2048 / 4096
Apple iPad			2048
Apple iPhone 4S			4096
Apple iPhone 3G S		2048
Apple iPhone 3G			1024
Google Galaxy Nexus		2048
Google Nexus One		1024 / 2048 / 4096
Google Nexus S			2048
HTC One S			4096
LG P880				2048
Motorola Xoom			2048
Samsung Galaxy Tab		2048
Samsung Omnia2			2048
Samsung OmniaHD			2048
SonyEricsson Xperia Arc		4096
SonyEricsson Xperia Play	4096
SonyEricsson Xperia S		4096
T-Mobile G1			1024

Source


#39

One more question what if I cut the background in half and loaded it as 2 separate 1100x960 png images would this make a difference or its the same thing ?


#40

No, its same only.

You can check with older iphones or ipad.

Check this device Max supported texture size, Google it to find out. (May be some app will tell you the same)

Yes, this will work. I remembered doing same thing 4yr back :slight_smile: