Ashley's Forum Posts

  • Sorry, there's a small bug where the countdown accidentally counts down to the start of the last day, not the end. The gamejam will carry on through Sunday, and I'd imagine the countdown will say something wrong during Sunday

  • Because of what I explained in my earlier reply.

  • Right click the project item in the project bar and select tools -> view spritesheets.

    I am really against any micro-management features like tweaking how spritesheets work. It is time consuming when we have stacks of other far more interesting and useful things to be working on, creates difficult bugs which only happens with certain combinations of settings, is confusing to new users, and users who don't have an intimate understanding of the engine can easily actually make things worse for themselves by naively choosing the worst option. We already see this a lot with the "downscaling quality" option, where people choose "high" for no reason, which adds probably 50% to the memory usage of the game for no benefit. It's really hard to explain to people how to use these options correctly.

  • What about collision detection with various other elements which do move

    In this case the collision checks will be far more significant, making the performance overhead of the individual objects negligible.

    [quote:2srdfutv]If so, is it possible, when disabling collision detection, to actually have that bit skipped so it does not share the vertex info to reduce that bit of overhead?

    See my earlier reply.

    but then why does Construct particles use that method?

    Because particles are an obvious and easy isolated case in the engine where you might actually create several hundred of the same "sprite" (although the individual particles are not really sprites).

  • You could always do a manual cordova build with the exported files, rather than using our build service.

  • The option to disable collisions for sprites, does it remove the mentioned overhead of vertex info sharing ?

    No, but for real-world games this probably makes no meaningful difference. Also if a sprite is decorative and doesn't move, it never has the overhead of recalculating its collision box, which is much of what bunnymark is profiling.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Honestly, I don't think performance measurements at 50-55FPS are useful. You should run it all the way down to 30 FPS and measure there.

  • Sorry, they're not currently available. Besides, we really don't like people adjusting official addons.

  • Android 5.0+ already covers 70% of devices. This time last year it only covered 43% of devices. By this time next year, pre-Lollipop support will probably be more or less irrelevant.

    On top of that, Crosswalk is no longer actively developed, probably for the same reason, so there is little we can do if people run in to problems with it. Then there's a lot of people out there who go around the Internet saying "Construct 2 generates bloated APKs, it adds 20mb of overhead", which only happens if you select Android <5.0 support, and isn't true if you select Android 5.0+. It seemed to be a significant point to a number of users and impacted the reputation of C2's mobile export (unfairly IMO, since you could easily remove it). I'd rather make a fresh start with Construct 3 and never generate APKs with any overhead.

  • Maybe scirra should add such optimization tips to the manual.

    We've got that. It's been there for years. People still make the same mistakes, not everyone reads the manual.

    [quote:3a4n02ln]1.Construct is does not have any internal optimization regarding drawcalls.

    Completely, utterly wrong! We have very heavily optimised this part of the engine with a sophisticated batching engine based on years of engine development experience. C2's renderer is even better at batching than our old C++ DirectX 9 engine.

  • Please use the issue tracker for bug reports and follow all the guidelines to ensure we can help.

  • Adding a new object that uses the particle rendering method is a classic micro-optimisation. As I described before it makes a difference on the order of a few hundred nanoseconds per object. I honestly doubt many real-world games would be meaningfully faster with the particles rendering method. Meanwhile it complicates the engine, since you more or less end up with two kinds of sprites, which confuses beginners ("which should I use and why?"), and it means more time to develop and maintain, when we have far more compelling things to be working on. Wouldn't you prefer us to do advanced text features or a built-in canvas plugin or other more useful things like that? We're a small team and we can't do everything. These are the things that would fall by the wayside if we chased benchmark results.

    This is how benchmarks can actually have harmful consequences if you slavishly follow maximum performance at the expense of everything else.

  • It's fairer to test the c2bunnyparticles test against Pixi, because they both use the same rendering mechanism. The c2bunnymark test uses general purpose sprites with more capabilities like collisions, so I don't think it's really fair to compare that to a particle renderer.

    [quote:2ynzwm4t]Setting the render scale in runtime for lower/midrange phones would be nice

    You already can, using low quality fullscreen mode.

    [quote:2ynzwm4t]I hope you will get some time at a later point to investigate some further improvements to get a bit closer to the pixi score.

    I already did, they basically use particles.

  • If you test C2 please make sure you replace the "For each" condition with "Every tick", otherwise it's needlessly inefficient. The github hosting the examples still has the unnecessarily slow "for each" version.

    So I looked in to Pixi's code to see how they're rendering those bunnies, and it turns out they use a similar rendering technique to the particles object. So I made a similar test in C2 using the Particles object instead, and you can get similar performance gains.

    Testing on a HTC 10:

    Sprites: https://www.scirra.com/labs/c2bunnymark/ - ~5500 30 FPS

    Particles: https://www.scirra.com/labs/c2bunnyparticles/ ~31000 30 FPS

    Particles are super fast, over 5x faster at rendering! It's magic! Well, not really - particles are a really limited case so we made special optimisations to render them faster, much as Pixi's bunnymark does. They're too limited to work for general purpose sprites. Also like bunnymark, particles don't process collisions at all, so that overhead is removed. So this idea that we can magically make everything faster by rendering sprites like particles isn't really feasible.

  • It's meant to work over HTTP on localhost. I'm not sure why it's not working. I'm sure I tested this successfully before.