www.iforce2d.net

I'm almost ready to buy this amazing tool, but I am wondering if RUBE is compatible with Texturepacker (http://www.codeandweb.com/texturepacker)?

The output file exported from RUBE contains information about the position, angle, and size of images, and the body they are attached to, if any. I have not used Texture Packer myself, so I don't really know what you are expecting when you say "compatible"... perhaps you could elaborate.

To be more specific, the main properties for each image are exported as JSON text like this: You would load this into your program, so you then have all of these properties available to load the image however you need to. What happens from that point on will depend on the target platform and rendering API you are using.

Although some of the RUBE sample loaders do actually load and render images (C++ using OpenGL textures, cocos2d using CCSprite, js using HTML5 image, SFML using sf::Sprite), these are provided as an example usage rather than a recommendation.

What I mean is - is it's compatible with spritesheets?

And is there any example on how you load spritesheets from, for example, Texturepacker? (which is a vastly used tool)

Thanks again!

But what does 'compatible' mean? If I answered "yes", what would you expect to be able to do?

If you are asking whether you can load an already processed spritesheet into RUBE and use the images from it individually, the answer is no. I did have some discussion with somebody a while ago about that, but it seems to me that misses the point of a texture packer.

If I understand it correctly, packing textures into spritesheets is one of the final steps in creating a build of your game, because the objective is to reduce file sizes and load times for the end user. Ideally spritesheets are automatically generated as part of the build process, because they can be different every time depending on how sprites have been edited, and which sprites are actually used in that particular build, and which sprites have been chosen as targets for packing, etc. As such, the spritesheet is generated data that you would not store as part of your source control system, in the same way that you do not store the compiled binary of your program - you store the source code that generated it. So at the content development and level creation stage, the spritesheet should be irrelevant because it has yet to be generated, and the individual images that will be put in it are subject to change, and your artists don't need to know how spritesheets work.

Thank you! Sorry for being somewhat fuzzy

You've already answered my question but just to rephrase myself:

"Is there a possibility to use the exported files from Texturepacker (compressed .pvr.ccz, .pvr.gz ..) and attach them to the bodies that has been generated by RUBE?"

This would be a great feature for an upcoming version of R.U.B.E!

That would be very unlikely, for the reasons outlined above. I would not say 'never', but I don't see any compelling reason, or any advantage it would bring. The only case I can think of is if you have already processed spritesheets but you don't have access to the original images, which raises other questions...

Looking at Cocos2d as an SDK example, I'll explain the assumptions I am making, and maybe you can tell me where I have it wrong and how packing textures before using them in a level editor is useful.

-----
In Xcode, you can set up the texture packing as a pre-build step (see the "To set up pre- or post-actions" section here), or as a separate target that is a dependency of your main project as recommended by Texture Packer's developer. My assumption here was that one of these methods would be used.

Once this is set up you can edit the original images anytime, and every time you build your app the spritesheets will be automatically built without even needing to open the Texture Packer GUI itself. TP is also smart enough not to pack things again if nothing has changed, so it should not slow your build down.

In your app, sprites can either be loaded from a spritesheet (eg. createWithSpriteFrameName) or from an image file (eg. CCSprite::create). My assumption here was that the spritesheet would be tried first, then the image file as a fallback if the sprite frame cache did not contain the desired sprite.

You could change whether the original sprite gets used by clicking the checkbox in Xcode to include it in your main target or not, and you could change whether the sprite gets packed or not pretty easily by adding or removing it from the TP project. Obviously you need to have one or the other enabled to make the sprite available to your app
-----

As far as RUBE is concerned, all those steps are downstream in the tool chain so they make no difference. There is no need for the level creation step to be aware of any platform-related issues such as hardware accelerated texture decompression. For example let's say you go with .pvr.ccz files because they are a good choice for iPhone, then sometime in the future you want to release your game on a platform that does not support them... or suppose Apple comes up with an even better compression format and TP adds support for it. Changes like that should only have an effect on the final compiled app bundle, but if you're using the already processed spritesheets as part of your RUBE scene, the change would backwash all the way upstream to your level creation! Would you really want to maintain separate versions of your RUBE scenes to accomodate various platforms like that?

Well I think I have said enough I have to admit I have not used TP for any projects myself yet, so let me know if there is something important that I'm not considering.