Memory Management with CocoonJS

  • Thanks for the info

  • Thanks ludei !

    This is great news all-round, that C2 can now use a compatible approach with CJS so we get proper memory management for larger games.

  • Copying what a mobile browsers does was not our goal because they were not initially designed for gaming.

    It sounds like you are confirming your goal is to diverge from what real browsers do. This then confirms our decision to drop support for Canvas+. We are not prepared to support something which pretends to be a browser, but in reality is incompatible with what browsers do. Your proposed improvements are simply very difficult compatibility problems for us.

    While mobile browsers perhaps used to be terrible for gaming, modern mobile browsers are very good and in my opinion very well designed for gaming. The philosophy that "mobile browsers are not suitable for gaming" is in my opinion now out of date and no longer relevant on today's web, and should not be used as a reason to implement things differently. I could go further in to the details of browser caching and memory eviction heuristics, but I don't see much point - so long as your goals are to deliberately go in a different direction, then I neither want the support burden of having to deal with those differences, nor to become embroiled in technical debates about which is the "right" way. We're going to keep going the way we are which is to design an engine based on a single codebase that runs well in all real browsers.

  • It sounds like you are confirming your goal is to diverge from what real browsers do. This then confirms our decision to drop support for Canvas+. We are not prepared to support something which pretends to be a browser, but in reality is incompatible with what browsers do. Your proposed improvements are simply very difficult compatibility problems for us.

    The proposed improvements (apart from the dispose method) are not Canvas+ specific and wouldn’t entail compatibility problems or a new code base. Dropping object references, texture-packing or WebGL texture compression will benefit any browser, whether it’s real or not.

    Divergence from real browsers is not the goal behind Canvas+ design. Performance and portability (ex. wearables) are our goal. We created a specialized gaming environment compatible with standard Canvas2D/WebGL APIs. It’s true that some engines required compatibility changes to work with Canvas+, but as explained in the first post creating a browser from scratch is complex and required changes are fewer each version. Default C2 HTML5 exporter works in Canvas+ indeed.

    We want Canvas+ to work with any Canvas2D/WebGL engine, ideally with 0 changes. We also offer some non standard features. However don’t think of them as diverging from what browsers do but as optional performance/memory extensions. Features like screencanvas are optional to use extensions. It’s analogous to what happens with WebGL extensions. If a GPU offers a unique extension, you shouldn’t think that it’s diverging from what a real GPUs does and that you’ll never implement that extension in your engine.

    While mobile browsers perhaps used to be terrible for gaming, modern mobile browsers are very good and in my opinion very well designed for gaming. The philosophy that "mobile browsers are not suitable for gaming" is in my opinion now out of date and no longer relevant on today's web, and should not be used as a reason to implement things differently. I could go further in to the details of browser caching and memory eviction heuristics, but I don't see much point - so long as your goals are to deliberately go in a different direction, then I neither want the support burden of having to deal with those differences, nor to become embroiled in technical debates about which is the "right" way.

    We agree that modern mobile browsers are more suitable for gaming now. In the last post we explicitly said that Android 4.4 and iOS 7.0+ webviews are capable of getting native-feel like games. We also support webviews in the CocoonJS Launcher and any user can compile games using a webview instead of Canvas+ in our cloud compiler. We are not webview haters. We let the users choose the environment that works better for them.

    We're going to keep going the way we are which is to design an engine based on a single codebase that runs well in all real browsers.

    That's ok. We don't want to change your design decisions. We just wanted to publicly clarify the memory management misunderstandings because we think that our team didn't deserve some of the comments found in the forum. And also, please, recall that we never intended that Construct2 had two different export branches, it was an internal decision and we have been trying to reorient it so the final result (ZIP file) could also be compatible/executable inside a desktop browser.

    A lot of users are still using C2 engine with Canvas+. We want the best C2-Canvas+ integration for them. We have released a new plugin for them with upgraded social, box2d and multiplayer services.

    The current lazy loading implementation is working (we have even added the idtkLoadDisposed property for backward compatibility purposes), but some users prefer the old way to avoid pauses between layouts without a loading screen. We’ll add a lazyLoading check into the C2 plugin. We’d really like to solve the lazyLoading progress bar issue but it seems to be in C2 side. If we can do anything in our side to fix it, we’ll do it.

  • My god this is getting ridiculous.

    I already feel like a second-grade customer because I make games for iOS.

    Now things seem more complicated than ever. Sigh.

  • Here is my 2p. I agree in the long term phonegap/cordova will be great export paths, but at present the supported iOS export options are poor for older versions of iOS7 and below. I know a supporting factor for C2 to choose phonegap as its primary method to export to iOS was based on the quick speed of users upgrading to iOS7. However, iOS8 isn't being upgraded as quickly as iOS7 -> http://www.engadget.com/2014/10/07/ios- ... are-stats/ which concerns me as a developer for my short term* iOS releases.

    *short term - I am hoping at longest we will have to wait until the next round of phone releases/iOS9 update. Which is probably another year away. Which is LONG time to wait.

    What should developers do in the short term?

    As I see it CocoonJS works now (or it did for me) so that should be supported as much as it can without changing the core philosophy of Ludei or Scirra's development paths. This means Ludei should provide detailed setup instructions and tutorials that is supported by both Scirra and C2. For instance at present there is no way to to showing loading screens between layouts, which is a big no no in game development (Check the major console developers TRC/TCR/Lotcheck documentation). So by default it should be turned off until C2 is willing to make changes to support it, which in turn depends on if it is a change they are willing to make. In other words whatever is exported from C2 just needs to work to whichever method is supported.

    Scirra also need to remember that they state on their frontpage that they support publishing to iOS. Which attracts many developers to C2, me included. If they only want to support iOS8 then this should be stated on the front page. Otherwise I believe CocoonJS should be reinstated to provide full coverage. Yes, I know you have only depreciated the export option, but it leaves the question of if left unsupported how long will it continue to work?

  • Well since Scirra supports Ejecta, the under iOS 8 is actually supported for now (if it does not work, report bugs correctly to see if they will fix it), even without ejecta, C2 games still work on iOS (through the safari webbrowser, you may think it is kind of a cheap justification, but actually the direct html5 export is the only one that produce a single result that runs everywhere without needed this stupid "build for each platform individually"), so their statement on the front page is true and accurate, as for cocoonJS, they should not take them back, ludei has to talk to scirra so they can offer good support, but we should remember that scirra has no means to guarantee that canvas+ will not break once again (as this is not their job to program canvas+, remember the people that complained to scirra directly rather than to ludei for some cocoonJS bugs? No wonder they did not get fixed, even ludei could not keep track of them).

    PS: the html5 exports is known to be one of the thing ludei wants to support (it currently works?), so in the mid term the cocoonJS exporter itself should not even be nessecery, and the plugin is maintained by the community, as long as there is communication, it is good.

    To be fair, the phonegap, ejecta, node webkit, etc... support should not really be a part of the built-in C2, and the same goes for cocoonJS, it is just convinient to have them, but none should be contractually quoted as exporters, dropping cocoonJS is just a part of what should have been done IMO.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Aphrodite To be honest I have never tried Ejecta and that's because I have only heard bad things about it. So can't really comment as I have no idea if it supports ads, iap, etc. I will have to give it ago for myself. If it is a worthy candidate then great.

    I also believe that Scirra should not be responsible for bugs related to third party plugins. If bugs come up then the user should submit the bug with the third party. It's what I have done many times with CocoonjS and to date they have answered and fixed many of my issues.

    However, I completely disagree about exporting apps. It is what sold C2 to me and will be why many others bought a license. Without it I would probably be using GameSalad or GameMaker.

  • Here is my 2p. I agree in the long term phonegap/cordova will be great export paths, but at present the supported iOS export options are poor for older versions of iOS7 and below. I know a supporting factor for C2 to choose phonegap as its primary method to export to iOS was based on the quick speed of users upgrading to iOS7. However, iOS8 isn't being upgraded as quickly as iOS7 -> http://www.engadget.com/2014/10/07/ios- ... are-stats/ which concerns me as a developer for my short term* iOS releases.

    *short term - I am hoping at longest we will have to wait until the next round of phone releases/iOS9 update. Which is probably another year away. Which is LONG time to wait.

    What should developers do in the short term?

    As I see it CocoonJS works now (or it did for me) so that should be supported as much as it can without changing the core philosophy of Ludei or Scirra's development paths. This means Ludei should provide detailed setup instructions and tutorials that is supported by both Scirra and C2. For instance at present there is no way to to showing loading screens between layouts, which is a big no no in game development (Check the major console developers TRC/TCR/Lotcheck documentation). So by default it should be turned off until C2 is willing to make changes to support it, which in turn depends on if it is a change they are willing to make. In other words whatever is exported from C2 just needs to work to whichever method is supported.

    Scirra also need to remember that they state on their frontpage that they support publishing to iOS. Which attracts many developers to C2, me included. If they only want to support iOS8 then this should be stated on the front page. Otherwise I believe CocoonJS should be reinstated to provide full coverage. Yes, I know you have only depreciated the export option, but it leaves the question of if left unsupported how long will it continue to work?

    completly agree with this ... and that why i don't care about ios8 and phoneagb good performance on it ... because people don't update to ios8 as quick as ios7

  • ludei ArcadEd

    With the new update (r186), it is now possible add the missing features to the plugin? What will be the difference now?

  • Hello,

    We are currently working on adapting the C2 plugin to the 3.0.4 version of our JS plugins, but it is not ready yet. After adapting the plugin, we will see which features we can add.

    Regards.

  • I am currently testing our new game Wheel & Deal with the latest CJS-plugin and and r185. Solid 50-60 fps on all our target devices. Now, if Game Center works as it should we are set. Nice.

  • You made some change in your game, or even made changes to files exported by the construct? Or simply, generated apk with the new exporter plugin and the new compiler?

  • You made some change in your game, or even made changes to files exported by the construct? Or simply, generated apk with the new exporter plugin and the new compiler?

    Check your PM! This is not the best example as I said there, but if you have any specific questions I'd be glad to help.

  • Game Center and Google Play Services both work fine in the latest CJS. My game, Hungry Hal, was compiled using CJS 2.1. Leader Boards and Achievements working in iOS using Game Center and Android using Play Services. The game is running great on even iPhone 4s and Samsung S3 phones. CJS works, and it works fast.

    Would I like to have layout to layout loading to save on some memory, sure. But part of game design, imo, is working around problem areas. Especially in mobile.

    Keep watching. Ludei seems to be working fast (much faster than they used to ) and I think some awesome things are coming.

    ludei, wanna pay me to make some video tutorials for all that is CJS+C2? Or teach a live class via stream? .

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)