Dalal's Forum Posts

  • There ARE some behaviors you can't add more more than once, but Sine isn't one of them : )

  • It depends on what you're trying to do. The most flexibile way I feel is to use a tiled background and use modulus to keep it wrapping. You still have to use 'Set Y', but I don't know if you can avoid that. Here's an example that wraps on all 4 sides with two events. You can replace the tiled background with any image of any size and it'll still work with the same events. Hope this helps.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Give it two Sine behaviors. Set one to horizontal, and the other to vertical. Tweak the settings until you get the diagonal movement you want.

  • This is absolutely beautiful work. Thanks for sharing!

  • MrMiller, What!? Seriously!? Where? Please link me.

  • twg, How many HTML-5 game engines have you tried that do this? Does the jerky movement stop after a minute, or does it continue throughout the game? How severe is the jerkiness? How accurate is this simulation in regards to what you're experiencing with movement?

    I want to figure out whether you are experiencing the exact same thing as me, and whether it's truly the JIT compilation that's doing this. If it's the JIT compilation, then I have hope that this will be fixed in the coming months.

  • Three questions:

    • Is there a reasonable way to "hack" a Construct 2 project so that I can use custom spritesheets?
    • @Ashley, would you ever consider giving us more options for the creation of sprite sheets within Construct 2?
    • Do you think sprite sheet optimization beyond what Construct 2 already does is worth it for mobile?

    So here's the deal: Construct 2 currently sacrifices some sprite sheet optimization in the interest of greater compatibility. For example, instead of creating larger more condensed sprite sheets, it creates one sprite sheet for each sprite. To my understanding, it does this primarily to support progress bar feedback. Since there is no way to tell how much of an individual image is downloaded, splitting sprite sheets up allows Construct 2 to count how many of them are loaded from the total, giving a more precise picture of the load progress.

    This decision makes sense when considering that Construct 2 was made for HTML-5 games, which are typically "downloaded" rather than "loaded from disk". However, I believe many people are using the engine now primarily for mobile game development (like me). This means the games will be running on less performant GPUs, but will load much faster since they don't have to be downloaded. These lower-end GPUs could benefit from not having to swap textures as often as they would with multiple spritesheets, and the "progress-bar feedback" reasoning here is not as compelling as it is for browser games.

    So for mobile-only developers, it would be nice to have the option to pack the sprite sheets manually, with the aid of tools like Texture Packer. Construct 2 games on mobile might consequently see lower memory usage, better GPU performance, and on the whole more native-like experiences.

    Now, I do remember reading that Ashley was unable to measure any performance difference between using one giant spritesheet and using multiple ones. However, I don't think the test he used is always an accurate profiler of GPU performance, because the test averages the framerate as reported by the CPU. In my mobile game, despite a reported framerate that's generally 60 or higher, there is persistent stuttering and frame dropping that makes the game look bad. I hope it's just JIT compilation that will be fixed soon, but I've learned to choose skepticism over hope. It seems like there could be something crazy going on with the GPU here that the CPU doesn't seem to capture. That's why I don't completely trust this idea that sprite sheets make no difference. If there is room for optimization that could theoretically help GPU performance, I'd like to experiment with it.

    What do you guys think?

  • I've looked in to this in the past and I think it's JIT compilation in the Javascript engine.

    Ashley, If JIT compilation is truly the issue, what sorts of Construct 2 events would you recommend we use in a "compiler" layout to force code to get pre-compiled? Should we call functions we use in the game, create and destroy objects, make Touch conditions etc.? Could this technique even work to reduce the problem?

  • Wow, this might explain the micro-pauses I'm getting with my game on CocoonJS! Perhaps there is hope after all, since Ashley's theory seems pretty spot on.

    If anyone is interested, I made a thread on Ludei's website, requesting them to also look into their compiler to see if they can fix the frame dropping. If you're also a "Cocooner" then please upvote the thread to show your interest in the issue.

    And also, I made a simulation of what my simple bouncing square application looks like on my phone through CocoonJS. I have always assumed the stutter was simply garbage collection, but now I'm thinking it's a combination of that and synchronous compilation. Whatever it is, I hope it can be fixed soon!

  • What is your solution to the 15MB app size limitation?

    I think it's 200mb with a premium account - plenty for a serious, medium-sized mobile game. And as far as I recall, when I wasn't a premium user it was 30mb, not 15mb.

  • I've been having some irritating frame stutter issues in my game using CocoonJS even though it shows me 58-60 FPS, which leads me to believe that garbage collection is the culprit, though I could be wrong. Regardless, my research led me to someone's open-source project called OwnGap, which though minimal, currently has touch input implemented. I have not yet tested this, but it seems like an impressive project that I figured was worthwhile mentioning to the Construct community, especially at this critical time when CocoonJS has been officially deprecated.

    And here's my unrealistic dream which I'll include here for fun: if this is actually a viable export option, perhaps Ashley could get in touch with this programmer from the heavens and give us that long-awaited alternative for Android export that doesn't suck. Yes, wishful thinking on my part, but hope is what keeps us going sometimes

  • Yeah it doesn't make a bit of difference for me looks like

    Thanks for the response.

  • Wow, I hate to be the guy that didn't read the post properly

    Thanks for correcting me.

  • Just FYI, I think this topic is covered here: https://www.scirra.com/tutorials/556/un ... o-families

  • In an article I was reading, it made the following statement which I'd like further clarification on.

    [quote:u727pkzp]

    10) Scroll to is faster than moving eveyting

    Rare situation but it happened to me. Don't move every object if you can scroll your view.

    My infinite "runner" game currently uses very specialized scrolling. I have a family of objects called "Scrollable" which move downwards as I "scroll" upwards. Should I re-do the scrolling so that it moves the view instead? How much of a performance boost might this give, and why? Is it worth it (I'm using CocoonJS to port it to mobile)?