Ashley's Recent Forum Activity

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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

  • The spritesheeting strategy is described in some detail in this blog post, although it's a little out of date now (e.g. the maximum spritesheet size is now 2048x2048 instead of 512x512).

    The spritesheets have to be square power-of-two to avoid wasting memory on some devices (even if others can do non-power-of-two). Also note that bumping up a 1024x1024 texture to 2048x2048 uses four times as much memory, not twice, so it can be very wasteful to use spritesheets which are unnecessarily large. These days memory use is the main concern, since users tend to develop intensely memory-heavy games and sometimes find it crashes the device if it runs out of memory. So one of the strategies used by the spritesheet builder is if something fits on say 1024x1024, it will also try a 512x512 tile, or two 512x512 tiles, or three, as a way to save wasting memory with empty space on a larger sheet.

    More technical concerns are: most third-party plugins aren't written for spritesheeting, and it's tricky to tile images unless they go in their own texture, so tiled background images don't get spritesheeted. Also perhaps surprisingly putting everything on to one giant spritesheet can actually significantly increase the download size of the game. Often individual objects can losslessly compress down to PNG-8 - sometimes around half the file size - because they use less than 256 different unique colors. However if you bundle everything on to one giant sheet, it becomes much more likely that there are more than 256 colors on the sheet and it gets bumped up to PNG-32, which produces larger files.

    I don't think the performance is really an issue. In extreme cases with thousands of objects the draw calls can add up, but there are ways of dealing with that. In most real-world games I don't think switching texture poses a significant performance burden.

    When I first wrote it I thought it was simple enough, just a matter of dumping lots of images on to one sheet. It turns out there are technical factors and difficult tradeoffs like download size vs. memory use. I don't believe there is one strategy which is universally better.

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 27 Oct, 2026

Twitter
Ashley has 1,833,973 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
  • x6
    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
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs