Ashley's Forum Posts

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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

  • Is the Godot engine native? If so, nice evidence that HTML5 can reach native performance!

    BTW I generally use 30 FPS as the cutoff for performance tests - 55 is a bit close to the v-sync limit, where scheduling issues could come in to play.

    • Post link icon

    Also FWIW, that C2 bunnymark test is needlessly inefficient. Replacing the 'for each' condition with 'every tick' works identically and increases the score by about 300%. It looks like from other people's scores this will mean C2 beats the godot benchmark, but it's possible that one is needlessly inefficient too, I'm not familiar enough with godot to comment.

  • Hmm, the CSP also had to be updated on the server side so maybe there's a caching issue. Try clearing the browser cache.

    • Post link icon

    Closing as this thread is not useful or productive.

    Our bug report requirements make it clear what to do if you run in to any trouble, including what to do if your project includes copyrighted content. If you're not willing to co-operate then we're not going to try to help.

    I'd also add performance problems people blame on HTML5/browsers/C2 routinely turn out to be hardware limitations, and nothing to do with Javascript or the web platform.

    [quote:2vzpred5]Do I need to share my entire project? I have copyright concerns.

    No, we don't want your entire project. Sending us your entire project is usually not actually helpful. The guidelines require a minimal project with the fewest events and objects possible. Preferably you will be able to demonstrate the problem by creating a new empty project, and adding the minimal events and objects to show what is happening. This is the only practical way for the developers to diagnose the problem. Projects with hundreds or even thousands of events or objects are a nightmare to test because there is so much going on in the engine and it is almost impossible to isolate which part is potentially going wrong. Further, a very significant proportion of bug reports (around half!) are simply mistakes in events, and not actually bugs. Spending hours or even days debugging a huge project only to find it was a mistake in the events is simply too costly to our developer time, especially as we are a small team. Everyone wants the developers to get back to writing new and exciting features instead! Generally if you cannot reproduce the problem in a new empty project, that is a strong sign it is really just a mistake in your events, so this is a good way of filtering out mistakes from bug reports.

    In your minimal project you can also easily use placeholder graphics instead of your actual artwork. This also removes any concern about copyright or having to sign NDAs. So it's better for both you and the developers.

  • When importing C2 projects, C3 guesses the C3 ID by converting to lowercase and adding dashes, e.g. "My Property" -> "my-property". You used an underscore though ("my_property"), if you use a dash it should import correctly. If it doesn't automatically get the right name you can use the LoadC2Property method. But I just realised none of this is documented, so I should update the docs

    • Post link icon

    Can you provide any actual examples or performance data? The NW.js exports run great across all OSs last time I tested.

  • You can always force it enabled by going to chrome://flags and disabling software rendering.