Release Candidate 0.11.0.3 is available!
Release Candidate 0.11.0.3
- Added support for Android 4.3 and 4.4
- Fixed Rules and Loops not expanding correctly when created minimized
- Fixed "Save As" not working on computers with FileVault enabled. No longer deletes images and sounds.
- Fixed white box appearing at the start of animations
- Fixed "Change Image" drop down not updating after new images were imported into project
- Fixed Blend mode not being set correctly for particles
- Possible memory leak with scene unloading
- Creator will not open if your GateKeeper settings are set to "Mac App Store" or "Mac App Store and identified developers"
- See forum post for additional information about changes to Animation behavior and supported image formats
Changes to Animation Behavior
Due to the nature of our behavior system, we cannot guarantee the order of execution of behaviors. We will occasionally make changes to how we execute behavior to improve performance or fix bugs.
First, some users had problems where animation didn’t play at the correct frame rate. We’ve fixed that issue, but in fixing that issue we exposed another bug. In older versions of the engine, we start animation as soon as the behavior is active. Unfortunately if the images haven’t been loaded yet, you’d see mismatches in what was expected to display and what actually displayed.
With GameSalad 0.11.0, we’ve made a change to the Animate behavior where animation won’t start immediately upon trigger of the behavior. It will start after all the images are loaded. If you haven’t marked the animation frames for preloading, then you may see a slight delay between the activation of the Animate behavior and the animation starting. This delay happens as we wait until all of the images are loaded into memory before playing the animation.
If your animations are time sensitive, we suggest you mark the animation images for preloading.
Supported Image Formats
Based reasonable assumptions from most people's experience it makes sense to do all you can to make your images as small as possible on disk. Small images load faster on the web, right?
Things work a bit differently on mobile:
1) Smaller images load faster, right?
On the web, the biggest bottleneck is network latency / transfer speed. The time to download an image from a server is so much larger than any other part of the image loading process that you want to get your images as small as possible. This assumption doesn't work on mobile. On modern mobile devices, images are loaded from flash memory rather quickly. So the time to decompress the image is a much larger part of the equation. So on mobile smaller file size doesn't always equal faster loading. It's actually faster for users to load an image that is in the graphic's system native frame buffer format at full size than it is to load a compressed images at a fraction of the file size!
2) Smaller images take less memory. In the GameSalad engine, we take every image and expand all the bits into memory. So no how matter how small your 1024x1024 image file with alpha, when you load it into memory it will always take up 4MB of RAM. Squeezing a few KB off of your image file won't help it take up less memory. If you are really concerned about memory, then design your images to have smaller dimensions but in a style that will stretch well.
3) Apps are shipped compressed. Both Android APKs and Apple IPAs are zipped formats, so you will have further savings in download size in the final product from this. Everything in your game will benefit from this compression including images and music! They won’t be as compressed as they would be in the specialized formats for these assets, but they will be smaller than you see them on disk as you work with your game.
Image formats are a tricky issue. Even within a single format (e.g. png or tga) there are many variations. The 0.11.0 GameSalad engine has changed how we load images to increase performance. In order to get this faster loading and render performance we need to get stricter on the file formats we support.
To this end we will not be supporting png images that are compressed using libimagequant / pngquant or any other png images that modify pngs from what you would normally save using the standard save formats from your image authoring software (i.e. Photoshop, Gimp, etc). This includes running images through tools like tinypng.com or Pngyu.
After the 0.11 update, we will be moving away from png as the preferred storage format and going to one that will provide better performance for the game engine. This format will employ some clever magic to make image files smaller but still much closer to what the devices uses in memory. This new format will save both disk and memory space and will decrease loading time tremendously. They'll even have the added benefit of making it much harder for people to break open your game and steal your images!
For your existing project you should either drop the original images you had before running the compression tools or run a script to convert them all back to more standard index or 32 bit PNG images.
We're sorry if this short term change hurts your projects in the short term by making the bigger,
but this change is setting things up bigger, better (and faster) things!
Report Any Bugs
If you find bugs in the Release Candidate, let us know! We'll be watching the forums and support tickets for info on this. Once we're all happy with the state of the build then we'll make it stable.
Take a moment to review the "known issues" section of the release notes before reporting any bugs. No need to duplicate reports on what we already know, right?
Thanks for your help!
Go Get It!
See the release notes here:
Download the release candidate here:
Scroll down until you see "Release Candidates"