Ashley that was on 147.

Just tested on 148 and everything works perfectly.

Thank you and sorry for the useless bug report :-(

weisdaclick Ashley gave you the right answer, Ejecta is not officially supported by Scirra (or me by that matter) is something I shared to the community, everything is 100% working on canvas2D (webGL doesn't work anymore with the new Construct 2 build but I'll release soon an update).

I always said this, Ejecta is not easy to use, it's certainly not a drag and drop solution. Every time I build my game I find some new quirk of Xcode that can take even half an hour to fix sometimes is just better to download Ejecta and start from scratch.

What I would do.

Disable any plugin.

Make sure you are not using tiled backgrounds.

Export with no compression, run exporter.

Download a brand new copy of Ejecta.

Run.

Check console for errors and post them here along with the line of code that generated the error.

Steps to reproduce:

1. Download my capx (https://dl.dropboxusercontent.com/u/1606950/tizenissues.capx)

2. Run on anything that is not tizen (including domless engines) (http://i.imgur.com/ypvkC1q.png)

3. Run on Tizen (http://i.imgur.com/ypvkC1q.png)

Observed result:

Tizen align text objects incorrectly

Expected result:

Should position text objects in right position

Browsers affected:

Tizen (device)

This happens in any positioning of text, not only on viewport, even texts positioned with integer values.

Sprites are correctly positioned, this is a pretty serious bug that is preventing me to submit to the tizen app challenge, I hope Ashley can give me some input to patch this thing and submit my game.

Thanks

Sure — sent you a pm with my skype

austin

Do you have plans for a bridge for Ejecta on iOS?

I don't really have time to look at your code but it would be really simple as it works like CocoonJS, a transparent webview over the accelerated canvas. I can help you in writing the code.

—

I just want to add my 2 cents about developing native.

People that have been around here long enough might remember how vocal I've been against the html5 choice. Truth is that Ashley made the right choice, the only "bottleneck" at the moment is mobile phones (Tizen excluded) the reality is that from the 4s onward the processors are so powerful that, unless you are biting more than you can chew they can run whatever game you might create.

I'm a full time programmer and while I have the skills I don't have time to code a game natively, I tried other game makers, but while honestly they run better it's not such a giant step forward to make me abandon construct. Ashley did an amazing job and some of the stuff you can do with Construct2 (layer rotations for example) would be very hard to program in another engine and are the byproduct of HTML5.

I think that when iOS8 comes out (killing 3GS and 4) there will be no issues in using construct on iOS, unless you want to do 3D (and if that's the case I suggest you learn unity) it's better to stick with construct2.

I honestly think that I would've never finished my games if it wasn't for construct, in the end, considering how tough the app store is now is way better to finish a game, as laggy as it can be than spending months learning a proper language and abandoning the project along the way.

If you really want to go native I suggest you look into corona which is an amazing engine, sorta in between a game maker and a low level language.

— it's not against the rules. Here's my game: itunes.apple.com/us/app/pigs-in-the-oven/id549867465

It runs fine enough (around 30fps), I test on the iPhone4 as well, it's the worst iPhone performance wise since they added the retina screen without increasing the processor power, I also have a 3gs and I get consistently 15fps more than the iPhone4. You have to be incredibly careful on iOS, even if Ejecta is the fastest wrapper currently (way more fast than cocoon) it's still limited, especially since Construct is not optimised for Ejecta.

goldentreee it won't unload from ram that's the issue.

There is no memory management in Ejecta (same goes for cocoonJS) so once loaded the image stays in the ram pretty much forever. In theory you could try to load a transparent png of 1x1 pixel on the same sprite, that should pretty much unload the texture, but I never tested this so it's a shot in the dark.

Hi Ashley could you tell us what parameters are you using for google closure?

It would help me immensely in my Ejecta exporter.

Thanks

goldentreee what you are asking is a very big issue, I'll try to explain why in the easiest possible terms. Please Ashley correct me if I'm wrong.

Let's start by saying that one of the biggest issue in Javascript is the lack of an explicit memory manager (there are project that aim to fix this) so everything relies on the browser. Modern browser have complex mechanisms to manage memory.

BOTH in webGL and canvas, construct requests the sprite images at startup (when the loading bar is on), at that point a browser makes note and says ok let me manage it, in the case of Ejecta (same goes for cocoonJS) instead those sprites get loaded as textures into memory right from the start! This produces a huge memory spike and with lots of sprites it can end up in the app closing (iOS has a memory manager that halts applications that perceives are hogging system resources and memory spikes are one of the triggers for halting).

Currently Ejecta doesn't have any explicit (or implicit) method to free a texture from memory (see here github.com/phoboslab/Ejecta/issues/166) this means that you have to be extremely careful with what you are loading into memory (see here: scirra.com/blog/112/remember-not-to-waste-your-memory).

As far as webGL goes the issue is still there, Ejecta apparently supports layout by layout loading, but since the images are decompressed into memory at startup is completely useless.

What Scirra could add is a concept of Atlases of images that get explicitly loaded at a certain point (with an action), you can do it right now by using the request from URL action on empty sprites, requesting a local image, I did that in my iOS game for loading of larger images, just know that there is a slight delay.

I hope I've been clear and precise.

NECROKRIEG that's actually very nice!

In the end I decided to go with a different approach.

The issue was that touching in another angle makes the object "jump" to the new angle.

goldentreee That's an interesting issue I'll play with this and see what's the issue.

— in the index.js file