Cocoonjs 1.4 issues with rendering

    • with extremely wide repeating tiled backgrounds, the edges become more fringed the wider they get. In webgl mode I get fringes, in canvas2d mode at some point retro-like huge pixelated edges start to appear. They actually GROW.
    • nine-patches work in canvas2d mode, but in webgl mode seams appear all over the place, rendering them unusable.
    • in canvas2d mode flickering lines appear at random here and there along sprite borders. I did add a 1px wide margin for all my sprites. It worked properly in 1.3

    Any solutions? It's very frustrating: both canvas2d and webgl in Cocoonjs cause graphical defects, and I tried running the game in Ejecta, which will not work either.

    In short, I cannot publish the game. And the client is waiting.

  • Question to Ashley: I checked the c2runtime.js to see if I can change some values for the nine-patch so that it removes the seams when run in webgl Cocoonjs. Which variables should I adjust?

  • I have the same problems, and the game is almost ready for publishing. I was just waiting for the WebGL integration by CocoonJS

    I feel a bit frustrated by this and I will probably start working on a new game until Ludei fixes this with a patch or something. I really hope 2 months of work doesn't go down the drain.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I also have disappearing objects when I return to a certain area. It might be slow refresh object load rate and I'm going to try to optimize assets.

  • Is this happening on iOS? (You mentioned ejecta, so I suppose it's an iOS problem)

    After the upgrade to Cjs 1.4 I renounced to test my game on iOS to avoid a nervous crisis and concentrated to android.

    I don't know if this may help you but when cjs 1.4 has been released I experimented also on android a lot of gfx glitches (wrong opacity settings, white objects, flickering) that disappeared after a complete uninstall and reinstall.

  • For now I am going to work around the main two issues in webgl mode. I will replace the nine-patch objects with my own constructed panels, and I should be able to remove the fringes by creating two or three repeating cloud objects.

    I did a couple of other optimizations, and got the game running at a healthy 50+ fps now in webgl mode (it's a shoot'm up of the different kind).

    Needs to go up this weekend, so these workarounds should fix the last couple of issues.

  • You should report these issues to Ludei, since we don't make CocoonJS and can't fix any problems with it.

    9-patch has a property in the C2 editor to turn seamless mode on/off - that might help.

    Android might be better since I think the Android CJS launcher is one version ahead (on 1.4.1 right now, whereas iOS is still on 1.4 since the approval process is longer).

  • You should report these issues to Ludei, since we don't make CocoonJS and can't fix any problems with it.

    9-patch has a property in the C2 editor to turn seamless mode on/off - that might help.

    Android might be better since I think the Android CJS launcher is one version ahead (on 1.4.1 right now, whereas iOS is still on 1.4 since the approval process is longer).

    Hi Ashley,

    Thanks for responding! Seamless mode on/off does not solve the display issues with the 9-patch object. Since I only have two panels in the entire game making use of this object, I removed those, and replaced them with my own version (corner graphic sprites, and rim repeating backgrounds.

    I believe these issues have been reported to Ludei a while ago already.

    I just don't like the idea of being dependent on a third party solution that is beyond the control of you and Scirra to provide solutions for.

    In my next project I may have to reconsider my options, and perhaps use a different tool, or start with early Ejecta testing, and go from there with Construct.

    Perhaps you could reconsider to offer out-of-the-box support for both iOs and Android. Ludei has proved to be quite troublesome for me so far, and for a while there jeopardized our project.

  • I just don't like the idea of being dependent on a third party solution.

    Construct 2 itself is a third-party solution to programming games.

    If you want to avoid those, you should code it yourself in native language.

    Perhaps you could reconsider to offer out-of-the-box support for both iOs and Android. Ludei has proved to be quite troublesome for me so far, and for a while there jeopardized our project.

    It will probably be years before out-of-the-box support for anything is added. Like I mentioned, making the game yourself in native language will provide all the solutions you're looking for.

  • Construct 2 itself is a third-party solution to programming games.

    If you want to avoid those, you should code it yourself in native language.

    You are misreading what I meant: I really like Construct 2, and come from a developer's background myself. The thing that causes alarm bells to start ringing in my head is Ashley's response that it's up to Ludei to fix things. Who's to say Ludei will not respond in like manner, and tell us that Scirra should adjust their code?

    Ludei's Cocoonjs is closed source as well, and we have to trust them not to change the license the day after tomorrow. Updates have been quite slow as well compared to other mobile game ecosystems.

    For me personally at least, it creates a somewhat fragile environment to rely on for my development. That is why I have been investigating Ejecta as an alternative, and I got simpler projects running quite nicely through xcode. It also frees me from being dependent on Ludei, and I have far more control over the output. That, and the benefit of working with an open source, means I can fix things myself if required.

    With Ludei I cannot fix anything myself, nor can anyone from the community. I do not have the time to debug to get our game working in Ejecta, so for this project this late in the dev process I just have to workaround known issues. Which I did today. It works quite well in Cocoonjs now.

    For the next project I will absolutely NOT rely on Cocoonjs - that is what this first dev experience with Cocoonjs has taught me. Most probably Ejecta. If that proves to be unsatisfactory - well, lots of other options out there, including mobile game frameworks and libraries.

    It will probably be years before out-of-the-box support for anything is added. Like I mentioned, making the game yourself in native language will provide all the solutions you're looking for.

    Any ecosystem has its issues and bugs. I am very pragmatic about it: if one tool or ecosystem/framework has too many caveats, I will switch immediately. There's only one way to really find out whether it is robust enough or is lacking, and that's what I did: I relied for this project on Cocoonjs. Next time I will not! That simple. :-)

    Cocoonjs tries to provide a non-technical way to publish to iOs, and I applaud that. It may work for others, but for me: I will avoid it next time.

  • >

    > I just don't like the idea of being dependent on a third party solution.

    Construct 2 itself is a third-party solution to programming games.

    If you want to avoid those, you should code it yourself in native language.

    >

    > Perhaps you could reconsider to offer out-of-the-box support for both iOs and Android. Ludei has proved to be quite troublesome for me so far, and for a while there jeopardized our project.

    It will probably be years before out-of-the-box support for anything is added. Like I mentioned, making the game yourself in native language will provide all the solutions you're looking for.

    i cant agree with you, there are at least two C2 competitors i know that is 3rd party solution(drag n drop game maker) and provide their own solution for android/ios export.

    its probably others have more staff and resource than C2, i know C2 is a small team, i bet Ashely would want a full solution rather than rely on 3rd party mobile exporter(that doesn't really work).

    i'd suggest Ashely to make the ios/android export feature available on free trail edition, so they know what to expect when they try to export mobile, i choose C2 because i like how easy it is to work with C2, and the intuitive UI when i test out the free version, but i didn't know mobile export would be a nightmare! now i paid full, 50% into my ios project, still worrying that this project can not deliver by C2 <img src="smileys/smiley5.gif" border="0" align="middle" />

    @ashely i love creating on C2, and you guys are genius! but please look at the problem with C2 mobile export!

  • I'm using iOS btw. IF that was still relevant. And I'm really hoping that Ludei fixes things with the new update. I could release my game in a few days turbo mode :)

    I don't want to complain about you guys since you've really made 90% of my dreams come true. I used to struggle so much with Flash, and Construct 2 is truly a godsend in every respect. It's made with us as users in mind, and that is still a bit rare.

    But if iOS exports were more reliable, It would really affect how much I invest, effort and time and money, into further projects in Construct 2, and also how much I recommend it.

    I really hope Apple gets their sh*t together and enables webGL on iOS 7... but judging from latest builds, it's probably not happening.

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