Ashley's Forum Posts

  • Support for this was already added in r219.

  • From the Browser object manual entry:

    Downloading is a browser feature and depends on the browser UI. Note that mobile apps don't run in browsers (there is no address bar etc), so the download feature isn't available there. Consider using the Share plugin to share the file instead.

  • I can't offer any support for editing projects after export. You could give it a go, but I expect it will be too difficult to get working.

  • For the time being you can keep using the C2 runtime to support Internet Explorer. But the C2 runtime will itself be retired in July. IE is very old and was long ago replaced by Edge, and its usage share is still falling, so if it's not irrelevant already, it will be soon.

  • For the record, since the introduction of WebGL in 2011, Construct games have rendered almost identically to native games. WebGL is basically OpenGL exposed to the web. So it's basically using the same rendering API as any other native game using OpenGL. (With WebGPU, this analogy will continue, but being more or less equivalent to the next generation Vulkan/Metal/DX12 APIs.)

    The main difference introduced by browsers is the driver blacklist. There are many poor quality drivers out there. These can crash and glitch and ruin games. This is a serious problem faced by many native engines. There is little anyone can do about it. Sadly the state of graphics drivers continues to be poor. (Hopefully the next generation APIs help with this, since they allow the drivers to be much simpler.) Browsers blacklist known bad drivers so you get software rendering instead. This means the game runs correctly, but slowly.

    So barring some kind of obscure browser bug we don't know about yet, the only explanation seems to be the graphics drivers. These are still a problem no matter which technology you use. You may find that when using some other game engine, it seems to be faster, but then you later run in to the crashes and glitches that the browser makers were trying to avoid. This can cause even worse problems, such as the game crashing or just showing a black screen on various types of Android devices.

    So while you may claim that Android performance ****** I think really this is just driver blacklisting on a small number of devices for a good reason. It's a matter of picking your poison - do you want software rendering or the risk of crashes and glitches? I think the former is the right choice.

    Changing the framerate mode will only make this worse. It doesn't make anything faster, it only changes when frames are scheduled. Unlimited framerate mode will allow powerful devices to run up in to the hundreds, or even thousands, of frames per second, promptly drain the battery, and earn you poor reviews.

  • If those events are continually true, it will continually re-run them every tick, and keep queuing up more and more waits. You probably want to use a trigger, or the 'Trigger once' event, to make it happen once.

  • It's impossible to tell from just a post like this. A group with a single event with a single action could itself enable hundreds of other events that do loads of intensive work. So it looks like the group is causing a big performance impact, but that's actually misleading.

    Use the profilers provided by Construct. They give you actual measurements about the time spent in various parts of your events and the engine.

  • You said you're sending binary data, but the error says you sent text. You probably aren't actually sending binary data.

  • In general browsers don't provide hardware details for privacy reasons.

    Besides there are thousands of different hardware setups out there - you'd have to maintain an entire database of hardware and its capabilities, and continually update it over time. That's probably more work than making the actual game.

    I really think this is the wrong direction, I don't think anyone takes this approach because of all these problems.

  • Tweening should not have any significant performance impact. It's hard to say more without seeing a project that we can try ourselves.

    30 FPS is already a pretty low starting point, so my best guess is this is nothing to do with tweening - the most common cause of poor performance is a device with broken graphics drivers that has to revert to software rendering. (That's not Construct's fault either.)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It's much easier to help if you share your project. Otherwise we can only guess.

    It looks like you're incorrectly passing strings instead of numbers for the position in createInstance(), so I would guess that is the problem.

  • I still have absolutely no idea how this could happen (the code is a pretty simple show/hide pair, and every show is paired with a subsequent hide), but one thing to try could be to disable UI animations, just in case there's some kind of weird browser bug involving animating the fader in and out.

  • I would guess they run a whole suite of benchmarks under lab conditions. You can't easily do that in a game and the results may still not be appropriate or meaningful for the reasons I already mentioned.

    I think the only thing you can rely on is the FPS. That's the gold standard for how fast the game is actually running. You could have adaptive heuristics like if the FPS is under 50 for 5 seconds, lower the graphics quality a bit. That then adapts based on how fast the system really is running the game under current conditions, but involves a delay. You could also rely on the CPU/GPU utilization measures to determine how much headroom you have to increase the workload if things are running smoothly.

  • There's no good way to do this. You can try running a short benchmark, but that may be affected by any other activity on the system. (E.g. if another app in the background did some work, it could drag down the performance numbers lower than they'd really be.)

    Besides, there's tons of possible performance metrics. For example some systems may have high compute performance but low memory bandwidth, but others may have low compute performance but high memory bandwidth. If you run a performance test which is ultimately bottlenecked on memory bandwidth, but then your game actually does a lot of compute work, your performance benchmark result is not actually the right result. Software and hardware systems are incredibly complex with dozens of metrics and there's a huge array of configurations out there, so it's not really possible to come up with a single number.

  • You can't disable WebGL, because it's required in Construct 3.

    I think you just want to turn off the 'Preview effects' project property though.