It won't use nearest neighbor (blocky) filtering if that's what you mean. In the PNG loading code, I'm using a simple linear box filter so that it's safe to use with spritesheets. For the CoreGraphics loader, it will use whatever CoreGraphics uses.

kamikaze:

And for iPhone 6 and 6+ I will able to set custom scale? So like I did in thread about v3 for support this devices.

It will work almost identically to how it does in that thread yes.

kamikaze:

Pvr will be resized too in v4? For android we have only png, but for iOS I like pvr.ccz

Again, sort of. You can store mipmaps in PVR files which are pre-scaled versions of a texture. To "rescale" a PVR file, you just skip the largest 1 or 2 mipmaps. This lets you trade file size for loading speed. (This hasn't been implemented yet, though it should be very easy.)

It won't use nearest neighbor (blocky) filtering if that's what you mean. In the PNG loading code, I'm using a simple linear box filter so that it's safe to use with spritesheets. For the CoreGraphics loader, it will use whatever CoreGraphics uses.

Can you please provide some demo? If it wiil looks same as TP images, this will be wonderful.

slembcke:

It will work almost identically to how it does in that thread yes.

Sounds great!

slembcke:

You can store mipmaps in PVR files which are pre-scaled versions of a texture. To "rescale" a PVR file, you just skip the largest 1 or 2 mipmaps.

Not really clear for me. So lets say I have 4096x4096 pvr.ccz file, can it be used for all devices?

It will look identical to how Cocos2D displays a sprite with a 0.5 scale with normal settings

So it will be not ideal as from TP. I see..anyway better to see it directly for some of my games..

slembcke:

If you make a PVR file with mipmaps, yes. TexturePacker should have a checkbox for this.

No, I mean I want just have a like Hero.pvr.ccz 4x and with magic scale it can be used on iPhone. Creating mipmaps we doing in current cocos, tabledhd 4x and iphonehd 2x. So, the problem with resize pvr.ccz? If it will be just png no problems?

So it will be not ideal as from TP. I see..anyway better to see it directly for some of my games

I would guess TP uses bilinear filtering. The same way that the GPU or the autoscaling will do it. It might be something fancier like bicubic or lanzcos, but that seems unlikely when it just calls it "smooth".

If your 4x Hero.pvr.ccz file has mipmaps in it then yes, it will work. If you don't use mipmaps, then you need to make Hero-4x, Hero-2x, Hero-1x versions.

PVR is not a simple image format like BMP or PNG. It's specifically designed for storing GPU texture data. It can store several images in a single file. You can store an array of textures (like PhotoShop layers), cube map faces and mipmaps for each layer or cube map face. Using PNG, you would have to make a separate file for each image.

The file size will be about the same, you'll just have less files to worry about. You can't save on file size and improve loading performance. You have to choose one. (autoscaled PNG for file size, PVR for speed)

With the way you want things to work, the iPhone 6 and Plus would load the 4x art like you are now.

Yep. JPEG will work the same way as before using CoreGraphics to load them.

There aren't any new APIs for doing preloading. You would do it the same way as in v1/2/3. Ask the texture cache to load them early. Retain them somewhere if you want to guarantee they won't be flushed. I don't really know of anything we can do to make that simpler or more automatic.

It would be really helpful to get some additional file format support for packages. I haven't taken a look into it yet, but a couple of these sound like a low hanging fruit for at least the tool itself. I do love packages, as they allow for games as a service development without starting a manifest system from scratch. Anyways, brief list below:

Support for .atlas (helpful for Spine files)

Support .bmp (helpful in trimming file sizes for backgrounds and other images that do not require alpha)

Support for .json (helpful for everything, eg: configs, animationData, etc)

.atlas files: Probably nothing surprising in them (name, rectangle). Though it might be easier to convert them at compile time instead of adding more code for loading more atlas formats.

Cocos loads most of its image formats using Apple's ImageIO library which supports .bmp just fine. (there is even a test for it actually) That said, I'm not sure what advantages they have over 8 bit .png files or 2/4/16 bit .pvr files.

.json files: Apple provides the NSJSONSerialization API. It's almost identical to the one for working with .plist files.