Ashley

I understand your point, but memory management in these DOM-less engines doesn't look easy to implement, they are partial implementation of a javascript engine, not a fully fledged browser and these kind of stuff is not easily achieved (although it might be implemented in future).

This topic encompass CocoonJS as well as it's basically the same thing as Ejecta (faults included). After testing WebGL does free memory from layout to layout and to be honest iOS wouldn't even mind 100mb of memory. The problem is that during the loading phase there is a huge spike in memory usage, that is because ejecta loads the texture as soon as the src property is set (thanks for the explanation, that was the missing piece of the puzzle) and so the memory gets filled for the whole size of the uncompressed textures (that on a retina display can become quite big).

I'm working on an exporter for Ejecta, I already fixed some issues with the audio object and other little stuff, I would like to try to set a "fake" src property during the loading phase, then set the src the time the object is created, do you think this is possible to achieve? Can you point me in the right direction?

Thanks

I can report that WebGL still loads everything at startup, why Ashley?

EDIT: I tested and they do get unloaded, but everything still loads up at startup, all these memory issues would be very easily fixed with an option to avoid any kind of preloading, small images in a local environment would not produce much of a delay, it would be sort of a global LoadImageFromUrl.

Ashley I don't think is so simple because the reply from Ejecta would be to blame construct 2 as loading 100mb of pixels into memory is not a very smart idea.

I think that there is wrong on both sides for sure, but that being said I'll try with WebGL and see if that works, otherwise I'll try Darklinki solution, even if I think the issue here is not loading them, but the lack of release..

I remember some versions ago there was a talk about dynamic loading of sprite on a layout basis, does this still holds true?

I'm getting an out of memory error in Ejecta on an iPad 3 because everything gets loaded at runtime and with the huge pixel density it just runs out of memory, I'm not using WebGL.

What are my options here?

It's a note to myself to check why that would happen. Could I have a look at the .capx that prints this?

I can't now as it's a full game that I'm about to release, as soon as I'm done I'll try to pinpoint why and where happens, it doesn't affect anything to be honest, nothing actually happens all works as expected, it gets printed inside a complex function full of local variables.

What it means this error I found in Chrome log?

Check: local var stack not big enough

Thanks

— I tried WebGL on my game, it works, but there are some issues. First of all it seems slower on my iPhone4, I see that you have an iPhone5 who have an incredible processor, I wait for other people input, from my perspective WebGL is slower than 2d canvas.

I tried some effects and most of them doesn't work.

It would be useful to make a list of supported effects.

Added a ghetto style exporter in the first post. It's a batch file that finds and replaces the correct lines using FNR.

It's really handy for me, so I shared.

If you are unsure about running batch files from random guys on the intertubes open the .bat file and check what it does.

Ejecta exporter.

Literally 5 minutes to do it. Everything already works under HTML5 exporter.

Three changes required:

this.isDomFree = true;

this.isiOS = true;

this.ctx = global_ctx;

Label it advanced/experimental to avoid complaints. Voil� another exporter to showcase, many people happy to not having to manually edit the code every-single-time they have to test something.

Any game can be accepted by steam, there have been several Flash games with no SDK hooks whatsoever sold on steam way before Greenlight was ever introduced.

The tools you use doesn't matter, it's the quality that counts. One of the most successful indie game of this season (Hotline Miami) has been made with Game Maker.

If you want to use the Steam SDK you have to write your extension for Node Webkit, never done it personally but I think it's more than doable.

Space Blaster has already been ported to Ejecta: youtube.com/watch (http://www.scirra.com/forum/experiment-construct2-with-ejecta-and-gamecenter_topic64187.html).

Game Closure seems far too complicated, Ejecta is working right now, with Game Center, iAP and WebGL. It works like Phone Gap and it's very very easy to extend with native code.

I firmly believe that as today the ONLY option to export professional games on iOS (with C2 of course) is Ejecta. Even if CocoonJS supported Game Center Leaderboards and Achievement (and it still doesn't), even if iAP purchases worked (which apparently they do not) there is still the issue of the forced CocoonJS logo before your game.

Anyway let's try to keep this thread on topic, posting example of games, issues and so on.

jayderyu yes it is but I'm not the original author, I'm expanding it with iAP purchases and whatever might come down to road to make it a complete Ejecta Plugin. I'll publish on GitHub so anybody can contribute.

Joannesalfa yes, all true! This is epic.

I'm sorry but Cocoon (at least on iOS) is years behind Ejecta, we already have working game center, working iAP and new features are rolled in every day. Plus is open source meaning no royalties, no issues that takes months to fix and if you really need something you can code it yourself (the extension system of Ejecta is really simple to understand).