Forums » Impact Engine » Blitting / Non-fixed sprite sheets support?

I just purchased the engine a few days ago, so haven't had a chance to fully dive into the core to see how big of a change it would be, but wondering if any consideration has been put into supporting blitting (as its referred to in the flash world) or specifically the support for non-fixed sprite sheets. These would be sprite sheets created with tools like TexturePacker where it will pack as many images into a single sheet as possible, it supports the export of a JSON file for the data sheet which lays out the reference of each individual sprite.

For those curious as to what this all means a good simple tutorial is available here: http://www.gotoandlearn.com/play.php?id=140 to get an understanding of what this whole process is.

Anyways - just curious if there's any plans to officially support this - again I haven't looked too deep yet to see what changes would be required, but if its non on the upcoming agenda, then I may take a crack at it myself.

-Thanks-

I have a feeling it is not currently supported and would have to be for version 2.0 down the road, because it's going to break compatibility.

I actually got used to the Impact way of handling sprites after having using TexturePacker & Zwoptex for a Cocos2D game on iOS where you pack hundreds of textures in a single file. My experience is that Impact is good for small sprites, especially if you blow them up to get that retro pixel look, but really complex games with thousands of sprites is going to need the kind of support you're talking about.

For now Impact is great for lightweight games. The organization and logic of how it operates is superior to other game engines, but it's not as advanced when it comes to some other things.

@stahlmanDesign - I completely agree. Part of me loves the simplistic ways of Impact, but as I begin to use it, I immediately start to hit boundaries. For now, they can be worked around but I can definitely see areas for improvement.

Maybe I'll take a crack at basic support.

Essentially though, I think for this support, it would simply require a rewrite (or additional) Image class, and instead of assuming each tile is a fixed height/width, it would take in the start x/y and height with (data read from the JSON). But I think this would obviously break how Weltmiester functions, and Box2D might need re-worked (though I've seen where Box2D actually supports this in Cocos (with real polygon physics boundaries) - but that's getting off point.