Ashley's Forum Posts

    • Post link icon

    Please send us an email at supportbcj@construct.net and we'll try to get you sorted out ASAP. I'm afraid as payments involve sensitive personal information we cannot provide support for such issues on a public forum, so closing this thread.

  • It should already be possible. Set the drawing blend to 'Destination out' and any opaque drawing will erase.

  • If you're doing something like stepped collision checks, then you can just use any fixed time step. The only difference it makes is how many checks/collision accuracy. For example you could just use a fixed time step of (1/60) and it will have about the same accuracy as frames when running at 60 FPS but with no variation at all because you used a fixed step.

  • Don't use 'Execute Javascript', you can just insert a script action directly in the event sheet which is much easier to work with.

    You probably need to turn off 'Use worker' in project properties, as by default the runtime runs in a web worker without direct access to DOM properties like 'window' and 'document'. The manual guide on JavaScript in Construct explains that more. And if you use a script action in the event sheet, Construct defaults worker mode to off so all those APIs will just work like you expect.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yeah, if you are calculating something like where an object will end up after 1 second, you definitely should not be using delta-time. The only input to that calculation should be 1 second, because that's how far ahead you're calculating the movement. If that's the case the problem is not that there are small random variations in delta-time, it's that you're fundamentally doing the wrong calculation.

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