Arima Thanks for your suggestion. I just tried it and unfortunately did not work. The origin points will remain in the same place for each frame but because of the frame size differences the animation playback will 'jitter'. For cropping to work, the engine needs to take into account how much got cropped off in each frame and offset each origin appropriately.

newt Where was blame cast?

tgeorgemihai Spriter is an entirely different tool for an entirely different purpose. Please read the entire thread to get a better understanding.

Joannesalfa 90 degree rotations are standard optimizations when packing spritesheets. Think 'Tetris', where you rotate the shapes to make them fit tighter together.

I took the time to thoroughly explain the problem so that the community and project would benefit. I want Construct 2 to continue to improve, I thinks its a great application. It already supports independent origins with each sprite frame so supporting a third a party application would be pretty easy to implement. This definitely takes priority over less useful new features like Spriter as using a spritesheet is a requirement not an option. Every single Construct 2 user would benefit greatly form this, even Spriter users would benefit.

Let me reiterate by saying that If spritesheets were properly packed, the benefits would be HUGE. This isn't a small gain, or a good gain, this is a HUGE gain. It would not be uncommon to see a large reduction in file size, very large memory requirement reduction and FPS boost. All this without lifting a finger. All Construct 2 games would instantly gain that, no additional work, all done automatically for you.

The images were purposely not cropped because aligning different sized images to have the exact same origin would be incredibly difficult and nearly impossible to maintain (in case you change any image). Even cropped versions would still be incredibly wasteful.

Cropping is always handled by a utility or the engine itself. For instance in Unity 3D, all cropping, packing and rotating is done automatically for your 2D games. Even third party libraries such as TK2D do all of this. With other engines like Corona, Moai, Marmalade or cocos2d etc..., it is done externally with an application like the one I mentioned. You don't ever want to do this by hand, not only would it take many hours for a single spritesheet but it would be prone to being inaccurate.

Regarding your comment on duplicates. Please do tell the secret on how to add frames and avoid duplicates in spritesheets. Construct 2 should easily be able to tell duplicate images and not repeat them wastefully in spritesheets. This is a bug.

90 degree rotations are trivial and at the GPU(webgl) and software levels(canvas2d) have no performance penalty.

Data 'compression' used by graphic file formats such as PNG or JPEG, has nothing to do with any of the issues I mentioned. Data compression only saves on file footprint. Using something like TexturePacker(I have no affiliation with them) is not a third party dependency because it is completely optional. Only people wanting to optimize their game would employ this technique. Not using it (as you do now) would not prevent you from creating and publishing a game. Its a good idea to use third part tools that are not required dependencies. This is completely normal, all game studios use many tools in their development.

I went ahead and created a spritesheet with TexturePacker to compare against my current sheets from Construct 2. You'll notice in the TexurePacker output there are no duplicate frames, which is one of the optimizations I mentioned. The following spritesheets were constructed using the exact same graphics which consist of 28 unique frames. Construct 2 unfortunately duplicates frames in animations making the spritesheets even larger than they need to be.

Construct 2 creates two spritesheets, each 1024x1024 in size. This takes up a total of 8MB in memory. 616KB combined file footprint size. Construct 2 does this because it doesn't know how to 'pack' it efficiently into one. Notice how wasteful the spritesheets are with lots of empty space between the sprites. That empty space between the sprites is the real killer.

TexturePacker for the exact same graphics creates one spritesheet that is 512x512. This takes up a total of 1MB of memory. 350KB file footprint size.

As you can see, packing spritesheets uses much less memory, has a smaller file footprint and speeds your game up because the GPU uses less fill rate to render these sprites.

Aphrodite,

I don't have the time to create an example right now, but you can learn what a sprite packer does by simply googling it. This is all common stuff that has been used for many years. Here is a link to a third party sprite packer application: http://www.codeandweb.com/texturepacker

In that website you will learn the difference between a non packed spritesheet and one that has been packed. This may be a good way to add this important feature to Construct 2. Instead of having the Construct 2 team implement it, they can help third party developers add Construct 2 file support. You'll notice how that tool alone supports over 15 2D game engines, again this is all common stuff, everyone does it.

Thanks for your reply.

I am using r168 and duplication of duplicate frames definitely occurs on export. Please do tell if you know of a setting or configuration somewhere that I am unaware of.

In my case Spriter has no place as I am using prerendered 3D isometric animations. But that is irrelevant because the same inefficiencies I mentioned earlier affect Spriter. Unless Spriter completely bypasses Constructs spritesheets and creates its own packed spritesheets that are used by Construct. Is that the case?

In any case, optimized packed SpriteSheets is something Construct 2 is in desperate need of. I am very surprised it has gone this far without them. Imagine without any additional work, changes or any external plugins making your game much smaller and faster.

Is it in the road map to have Construct 2 optimize spritesheets? Spritesheets created by Construct 2 are incredibly inefficient. Other engines and tools pack spritesheets by trimming empty space around images and internally keeping note of how much got trimmed to properly maintain offsets. They also try 90 degree rotations on images to optimize space in the spritesheet. The effect is spritesheets that are much smaller. That makes the app size smaller and improves performance because the draw fill rate is also reduced.

Another inefficient area is with duplicated frames in animations. Currently if you duplicate a frame it actually adds a copy of that same frame to the spritesheet. The engine should be smart enough to avoid this.

These two optimizations would reduce the file size, download size and improve draw performance significantly. I sure hope Scirra is working on implementing this. This is standard with all 2D engines and severely limits the size of a game's content without it.

Thanks Sargas.

I created a family that contains 5 different enemy sprite objects. I have a ForEach loop of that Family and I would like to determine on each iteration the type of the enemy. Is there anyway to do this?

I have used Unity Pro and Gamemaker studio professionally and both can export to iOS and Android without any third party plugins at the push of a button. They both really do deliver on 'push to publish'. Extremely easy to use, no problems.

The price of a single Unity Pro License with Android and iOS exporting enabled is $2500. Gamemaker Studio about $800.

Thank you for the replies. Unfortunately I do not own C2 and cannot perform any testing. I don't want to purchase C2 and find out it does not have reliable socket communication on iOS and Android. From the research I've been doing online, socket.io is inherently not reliable for mobile and often fails for various reasons.

If anyone using C2 has tested socket.io reliability on iOS or Android devices please share your experience. This is vital to determining whether or not C2 can be used for a networked mobile game.    

Thanks

Hello,

I am trying out the C2 demo version and I have a question. Please forgive me if its been asked before. I would like to make a turn based game for iOS and Android that will communicate with a NodeJS server. Does the standard websocket plugin work correctly when an iOS and Android build is compiled with something like CacoonJS or PhoneGap? I am unable to try this with the demo build and would like to confirm before purchasing.

Thanks!