...wanted to think about this one for a while.

Ashley - you made a good argument earlier, but I disagree about some of the reasons you posted.

Exact compatibility with a browser I don't think is all that important, as games don't need everything a browser can do. Again, we don't need an entire browser engine - we just need what games need. Hundreds of thousands of games have been made without needing an entire browser engine.

As for the issue about third party plugins - as much as I appreciate all the work put into them, even with C2 as it is now, the vast majority of games could be made without them. If C2 was feature complete, then even more so.

By hiring someone to work on native exporters concurrently, it would reduce the impact the extra work would have on C2 itself. Tomsstudio is showing that it's possible. I agree that the path you took up to this point was the right one, though. Trying to make native exporters while also making the editor and such from the start would have been too much to take on at once.

Yes, we'd have to create custom code for some platforms. But so does everyone else, to some extent. The HTML5 exporter would still be there for those who wanted to use it instead. It would give us a choice rather than having only one option.

The point of asking for native exporters wasn't just about solving performance problems, though that was a big part of it - it was also about other things like the issue of no memory management on iOS and about you being able to directly control the quality of C2's own exports.

More thoughts/feelings:

• feeling a bit discouraged after years with less improvement than expected
• disappointed code performance will always be behind the competition's, especially the platforms that really need it like mobile
• no manual memory management with JavaScript can cause stutters when garbage collection is running. We just have to hope gc collection improves to the point it doesn't cause stutters anymore on every platform, since so many use different code for gc.
• being rattled by chrome's recent xp/vista software rendering nonsense. We just have to hope the chrome team changes their mind.
• misses out on export to a lot of platforms (3ds, vita, ps3, ps4, Xbox 360, Xbox one)
• all we can do is hope that sony and microsoft enable support for html5 games on ps4/xb1, and that performance is acceptable - I tried a test on the ps4 browser and the performance was terrible.
• I'm feeling better about the android situation after discovering crosswalk is capable of running a game with a lot of assets, but I'm not confident about the situation on iOS. Apple has had the tech for jit just sitting around in the operating system for years and don't let anyone else use it, which makes no sense to me. If they don't want the web competing with the app store, then why do they allow jit on the web, but not in apps? It just makes it harder to make an app using web tech, which as an app, would be on their store. They also have shown no inclination to change their stance.

What it really boils down to is too much is based on hope. I'm just tired of relying on hope for the quality of exporters to improve, and worse, once we get them, having to hope that a quality exporter isn't later screwed up in some way. Because of the recent XP/vista chrome problem, I feel uncomfortable about the exporter situation rather than secure. Are they going to screw something else up? What am I supposed to do if they do if they do? I have no options, and neither do you, which hurts the quality of your product and your user's products. What's worse is that we don't just have to hope for one company to do things right and keep doing things right, we have to hope for a whole bunch of them to do so, and even if they all did everything perfect C2 would still lag behind in speed and miss out on several platforms it could otherwise export to.

I think these problems detract from the perception of C2 as a 'serious' tool that can be used for serious development. When choosing an engine for a serious project that might take years and many thousands of dollars, I'm concerned about how many developers are going to look at C2 and just see too many limitations, caveats, problems and potential problems compared to the competition and use something else. There's too much uncertainty. Many people who choose C2 and discover the various issues will eventually move to other engines because of it, as seen by several people who commented they have already done so in this thread.

I'm afraid I'm still in the native bandwagon. I see how you're playing the long term game and respect it, and I understand your point about trading one set of problems for another, but I think it is more important for your long term benefit to make native exporters, so that C2 doesn't end up as a 'getting started with game development' engine instead of being something worthy of sticking with or even switching to for more experienced developers.

There's the pairer object, you could use that which sort of works like a dynamic container (I haven't used it in long enough that I can't remember how well it would work for this purpose though), or you could store uids in instance variables as well as the offset distance and angle, then use a for each loop to place the objects each tick.

C'mon, patience. Tom's working on it.

This is an English speaking forum, please stick to English or provide a translation.

As far as I know, no.

The easiest way would be to place another object at its location then use the move at angle action, and have it move 10*NumberOfSeconds at 315 degrees. Keep in mind the location might not be exact depending on the fluctuations of dt if you're using it for physics.

Construct is almost exactly the same as MMF2 (now called Clickteam Fusion).

It's really not. C2 is light years ahead of MMF in pretty much every way aside from native exporters.

If you're on XP or vista it uses swiftshader which is software emulation for webgl, but it's not perfect, and sometimes the effects don't work correctly.

You put all of the assets into 1 layout and it ran at 750mb? Pretty impressive heh.

Sorry, no, should have been more clear, I added maybe 500 mb of images to the about 250 mb that was already there, and spread the new images across 3 layouts that never get visited.

If the VRAM usage of the construct classic version of loot pursuit is anything like the C2 version (C2 version should be less because I set it up better), total VRAM in use shouldn't be above about 100 mb at any point.

what kind of music problems are you referring to? start times? or something like syncing problems?

I was recalling someone else complaining about them - I admit I might be remembering incorrectly. I haven't gotten to the point Of adding music in my games yet.

— - I recently got access to an android phone and just gave crosswalk a try - I didn't realize it has memory management, so I tossed in the rough equivalent of all of loot pursuit's graphics into the capx which probably would total somewhere around 750mb at least (when uncompressed in ram), ran it, and it in fact did not crash though it did occasionally have random pauses up to over a second. So I'm not sure what it's doing, but thanks for mentioning that.

Also a good point about the shared memory - if layout by layout loading is only for VRAM, and on mobiles normal ram is also used as VRAM, I'm not sure if one of two things is happening - either its keeping all compressed assets in ram and decompressing them only when they're needed and dumping the previous layout's uncompressed assets, or two its keeping everything decompressed in ram and swapping stuff out as it loads from flash memory when needed. My guess is the former, as I would expect the latter to cause quite significant pauses, but I did get a few significant pauses here and there (though not at layout transitions) so I'm not sure (haven't checked the total ram usage yet).

All this talk about C2 not being able to make larger complex games on mobiles... not true.

I think you're misunderstanding what I meant when talking about a large game. Complex games with thousands of events are certainly possible on mobile as it is (music problems and such notwithstanding). Large games, and by that I mean games that take up a lot of memory, aren't, for the very reason you struggled with - C2 loading all images at once. 250 mb is not at all a small amount for a mobile game - as far as I know, iOS is already throwing memory warnings at that point. Optimizing, reducing color palette and resolution will only go so far.

Loot pursuit, my rpg, was also running smoothly with over 3,000 events, but as soon as I added too many images, it started crashing. I wasn't even halfway through the game at that point, maybe a third. No amount of optimization will make it run on iOS unless something is done about the images all being loaded at startup.

I feel kind of sorry for Ashley - unappreciated by some as a one man coding guru

Colludium - I certainly hope I didn't sound that way. I crazy appreciate all the hard work he puts into C2 - as I mentioned before, if it weren't for construct, I wouldn't be making games at all.

Though I can't speak for everyone, I think generally others feel similarly that they appreciate the effort put into C2, but just have some complaints about the present state of some things which are outside of Ashley's control due to the route he's chosen. I don't think expressing discontent with valid flaws automatically means people aren't appreciating the work put in.