Ashley's Forum Posts

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You do not have permission to view this post

  • We have worked really hard to optimise our engine, to the extent I'm convinced there aren't any easy optimisations left to make. Render cells was getting to the point of very complicated implementation with benefits only in specific circumstances. I think most complaints are just to do with Chromium's frame scheduling/v-sync, which is actively a work-in-progress as the Chromium GPU team are upgrading a bunch of stuff. But as ever if you find anything particularly slow, send me a .capx and I'll profile it. I really rarely get sent .capx examples of slow things, and last time I got sent one I managed to profile it and make improvements to the engine, but people mostly talk about it which isn't helpful, I need to be sent real-world examples! Also as ever if an update breaks anything or you have any other bug reports please file them following all the guidelines, otherwise there's not much we can do.

  • Thanks, should be fixed in the next build.

  • Sorry, I think this is either a bug in Chrome (neither Firefox nor IE appear affected here - even though you mark them as affected in your report, I can only reproduce on Chrome), or a problem in C2's preview server (which is a component of Windows and not something we can control or fix), since it works after exporting. So I don't think there's anything we can do to fix this. However at least it does not appear to affect the exported app.

  • As far as I can see NW.js 0.12.0 preview mode in C2 looks identical to the C2 editor. Can you provide screenshots on Dropbox or somewhere else to compare? (The forum attachment system has been playing up lately so I don't know if you already attached pictures)

  • Can you provide a .capx that demonstrates this issue? So far nobody else is reporting it.

  • Hmm... you're right, but fixing this kind of issue can come with a big compatibility cost: there may be lots of existing projects using the form -x^y and expecting a negative result (and only working correctly in that case), and then if we fix this those projects break. It's hard to correct this in a way which only applies to future/new projects and not existing ones. I think this may have to simply remain a known issue - at least it's easy to work around.

  • The important thing is just to use asm.js physics.