WackyToaster's Forum Posts

  • just curious why you'd ever want your game to go above 60fps

    I have a 240hz montior. Sadly not because my PC is strong enough to support it (unless the games are older) but simply because my old one died and this one was on sale :V My Laptop also has 144hz. Construct games run tied to the monitors refresh rate, so as long as the PC can handle it the game WILL go above 60fps naturally. I'd be quite sad if a game doesn't reach 144hz on my 144hz monitor, especially if it isn't 3D maxed-out eye-candy.

    To be fair, my own game also runs at around "only" ~150fps though considering the 2D nature it probably should be more. I just noticed... it does run at 240 in the preview but not in the export. Hmm...

    In any case, the faster the game runs the better. If it hits 240fps on your machine it might just hit 60 on an older one. But if it already is chugging along at 60 on yours, the older one might hit 10 fps and it's unplayable.

  • editor.construct.net

    Then start building. Set a (small) goal of something you wanna make. Make prototypes. When you get stuck --> Check the documentation (https://www.construct.net/en/make-games/manuals/construct-3), check the Forum, try a google search, ask (forum/discord)

    That's how I did it, but admittedly it involves a lot of banging your head against walls sometimes but I feel like you'll encounter that no matter what.

  • Yes I can confirm, it's solved now.

  • Jup I get it too. I don't wanna delete my cache and reinstall all the addons. Guess I'll roll with r264 for the time being.

  • Actually you can rather easily roll back :)

    construct.net/en/tutorials/open-project-saved-newer-2203

  • I've learned that lerp with dt is technically NOT framerate independent. Just so you know.

    construct.net/en/blogs/ashleys-blog-2/using-lerp-delta-time-924

  • Have you checked the Race track example ?

    It actually does pack such a ranking system with checkpoints.

    You need to push these much more, nobody thinks about checking these for some reason :D Maybe if someone makes a thread and mentions a XYZ game hint that there is an example project to check out (like you do with similar threads)

    I just took a quick glance at it but it seems to be similar to what I described. Cool!

  • With an array perhaps?

  • How about additionally checking the distance between the previous and the next checkpoint?

    distance(player.X,player.Y,prevCheckpoint.X,prevCheckpoint.Y) / distance(prevCheckpoint.X,prevCheckpoint.Y,nextCheckpoint.X,nextCheckpoint.Y)

    This gives a value between 0 and 1 as how far the player is between the checkpoints, e.g. 0.78 (= 78%)

    You add the number you already have that gives +1 per checkpoint and add to this the number between the checkpoints. The player with the higher number is further along the track. Like player X has checkpoint 2 and is 55% along the track = 2.55 and player Y has checkpoint 2 and is 54% along the track = 2.54.

    EDIT: You probably want quite a bunch of checkpoints for this to work properly, especially when there are many curves involved. Here is a checkpoint map from mario kart for reference.

    EDIT2: You probably need to check for shortest distance rather than distance to the origin point especially at the finish line where it really matters to be exact... Not 100% sure how that works but I guess the player that passes it first wins should do the trick aswell.

  • Awesome, seems pretty useful!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Have you tried -600? I think that could work but I haven´t tested it.

  • There´s a variety of options. Tween with ease in & ease out should do the trick.

    construct.net/en/make-games/manuals/construct-3/behavior-reference/tween

  • I don't think I wanna do that, I´m way too deep into using tile movement. And I don´t even think it would solve the issue with the pause. The movement itself is framerate independent, the pause isn´t. Changing the movement to anything else will still have the pause being a problem.

    However, I think I found a solution that works well enough for me. I´d say 95%, which is good enough for my case. It´s still hacky, but better than what I had when I started the thread. What I´m doing now is to adjust the speed of the cyan square depending on deltatime, making it slower the higher the framerate. This accounts for the shorter duration spend on the tick it pauses. Basically I just set the speed to 500 + (500*dt)^2 The difference is small enough to not matter, and I probably could still tweak it to be even more precise. I should note that this isn´t some mathematically correct formula, I just cooked it up and found it to work very well. ¯\_(ツ)_/¯

    So unless someone stumbles on an even better solution, I´ll roll with this. Thanks for the help everyone.

  • How do you "simulate" different frame rates to see that "it does not produce results"

    My old screen died so I bought one with 240hz and I switch the hz up or down in the settings to test and compare how far the cubes go apart over the course of the movement across the screen, as that should be the same if it were framerate independent. Also there is the Framerate mode in the advanced options where you can have the game running as quick as it possibly can, which is somewhere around 2000fps in my game. I was already aware before that something isn´t framerate independent, but having the new screen kind of put a little more priority on it.

    You explained what you did, as far as code goes, but I do not know what mechanic you are attempting to achieve and what result.

    The object with tile movement that stutters is the (usually invisible) player object. The other one that follows is the actually visible sprite of the player. I just don´t want the player character to visibly stutter when moving, as it would if I were to just pin the sprite to the player object. So they are seperate and while the player object is waiting for the function to go through, the visible sprite has time to catch up. (But overall it should always be just slightly behind)

    As dop pointed out, dt is working just fine and the dark blue square moves as it should. So the question now is how to make the cyan square move framerate independent. Artificially extending the pause from 1 tick to 0.03 seconds should do the trick, but it doesn´t work.

    Here´s a comparison with the 0.03 second delay. I´ve also timed the movement of the cyan square at different fps and it takes 4.3 seconds at 60fps, 4.2 seconds at 240fps and 4.1 seconds in "unlimited" mode. So it is not framerate independent.

  • That doesn´t work though, it still produces different results depending on framerate.