Ashley's Forum Posts

  • Delta time has small random variations because neither the refresh rate of your display nor the timer measuring the time between the display refreshes are perfectly accurate. However this should not normally matter.

    It's also actually correct that it varies, if your display refresh rate varies too. For example suppose a display had an irregular refresh rate: one frame was displayed for 50ms, then the next frame was displayed for 100ms. In this case the delta-time measurement should be 0.005 then 0.01, so that the motion of the game is lined up to the actual display refreshes. If you smooth delta-time or otherwise don't use the actual value, then it can actually add jank and inconsistency, as in this case the game might do something like advance motion by 75ms when the image is shown for either 50ms or 100ms, either undershooting or overshooting. Given the prevalence of variable refresh rate displays, this may be a more likely scenario than it seems.

    I think the problem in this thread may be that you've jumped to conclusions. The object you showed wobbling is not actually moving. So why is it using delta-time? This appears to be a logic problem with your events. I don't think you should be using delta-time at all there.

  • Messaging between frames on the same page can be done with the postMessage() JavaScript API. Some services also provide a JavaScript API you can use.

    If neither is applicable and you want to communicate with an entirely separate application which does not provide any JavaScript API, it is tricky. Your best options are probably a WebSocket or a browser extension - but you'll still need to know how the external application works and how to message it.

  • That sounds like a regular cross-domain request issue, and that's also covered in the manual.

  • The current plan is to include it in the next LTS release - due out in the middle of this year (June/July) - and remove it after that. Then you can keep using the LTS release with NW.js included for another 18 months beyond that.

  • You can use the Timeline Controller object's 'Set instance' action to set a different instance to play a timeline with. See the Timeline instances example. If you want to play for all instances, you could try something like 'For each Sprite - set instance Sprite, play timeline'.

  • If you only need it to work for your one browser, you can try going to chrome://flags and changing settings to allow it. It looks like you could add the specific server to "Insecure origins treated as secure" to minimise the security risk of allowing any insecure access.

  • Modern browsers block secure websites from sending requests to insecure websites. So it's browsers that are blocking this for all web content, it's not specific to Construct. Construct's preview is a secure website, and so you will hit this security restriction in preview mode.

    The one exception is you can make insecure requests to localhost - that is allowed as the system knows the request will not leave the same device.

    All modern web content should be secure and run on HTTPS. Nobody should be running an insecure web server for anything important these days.

  • The Function maps example shows how to use function maps to call a function by a string.

  • HTML content shouldn't affect the draw calls measurement, as draw calls are the time spent drawing things in to the canvas, and HTML content isn't drawn in to the canvas. So this doesn't make sense. It would be easier to help if you could make a minimal project demonstrating the issue.

  • I looked in to this and it does look like it stopped working. It turned out to be a bug in a new code minifier we're using. It should be fixed in the next beta.

    It is best to report problems directly to the issue tracker though - this is just serendipity and I may well miss problems only mentioned on the forum, or commonly they don't have enough information to investigate.

  • It should be supported then. It's hard to help further without knowing more about the problem - perhaps try clearing your browser cache and try again? Alternatively you could connect the device to a mac via cable and use Safari developer tools to check for any error messages in the console.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • What version of iOS is the device running? The minimum requirement is iOS 15.4.

    Tried both safari and Firefox apps.

    Unfortunately Firefox on iOS is just a wrapper around Safari, as Apple have banned other browser engines. So there won't be much different if you try a different browser on iOS.

  • It's probably possible with a wrapper extension. Construct's extension SDK can give a wrapper extension the HWND for the main window, and then you can make any Win32 API calls you like to alter it.

  • Construct should save data indefinitely. If it's being lost, it is your browser that is deleting it, not Construct. Check your security and privacy settings, and check if you have any privacy-focused browser extensions that might be interfering. For example if you have some thing that deletes all cookies once a day for privacy/security reasons, that will cause Construct to lose all its saved login/settings/etc information.

  • What I'm highlighting here is that I have noticed a tendency for Pixel art games made with Construct on Poki to load slower for players, to the point of significantly affecting the player bounce rates

    Do you have measurements you can share that prove this? I find this surprising - pixel art games should not have heavy art assets by any stretch, and a good CDN should not have a problem with something like 100 small files - with modern HTTP 2+ those all just go down the same connection efficiently without having lots of per-request overhead. For example the Construct editor is 1000+ separate requests to load the editor - mostly lots of small files - but it's served cached via CloudFlare CDN over HTTP/3. A cold load takes <1 second on my system (with a good connection, but still). So I have to ask, what measurements have to made and what has led to identifying spritesheeting specifically as the cause of it?

    Again, in the use case I am defending, memory usage is NOT the bottleneck.

    I know, but we have to make something that works for all sorts of kinds of projects, not just specific ones. If we add a setting, sometimes people change the setting, forget about it, find their project starts crashing, and then leave us poor reviews or end up contacting customer support. So we also try to avoid features that make it easy to shoot yourself in the foot like that.