Tokinsom yeah, I agree the whole thing could be a bit more streamlined ! And I do like the idea of keeping sprite sheets internally to make resource management easier. Plus it shouldn't prevent the user from editing individual animations, re-ordering frames, adding image points, etc. all these would just need to be kept as metadata in parallel of the sheets. Maybe for C3

Though I do see a point in re-slicing/re-packing the sprites ; automatic processing of large amount of resources can usually lead to better results than manual management. For example maybe several sprite sheets can be recombined into a single texture atlas, maybe some animation frames are unused and can be dropped from the export while keeping them at edit time, etc.

Yeah, it happens for a collection of very specific Y values ; these must be corner cases that are not dealt with properly in the collision logic

Tokinsom : oh, I see what you mean ! Thanks for clarifying Keep the sheet itself as a resource, instead of processing it and slicing it into frames directly on import. Indeed that makes resource management, especially animation updates, easier.

Though I think OP is mostly after building an animation from a spritesheet, regardless of the slicing, instead of manually importing one frame at a time, which is clunky and time consuming. Something C2 is capable of.

As for efficiency and performance, frames are packed into texture atlases when exporting anyway, so delaying the processing or not should be negligible.

I fail to understand the difference ?

Import a sprite sheet, slice as needed to separate all the frames, move/remove frames or adjust speed if required, and we have an animation good to go -

what am I missing that doesn't satisfy the initial request, i.e. importing a sheet to build animations

add sprite > sprite editor > animation window > right click > import frames > from sprite strip

I believe that's what you're after

You can already sprite sheets ; C2 tries to guess the sizes/rows/columns, but you can force the slicing to make it match your sheet

There's a "move to object", with option to place in front or behind another item.

I have little experience with Android, but I believe it is now possible by bundling expansion files with the app (while the app is still limited to 50Mb, the expansion files can be up to 2x2Gb), or using a downloader in the core game.

There's a System condition "Is number NaN" that you can use to breakpoint or output as log

Wrong layer ? Wrong blending mode ? Wrong parameters on the default instance ?

Just a few things to check, as creating sprites dynamically does not affect the quality.

One way or the other, it's still inconsistent - some Solids trigger a collision while some other instances don't ? And simply moving Solids that don't trigger collisions suddenly changes the behaviour.

I think I am using the Platform/Solid behaviours as intended, but the result is inconsistent.

Maybe Ashley can comment on the exact intended way to use/combine these behaviours, if that's not a bug

My guess would be that is has to do with space partitioning and cell boundaries during the collisions broadphase, if there's one ; objects sitting on the boundaries not handled properly would explain that sort of logic. Though it's a total gutfeel.

I've exported the test scene and uploaded to dropbox, if it's quicker to review the bug without downloading / opening / running the capx before looking into the issue.

https://dl.dropboxusercontent.com/u/526 ... index.html

All 3 red blocks are instances of the same object type ; the red block in the middle never registers a collision when jumping onto it *only* because it's at a specific y position. See original post for addition repro info