Ashley's Recent Forum Activity

  • The Linux exporter will never say that it requires the Microsoft Edge WebView2 runtime. If you see that it means you tried to run a Windows WebView2 export on the Steam Deck.

  • See the note in the manual:

    The "is online" detection of the Browser plugin is more or less a guess. It is actually difficult to categorically determine if an Internet connection is available. For example the user may have intermittent signal, and online features sometimes work and sometimes fail unpredictably. In this case the "Is online" detection is probably wrong, as it can't actually tell whether a connection will work. Rather than using this condition to check if online features will work, usually it's better to just go ahead and use online features anyway as if the user is online, and handle any errors that occur as a result.

  • "This app requires the Microsoft Edge WebView2 runtime. It will be downloaded and installed for you now."

    Use the Linux exporter for the Steam Deck. Don't use the Windows WebView2 exporter - despite the Windows compatibility on Steam Deck, it's not good enough to run WebView2, but the Linux exporter runs natively. See Exporting to Linux and the Steam Deck.

  • In the NW.js object, there is a ReadFile expression (not an action) that synchronously reads the content of a file and returns the content as a string.

    However I would advise using the File System object with one of the newer export options. NW.js is deprecated so will be removed in future, and the File System object can read files asynchronously which is usually better for performance and avoiding jank.

  • It looks like GetAccessToken() wasn't available in SDK v2 due to an oversight - I've added an equivalent getAccessToken() method for the next beta (which would be called via runtime.objects.Facebook.getAccessToken().

    The existing IPlugin static method getByConstructor() and methods getSingleGlobalObjectType() and getSingleGlobalInstance() allow for retrieving an object type or instance for a given plugin constructor, but you won't need those for calling getAccessToken().

  • You do not have permission to view this post

  • You do not have permission to view this post

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

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,789,342 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x43
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs