External sprite sheets

[haligalaph]

Does SpriteBuilder support external sprite sheets made in Zwoptex or TexturePacker? At present moment after adding png and plist files of sprite sheet, SpriteBuilder shows only png file in its resource inspector.

[jtwigg]

It looks like it used to but the behavior has been degraded since SpriteBuilder started largely producing its own SpriteSheets.

I'll see if I can get it back up and running quickly enough.

[KingOfTheHuns]

+1 for this. I think it is very important to be able to use your own tool to create the sprite sheets.

[vlidholt]

This would be a really nice to have feature, although it is not as easy to support as one could think. SpriteBuilder automatically resizes images (even when building the sprite sheets). Pre-made sprite sheets cannot be resized.

A possibility could be to force the user to provide them in a specific format – similar to how the bitmap fonts currently work. Another possibility could be to extract all the sub-images from the sprite sheet using some sort of import function.

[haligalaph]

The main reason for using external sprite sheets for me is that Zwoptex has much more options. In most cases SpriteBuilder's generator is all you need. But sometimes you have to manage sprite sheets' creation. For example, several times I had to forbid rotation for some sprites. So extracting sprites and recreating sprite sheet will break all advantages of external editors. Maybe SpriteBuilder shouldn't autoresize images from external sprite sheets and user is responsible for providing all necessary sizes?

[KingOfTheHuns]

I see two use cases for external sprite sheets here

Use case 1)

In this case we don't want that SpriteBuilder to manage resources for the app i.e. SpriteBuilder is only used to create layouts/node graphs, etc using the existing assets included in sprite sheets. Basically the requirement is that SpriteBuilder should be able to open/use the provided sprite sheet files. The format is not a problem because the sprite sheets should be provided in the format that cocos2d supports e.g. sprite_sheet.plist/sprite_sheet.pvr.ccz, etc.

In this case the developer could provide the sprite sheets using the usual folder structure:

sprite_sheets
|-- resources-phone
|   |-- sprite_sheet1.plist
|   |-- sprite_sheet1.pvr.ccz
|   |-- sprite_sheet2.plist
|   `-- sprite_sheet2.pvr.ccz
|-- resources-phonehd
|   |-- sprite_sheet1.plist
|   |-- sprite_sheet1.pvr.ccz
|   |-- sprite_sheet2.plist
|   `-- sprite_sheet2.pvr.ccz
|-- resources-tablet
|   |-- sprite_sheet1.plist
|   |-- sprite_sheet1.pvr.ccz
|   |-- sprite_sheet2.plist
|   `-- sprite_sheet2.pvr.ccz
`-- resources-tablethd
    |-- sprite_sheet1.plist
    |-- sprite_sheet1.pvr.ccz
    |-- sprite_sheet2.plist
    `-- sprite_sheet2.pvr.ccz

SpriteBuilder would pickup the sprite sheets from the folder corresponding the device the layout is being made e.g. phone or tablet.

Use case 2)

SpriteBuilder could drive external sprite sheet generator apps e.g. TexturePacker when creating sprite sheets. This could be done e.g. via script API. TexturePacker provides command line API to generate sprite sheets.
SpriteBuilder could come with some default scripts that the developer could modify to add additional options.

I guess probably use case 1) is more common since TexturePacker (and I assume other sprite sheet makers) can already be integrated to the Xcode build process. So, SpriteBuilder only needs to be able to use the existing sprite sheets.

[vlidholt]

I think I would rather improve the build in sprite sheet generator so it can do whatever the other tools does. For instance, adding support for not-rotating images would be pretty easy to add, but what is the use case?

[haligalaph]

I think it is better for SpriteBuilder to focus on its main use cases, rather than on implementing improved sprite sheets generation. It still has a lot of things to do. In my opinion trying to implement all things in one IDE is a wrong way. Why then also not to implement Glyph functionality? I don't mean, sprite sheets generation shouldn't be a part of SpriteBuilder. It is very useful and saves a lot of time. But good IDE should be flexible. So I think, SpriteBuilder should support external sprite sheets, rather than has its own super complex sprite sheet generation. Of cause it is not high-priority task. At present moment If you need sprite sheet created with TexturePacker, you always could replace SpriteBuilder's one after publishing. But it adds one more step, and tools like SpriteBuilder are made for reducing such steps. So I think one day this functionality must be added.

[KingOfTheHuns]

I completely agree with @haligalaph.

[fallhunter]

I completely agree with @haligalaph. I like spritebuilder, but I think it should be more flexible. sometimes I just want to control the resources just because 1) the 'managed' way cost too much disk space. 2) I need switch the resources according to language as well as screen size.

[NickyWeber]

+1 for using external spritesheets. The power of SB is its visual editor for nodes and animations. That's something other tools don't provide.