Ejecta Thread

0plus1

I have just compiled the game I made using Ejecta. All is working well and performance is awesome especially on the iPhone 5 :)

I do have some questions, hopefully you can help me out.

1. Do you suffer from any performance loss each time you exit to iOS main menu and back again into your game? (without quitting the game itself). For mine I noticed it wasn't as smooth as when I first launch the game.

2. How do you go about fixing the different screen ratio sizes between iPhone 4/4s and 5? I created my game with iPhone 5 in mind, so when I tried it on the iphone 4 it scaled with black bars on the side.

Thanks in advance.

— yeah, speed is amazing in Ejecta, is waaaay faster than cocoonJS, especially with the last updates.

1) I never noticed that, are you using:

document.addEventListener('pageshow', function() {

    cr_setSuspended(false);

});

document.addEventListener('pagehide', function() {

    cr_setSuspended(true);

})

I'll test it and report.

As for the screen sizes that is not an Ejecta related issue, I made my own scaling library which basically stretches the background to the window size, there are threads about this, every game is different, you might want to just stretch the background and keep the action in the center or to move around content based according to the aspect ratio. But this is completely off topic, I suggest you either search or open a new topic because it's a very long topic to discuss.

—

Maybe this will help you, info from Ejecta author:

This will stretch the canvas over the whole screen, regardless of

its internal resolution:

canvas.style.width = window.innerWidth;

canvas.style.height = window.innerHeight;

It's in the documentation:

impactjs.com/ejecta/overview

Wow, Ejecta is getting better and better every day. 0plus1 has done a great job on the unofficial exporter . Too bad I had to cancel my apple dev account ( had a second kid, no time for hobby programming) . Great work everybody! Hopefully this will become an official exporter when I come back to the apple dev program.

0plus1 sorry, I'm still relatively new to C2. How do I add in those line of codes?

szymek Cool. Thanks for the info, will check it out.

— Mine is still good for another 6 months and I have only released one game so far (paid someone for the programming). So might as well try to make the most out of it :D

0plus1

1. Do you suffer from any performance loss each time you exit to iOS main menu and back again into your game? (without quitting the game itself). For mine I noticed it wasn't as smooth as when I first launch the game.

I have it too at my end, but only with the beta version: if i use the last stable one, the pb is not here at all, and everything works well.

Maybe try to use the stable version if it was not already the case. Otherwise i don't know, maybe try "webgl" off.

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

— in the index.js file

—+1:

I don't know if I can ask you that, cause I don't really understand how far you can go in the work with Ejecta, and i'm far away to be a programmer, but do you think we can expect to have someday the memory manager (the layout by lauoyt loading) working on Ejecta ? It would be incredible, but I suppose it's linked to the improvements in webgl of Ejecta.

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.

Thanks for your answer, it was very clear. :)

—+1:

I know it starts to be off the topic, so i will not be long, but i tried to use the URL request in empty sprites and it works very well to load an image (with effectively a slight delay), but it stays in the ram of the project once it's loaded (well, at least i din't find how to clear it from the ram if it's possible), so it's not exactly like a layout by layout loading, but it can be nice to reduce the time of the 1st loading for example.

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.

0plus1

Not sure if this is off-topic or against Scirra forum rules but do you think you could share with us the name of the games you have submitted to the AppStore that was compiled using Ejecta?

The reason I asked this is because I would like to see how well a game can run on an old phone like the iPhone 4.

When I compiled my game, it runs well on iPhone 5 but terribly on the iPhone 4, to the point that it's beyond playable. (below 30 FPS)

Personally, I would prefer to make web versions of my game using Construct 2 while using a proper programming language for developing on mobile platforms (which I'm learning) but that takes time. I'm hoping to just get something up that's playable on at least an iPhone 4. Currently my Apple dev is active but doing nothing *ouch*

— 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.

—

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.