Ashley's Forum Posts

  • Remember not to waste your memory

    I don't know why a boundary image would need to be so large - if you're drawing all four edges with a large area of transparency in the middle, that is very wasteful. Just make each edge a separate sprite and place them around the edges. That means you don't need any transparent central area at all, which saves loads of memory.

  • Closing as this is not really a vulnerability, it's no more a problem than the fact you can open Chrome dev tools on any page. It's there by design to help you diagnose any issues with your game, and includes the usual profiler, timeline etc. Even if you removed it, there are still easy ways to "hack" a game, it's not really relevant to that.

  • Okay, I guess we should fix this, but it's a breaking change and would throw loads of existing games ever-so-slightly off. So I think we need a project setting like "enable better acceleration precision", which defaults to on for new projects but off for old projects, or something like that.

  • so basically, my hard drive is half dead, and im still trying to get it in for repairs, but in the meanwhile I decide continue working on a game.

    This is where you went wrong

    C2 also has built-in backup features so you can do things like backup to a Dropbox folder which is pretty resilient - your whole PC could burn down to a crisp, and you can then still get your work off Dropbox.

  • calebbennetts - this is pretty confusing, but I don't think it's the case... it's not that C2 uses the wrong formula, it's that it treats acceleration differently to the kinematic equations.

    The kinematic equation (d = v * t + 1/2 * a * t^2) assumes the acceleration keeps increasing throughout the given time t. So for example if you have a car that starts at a given speed and keeps a steady acceleration, this will tell you how far it will travel in say 30 seconds.

    Construct 2 treats movement as a sequence of very small discrete steps that happen once per frame. Given a frame is typically just 16ms, I never thought to take in to account the effect of the continuing acceleration over that time. So C2 actually assumes the velocity is constant (not accelerating) for the duration of delta-time. However since it updates the velocity according to the acceleration after every step, you still get the effect of acceleration over time.

    Should Construct 2 take in to account the acceleration during delta-time? I guess that would be more correct. However there are two issues: we probably can't change this in the engine itself without breaking loads of existing games (which will all become slightly off), and the acceleration can actually change every tick as well, for example alternating between 1000p/s/s and 0p/s/s every tick. In that case which acceleration should be used for each step, given that there is a different start and finish acceleration and the engine doesn't necessarily know what the finish acceleration is? I think strictly speaking if I were starting from scratch I'd take in to account the starting acceleration over the whole step, but we can't change this now, and I think this is one of those things where as the time step tends to zero it becomes closer to correct, so this is another one of those "discrete steps don't work quite like the continuous real world" quirks.

    Anyway, this doesn't quite solve the stated problem: the jump height can vary depending on the framerate because the calculations take in to account delta-time, which is based off an imperfectly accurate timer in an imperfectly scheduled operating system, so it tends to have small random variations every step. Given the movement over time is a non-linear summation, the small random variations can accumulate and it can change by a couple of pixels by the crest of a jump. Your altered formula is still susceptible to the same problem, because it still uses a randomly-varying dt, although I can see it would reduce the accumulated error assuming a steady acceleration. My solution fixes the value of dt every step so there is no random variation and you are guaranteed identical results every time, which you would still need to do with your altered formula to guarantee identical results as well.

    Still, I'm wondering if a setting to use more accurate acceleration calculations would be worthwhile...

    tl;dr: the problem is a randomly-varying dt, but your formula only changes whether acceleration is taken in to account during the step or not.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • No, it's running in to a limit in the Windows OS. We never knew about the limit until it was too late. C3 is architected to avoid this problem.

  • Try changing the icon caching setting in Preferences.

  • Crosswalk is basically necessary for Android 4.x devices. On those the built-in webview is either horribly slow or missing loads of features. On Android 5.0+, the built-in webview is as good as Chrome so the games should run fine.

    Android 5.0+ is (at time of writing) just over half of all devices. Once it reaches some vast-majority amount (say 90%), it won't be necessary to use Crosswalk any more.

  • The built-in "Webcam" example shows how.

    • Post link icon

  • Closing, see the bug report requirements.

  • See remember not to waste your memory.

    400mb should be OK on modern iOS devices. C2 games should generally work fine on iOS, there are no major known incompatibilities. The most common mistake is forgetting to upload some of the files so it fails to load.

  • It looks like your solution is just to subtract off the delta-time calculation C2 does, effectively removing dt from the formula.

    There's a better way: just set a minimum framerate of 200. Then dt is always fixed so stepping will be deterministic. You'll have to adjust your speeds and accelerations though.

  • I'll reply here, better to post in the forum than privately by email.

    The signalling server is specifically designed to kick any clients that send too many messages, to prevent both intentional and unintentional DoS-type attacks, and prevent wasting server resources. For example a common mistake is to accidentally have some kind of message sent to the signalling server every tick. This wastes bandwidth and could impact the service of other users on the signalling server, so by kicking such users it forces them to correct the problem.

    Your example .capx still sends way, way too many messages to the signalling server. There is no way you need to update your game list every 500ms. The ping time could even be that high, meaning you're issuing a new request before you've even heard back from the previous one.

    You don't even need to update it every second, or 5 seconds. How about every 10 seconds?

    If this really is a problem for you and for some reason you want multiple updates per second of the game list, you can always purchase the signalling server from the store, reconfigure the flood limit, and hammer it as hard as you like. But you'll be paying all the bandwidth on that. You can't expect us to pay for servicing an unnecessarily huge number of requests.

  • I think if your project has the touch plugin it listens for and prevents default on all touch events. Otherwise things like page selection, scrolling and pinch-to-zoom happen, which is never wanted in a C2 game.

    Unfortunately this does block scrolling to such as in your case. TBH the runtime isn't really designed for that, it basically takes over the whole page. I can think of 2 possible workarounds:

    • add touch event listeners with capture, so you get them first, and stop propagation on them so the runtime doesn't see them - but then none of the C2 game's touch events will work
    • put the game in an iframe and float any content you want to pop over it in the parent document. Since it's a whole other document you're in full control of touch events.