Ashley's Recent Forum Activity

  • I can't really comment without a .capx, because I can't see if the events are efficiently designed or not.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Publish via Crosswalk, or recommend users update their browser to Chrome for Android.

  • Families are not involved in the texture loading at all. Texture loading works by individual object types instead of entire families to avoid dragging in loads of textures that aren't necessary. So if you have one "Sprite3" instance in a layout which is a member of a family, only "Sprite3" has its textures loaded.

  • lennaert - must be an old quote - it's basically accurate except we've supported layout-by-layout texture loading for a long time now!

  • Exactly! I don't imagine many, if any, would support keeping this for backwards compatibility reasons.

    It's hard to anticipate the impact of this. If it broke say 10% of projects then a lot of people would probably get angry and wish we hadn't. Some people have projects with thousands of events and combing through them for expressions involving any power expressions that could possibly return the wrong result (often tricky when variables are used) may not be practical. Then those users don't have any good options other than to stay with older versions of C2 and miss out on all future updates. (Cue the "is this how you treat paying customers?!" posts.)

    Previously we try to keep breaking changes to easily fixable things (e.g. if it breaks, change a project property back and it should keep working), or automatically fixable things (it internally checks the version when loading and applies a fix). This is a more difficult case to do that with. Still we could experiment with making the change on a beta release, but not everyone uses them.

  • This is probably a bug with a third-party plugin. Check all your plugins are installed correctly and up-to-date. We can't investigate any further unless you provide a .capx that demonstrates this problem without requiring any third party plugins.

  • A few sums to demonstrate how to work out things like memory bandwidth:

    A 2048x2048 texture has 4,194,304 pixels, each taking 4 bytes (ARGB), using 16mb memory. To render that at 60 FPS, the GPU needs to shift 16mb x 60 per second = 960mb/sec bandwidth. So with a single object you've pushed the memory bandwidth to nearly one gigabyte per second, and that's not including anything else. Especially for old mobile devices, this could already be way over the hardware memory bandwidth capabilities of the device. Then people conclude we need to optimise our engine...

  • 4. Some behaviours are just slow.

    I will use this one as an example. I wanted a rotating background in my game. So I made a 2048 by 2048 image. The game currently ran at 60fps with the background not rotating. As soon as I added Rotate Behaviour the performance dropped to 8fps. whoaawhh

    I switched to rotation in the EventSheet and that jumped performance to 30fps.

    I then rotated in the EventSheet every other tick(ie updating the image rotation at 30fps) and the game ran at a buttery smooth 60fps. And there was no visual difference.

    Lesson. Don't use Rotate Behaviour. I don't know why. I looked at the code. Doesn't seem like anything would hit performance. But eh.

    Stories like this make no sense at all to me, because the Rotate behavior works pretty much identically to an event saying "every tick, rotate speed * dt degrees". I really cannot think of anything at all that could explain any big performance difference. I think it is likely in this case something else caused the performance difference, in particular you mention a 2048x2048 texture which will really push the memory bandwidth/fillrate of the device really hard, which is really not a good idea for mobile devices which tend to have constrained memory bandwidth and fillrate and probably is more likely the explanation for 8 FPS. (This applies exactly equally to native apps: it's a hardware limitation, and you'd get the same performance results doing the same thing in native.) Also note if nothing is changing in the game then C2 skips drawing the screen at all, which could explain 60 FPS when it's not rotating (because it's not actually drawing anything), and you incorrectly attributed the performance drop when rotating to the behavior, when in fact it's simply the rendering vs. not rendering performance difference. Yes, performance is a complicated subject

    This comes up a lot in general when people talk about C2's performance: either the cause of performance problems is mis-attributed, or you'd get exactly the same results in native tech because you're running in to hardware limits.

    Anyway if you ever get weird performance results like this, please post them to the bugs forum as performance bugs so I can investigate, but I am 95% sure it will work out as being something else, like bottlenecking the GPU memory bandwidth.

  • So the .capx you sent me used Box2dweb physics, so I switched it to asm.js which is usually a lot faster (and is the new default as of latest releases for that reason). Then I turned pixel rounding off because it doesn't appear to be necessary and can have a small performance impact (since it must round every co-ordinate used in a draw call if it's enabled). After that, on a Moto X, 1st gen Nexus 7, and Nexus 9, it runs 59-60 FPS in Chrome for Android using preview-over-wifi. So there does not appear to be any performance problem at all. Some old Android stock browsers are pretty slow and buggy, but it's the browser, not C2 - give Chrome for Android a go if you haven't tried it yet.

  • I can't see that any of your demos include any performance measurements at all, such as the FPS, so are you just guessing? It'd be more helpful to share your .capx anyway so any problems can be more closely investigated.

  • The ghost shooter multiplayer demo runs on a dedicated server. It's just permanently running a Chrome tab which is the host of the game. It runs just fine - no stability issues even after running for weeks.

  • damainman - bugs are an inevitable result of the imperfect nature of software development using any set of technologies. I want to help you, but if you complain about a bug but provide nothing for us to investigate, what do you reasonably expect us to do about it? I can imagine going to all the effort of making a big game, and not encountering your specific problem. In fact that happens regularly even with small bugs, because they depend on factors which the submitter didn't originally realise, like the presence of a separate feature or something about their environment. This is why our guidelines exist - to ensure we can actually help. Even submitting a sporadic issue with one of your smaller .capx's with hints on what to try would be something, but right now I think I've got nothing.

Ashley's avatar

Ashley

Online Now
Early Adopter

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

Twitter
Ashley has 1,834,309 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