Ok, we've been seeing some users having trouble with this, while for others it works just fine. After some digging, we think we've found a couple of issues.

First of all, CocoonJS searches for fonts by filename, and not by the internal font name. This means that if the font name is "my super font!", but your file is named "my_super_font_0.ttf", Construct should ask CocoonJS for a font named "my_super_font_0". We know this is not "standards compliant", but it was the easiest way for us to add this feature.

Also, there seems to be some trouble with some Construct exports we're getting, which instead of having a folder named "fonts", have font filenames that start with "fonts\" (which on Unix file systems is a valid part of a filename). This means CocoonJS doesn't see any "fonts" folder, so no ttf files are loaded.

We are guessing the way Construct generates the zip file doesn't correctly generate folders, but we're not quite sure yet. If you want to check if a zip file is correctly constructed, just unzip it on an OSX machine, and you'll see if the "fonts" folder is created or not.

Ok, I guess we have to step in here!

First of all, performance is and will always be one of our top priorities. We are usually forced to divert efforts away from performance improvements and into other features, but anything that could hurt performance is examined up close to make sure we're never slower than we were before.

As I'm writing this, we're giving the final touches to a time profiler system that allows us to check exactly on what sections of our code the CPU is stalled or unreasonably busy. This should help us enormously to track down performance problems.

However, just as Arima says, there are some things that are beyond our control, like hardware capabilities.

Android devices are getting quite good now, but most of the ones from 1-2 years ago have embarrassingly low specs compared to the iOS ones.

Also, the operating system itself is getting really fast now after "project butter", but Android 2.x is about as slow as you can possibly get for an OS. We've seen the same hardware going from 30 to 60 fps just because of an OS update :-

So, to sum it up, we'll keep doing our best to be as fast as physically possible. Miracles might take a bit longer to achieve ;-)

delgado

supportlyn@ludei.com

Thanks!

I suppose you didn't change nothing between versions, could you please send us the project to take a look? Thanks!

That's because our demo uses our native Box2D binding, while Construct exports don't (yet), so your exports don't get the performance improvements our binding can deliver.

The Box2D binding is not yet complete, and until then it doesn't make much sense for the Scirra guys to use it in Construct, as some features would just not work on CocoonJS.

As soon as our Box2D binding is able to everything Construct needs, integration will be a matter of minutes :)

Hi Koen,

Send us the HTML5 zip file and we'll take a look at it and see if we can figure out what's making it run that slow.

Hi everyone!

The Ouya project does certainly look interesting, but we don't have the SDK... nor the device itself!

From what we've seen, it looks like a pretty standard Android device with a couple of APIs on top to provide specific hardware support, so it shouldn't be very hard to provide full support for it.

However, unless someone sends us over a devkit (and we manage to save a couple of days to tinker with it), I guess it'll have to wait for the moment ;-)

Regards!

Hi Delgado,

We're mostly battle-testing our platform and making sure every part of the platform is rock-solid.

As for new features, we have quite a few things waiting for the next release, but most importantly:

• Revamped Facebook + GameCenter extension
• Improved (and optimized) Box2D extension
• In-app purchases system
• New ads subsystem for android (with support for more ad providers)
• Lots of improvements in the cloud system
• Support for user-selectable feature enabling/disabling (so we can remove unneeded permissions in android, like camera or billing).
• HTML parsing with divs support

I'm sure I'm leaving out quite a few things, but I think that's a good teaser for the moment ;)

Of course, some of those features might not be ready for release with the next update, so please have some patience if your favorite feature is not released right away :)

Hi guys!

Ok, a bit late here, but I think all this needs a bit of explaining on our part.

The Box2D extension is still quite incomplete in the last version we released, so there are several things that don't work yet. Contact listeners are missing, fixture support is incomplete, etc. We're working on improving support for all these things, but for the moment I'm afraid you'll have to wait, as making Construct support every feature of Box2D in CocoonJS would take an enormous effort from Scirra.

We hope to get that extension to a point where integration into Construct will take a few seconds, but for the moment it's not complete enough for that. We'll keep working, though.

You can take a look at how we're doing in our extensions repo here: bitbucket.org/ludei/cocoon_cocoonjsextensions

(Please note that only the "master" branch will work with the released version of CocoonJS)

Hi,

We're working on it and will be in our documentation with the next release. Anyway, remember that only premium users can use the extensions. Thanks!

Hi Ashley,

Yep, the "relatively" part is the tricky one. Because of how it's implemented internally it's not as easy as it would seem at first sight. We'll definitely have to think of something, though. We'll keep you posted.

Hi pavelkn,

The most likely problem is the device is running out of memory. We're working with the Scirra guys to find a way to load/unload images as they are needed, but for the moment CocoonJS loads all images on startup, and it needs enough memory to do that.

Also, image compression doesn't help at all for this, as images are decompressed when loading them into the graphics card. So, for the purpose of in-game memory usage, it's like if you were using BMP images (or uncompressed TIFF images for the ones with alpha channel).

There's also the issue of NPOT textures, which makes textures of 513x513 pixels use memory as a 1024x1024 texture, for example. Always try to reduce images to power-of-two sizes (or tightly pack several small images into a bigger POT one) if you are able to do so. Otherwise you'll be wasting lots of GPU memory.

Until we implement a way to load/unload images on request, our suggestion is to reduce the images size until they fit in memory.