Ashley's Forum Posts

  • Both links return 404 not found, so closing. Please post a new report with a working .capx link if you still want this investigated.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Note the XOR blend mode is not supported in WebGL mode - it will look the same as "normal" blend mode. Still, the rendering bug should be fixed in the next beta.

  • Closing, please see the bug report requirements, and also make sure you have the necessary drivers for the system to recognise your gamepad.

  • This should be fixed in the next beta.

  • Closing as no further reports since r206. Please post a new issue if you still have problems.

  • It's a bug in the "Use render cells" layer mode. You can work around it by turning that off, or it's fixed for the next beta. Nice catch.

  • Letterbox mode should scale everything correctly regardless of the DPI setting.

  • Can't reproduce, works fine in Firefox here. Check you're not using any privacy browser addons or private browsing modes, which may clear the storage. I'm not sure why you would use "check item exists" in an "on item set" trigger anyway - of course it exists if it's just been set!

  • Your numbers are very likely wrong. Chrome will happily use up 100% of the cpu if you give it that much work. However measuring CPU time is actually pretty complicated. C2's 'cpuutilisation' expression is really "time spent in main thread", literally based on timer measurements. There isn't a direct way to get CPU usage in Javascript, so this is used as an estimate, but it has some drawbacks:

    • time spent in the main thread is not necessarily the CPU usage, e.g. if the CPU suspends the thread and goes idle for a while, then resumes the thread, all that time will be included in cpuutilisation making it look like the CPU usage is higher than it really is
    • the timers only cover the main event loop, and some things like input triggers are not covered
    • the timers only cover the main thread - anything the browser dispatches to another thread is not covered. For example Chrome basically saves all draw calls then forwards them to another thread to run in parallel, whereas some other browsers run the draw calls on the main thread. This means cpuutilisation excludes the draw calls work in Chrome because they happen on a different thread, but includes the draw calls work in other browsers which do run on the main thread. In actual fact the CPU work done may be identical, but this causes different measurements. Similarly there are other features which may or may not be included in cpuutilisation depending on the threading model of the browser.

    Further, if you look at the per-process CPU usage in Task Manager, there are more gotchas:

    • Chrome is a multi-process browser, so you need to take in to account the sum of all CPU usage across all Chrome's processes
    • Windows tends to merge all cores in to one percentage reading, so e.g. 25% CPU usage on a four-core system may indicate one core at full usage, two cores at 50% usage, four cores at 25% usage, or something else. It can be hard to tell.
    • Since C2's cpuutilisation is only measuring one thread, it could read 100% when Task Manager indicates 25% (assuming a quad-core system again). Both are correct: the main thread is entirely busy, but only one core out of four is fully utilised.

    If you are not aware of these various complexities, you will simply confuse yourself by making misleading measurements. There are reasons that C2 could measure way higher than Task Manager, or way lower. Your impression that Chrome is not able to use the full system resources is almost certainly incorrect and probably just a result of these complications.

    My advice: just look at the measurements in C2's own profiler. That should give you a reasonable idea of which areas of your events are slow. And only treat the specific numbers as a ballpark, as if they can only read "low", "medium" or "high".

    If you're wondering why C2 doesn't "just" run everything over all cores, then see my blog post Why do events only run on one core?

  • Sebastian - no, browser crashes are certainly a problem in the browser. It is not normally possible for web content to crash the browser, no matter what the content does.

  • If the browser crashes, it's not a problem with C2. Either you used too much memory, or the bug is in the browser. See the bug report FAQ about reporting issues in browsers. Closing.

  • Answer your own performance questions with measurements

    Without making any measurements, I would guess it makes no difference either way, since the (tiny and irrelevant) amount of work checking the "trigger once" condition is probably about the same as the (tiny and irrelevant) amount of work in the "set animation speed" action. Of course if you make measurements you can prove this for yourself.

  • just be aware that the built-in multiplayer functionalities are designed around the host/peer architecture, not server/client. It may or may not be an issue depending on your concept

    "host" and "peer" are just different names for "server" and "client", it's the same architecture. The connections are what go peer-to-peer, but it's still an authoritative server model - the host acts as the server.

  • matrixreal - don't worry about this when designing your games. It all happens automatically and is taken care for you.

  • You do not have permission to view this post