Ashley's Recent Forum Activity

  • 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.

  • That sounds more like a bug than a missing error message. I think I saw a report on the issue tracker for that already.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Could you file an issue with full reproduction steps? I'm afraid we often can't fix issues with that brief a description, even with the crash report.

    • Post link icon

    If you really cared, you would change it.

    I think you are just trying to force us to do it the way you want it.

    • Post link icon

    The bottom line is that they don't care about your opinion.

    I'm just baffled how you could come away with this view after both Tom and I have put so much time and energy in to explaining our position and our concerns with the proposed alternatives.

  • AFAIK C2 has a similar WebGL batching engine to Pixi. I think the main performance difference when you get in to the tens of thousands is just hand-written dedicated JavaScript vs. the event engine overhead. C2's engine also does a lot more work: for example it makes the assumption you will be using collisions so it shares the rendering vertex data with the collision engine so it doesn't have to be re-computed, but this adds a bit of extra overhead. So we could probably make some similar optimisations if we entirely removed the collision engine, but then it's not a very useful game engine any more!

    Benchmarks are only useful to a point - I mean if you can hit 5000 moving on-screen sprites at 60 FPS, how many games are going to need more than that? A good way to think about the overhead is the per-sprite time. 20000 sprites 60 FPS means it can render 1.2 million sprites per second, or about 833 nanoseconds per sprite. If that's improved to 30000 sprites 60 FPS, it means the overhead per sprite has reduced to 555 ns, saving about 278 ns per sprite. This is very much microbenchmarking, and improvements like this can take a long time, and yet bring no meaningful performance improvement to real-world games.

  • The browser won't overwrite your downloads. So it will always add a (1), (2) at the end if you keep using the same name.

    It sounds like you'd be better off using browser storage instead of repeatedly downloading copies.

  • There's no good reason for them to be different - they are based on the same browser engine. I'd suspect it's just a margin of error in the test, or a quirk of only measuring to 55 FPS where v-sync scheduling comes in to play.

  • Looks like Unity's rendering performance is only about 25% better than the HTML5 version, so not that big a difference when it comes to on-screen sprite throughput.

    If GDScript is python-like, then compiling it to C++ won't make it fast - it'd need a proper JIT to compile it well. JavaScript happens to have excellent JIT support, so that would explain why it's faster. So there seems to be a good argument here that JavaScript is faster than GDscript.

    There's a request to support 30 FPS rendering in Chrome here, star it to show your support: https://bugs.chromium.org/p/chromium/issues/detail?id=485600

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,775,610 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs