Ashley's Forum Posts

    • Post link icon

    In short, some devices like laptops have two GPUs, e.g. a fast but power-hungry gaming GPU and a slow but power-efficient integrated GPU. Which the system uses depends on things like whether it's running on battery and the user's settings. The GPU preference lets you request which GPU gets used - for games usually you want the high performance GPU. However often the system or user settings can override the choice, so it's little more than a hint.

    AFAIK most devices only have one GPU, in which case the setting doesn't matter, as there aren't multiple GPUs to choose between.

  • It's a difficult problem. You will need a backend service, an account system to provide logins, a reporting system that feeds in to that, a system to ban or otherwise moderate accounts that violate the moderation policy, and people to keep reviewing it regularly.

    By far the easiest solution is to not allow players to do anything that could violate a moderation policy. This is why many games auto-assign usernames and avatars, or only allow choosing between combinations of pre-set values, and only provide pre-set messages for player chat.

  • Did you change the anisotropic filtering setting? Usually if that's enabled it improves the image quality of angled surfaces like that, but if you turn it off it can look blurry.

  • If the element has CSS that allows vertical scrolling (e.g. overflow-y: auto;) then the browser should automatically allow scrolling the content with mouse and touch.

  • If you find additional information like settings that work around the problem, remember it would be useful to add those details to the Chrome bug report too.

  • Why does it matter? Surely actual players will run either the x86 or x64 builds only and not switch between them?

    If you trust the Steam Hardware Survey to be representative of your own audience, that is showing that virtually all Windows systems are 64-bit, so you probably won't miss much if you go x64 only.

  • My best advice is: make measurements and be scientific about it. I regularly see weird claims and things that sound technically impossible. People often do things like make multiple changes and then misattribute the thing that actually helped, or make mistakes and misattribute the thing that is making it worse. Software systems are complex, results are not always what you'd think, and even experienced software engineers lose track of the things they've changed along the way.

    If you think something is causing a performance problem, you should be able to measure it, make a single specific change, and then measure a significant improvement afterwards. If you're not doing that, it's not much better than rumour.

  • Unfortunately this problem is generally caused by broken graphics drivers and not Construct. Try installing any available system software updates or see if you can find an update for your graphics driver.

  • You do not have permission to view this post

  • It's not currently possible for web content to limit the FPS in a way that correctly handles both CPU and GPU overload. For example if you want to limit to 30 FPS, but the GPU is overloaded and running at 25 FPS, it's not possible to handle that properly in JavaScript code without it descending in to a janky mess. You can code something that tries to skip frames or some such, but it won't handle cases like that properly.

    Star this Chrome issue to show support for proper FPS limiting in browsers.

    However if your only goal is to save battery on high-framerate mobile devices, AFAIK these devices already drop the framerate in power saving mode. So if that's your only reason to limit the FPS then I'd argue it's not necessary as it's already handled by the system.

  • Here are a few points for consideration!

    • If you are using event sheets and don't want to program, then a tool like Construct makes it possible for you to make your game whereas otherwise it could have been impossible.
    • A vast range of high-level features speed up development time a great deal, such as built-in physics, pathfinding, line-of-sight, platform movement, etc.
    • Being web-based makes it uniquely good for integrating HTML and CSS for things like forms and data tables, which can be tricky in other tools.
    • There is genuinely an identical codebase for all platforms meaning cross-platform issues amongst the supported export options are rare.
    • Browser performance is outstanding these days - many people still assume it's slow but it is in fact so fast now it can far out-perform competing tools
    • Publishing to the web provides a way around paying 15-30% of your revenue to a platform owner
    • Web technology is the future! Construct started when everyone was still using Flash, and the editor itself is fully web-based, and I believe that's the direction everything is going in long-term.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I don't believe we have made any changes to Construct that would cause such a large increase in the build size - it would have been a major problem for a lot of people if we had done so. In fact we've introduced features like WebP image support that allow further reducing the exported size.

    Almost all the build size is likely taken up by your own project's content - perhaps you accidentally imported some resource or perhaps even a third-party addon that increased the size a great deal.

  • Thanks, I've starred the issue so I'll also be notified of updates in case I can provide any assistance.

    I'm not sure if anyone is able to narrow it down to a specific time, or even Chrome release, where this issue first started happening (if that's the case and it hasn't been there forever), but if you could that would potentially be a key detail to help the Chrome developers figure it out, in case they made some important change to something around that time.

  • The advice doesn't say "never update Construct". It means you should not try to use source control when everyone's on different versions. The solution is to make sure everyone on your team updates the version of Construct they are using at the same time, and then everything should work fine. Construct prompts you when a new version is available, so when you first see that, just remind everyone on the team to update as well.

  • Thank you, it now successfully passes our automated review process, and the updated translation will be available in the next beta release. It will remain under review for several weeks so please be patient, but we will issue rewards once review is completed.