The gameloop function was declared when money had the value 100, in the initial render. It is this same function, in whose scope the money variable is still 100, that gets called on each frame, rather than the function that gets created on each render (which has the "freshest" value in money).
You are doing nothing wrong. This is because the React state is updated asynchronously. This mean when you want to console log the state of the money variable, the state is not updated yet. What you can do is log it from the useEffect function, something like this:
So, my game loop allows for the rendering to be skipped if game updates and rendering do not fit into my fixed time-slice (16.667ms). This allows my game to run at identically perceived speeds on different devices. And this works great, things do run at the same speed.
However, when the gameloop skips a render call for even one frame, the sprite glitches. And thinking about it, why wouldn't it? You're seeing a sprite move say, an average of 10 pixels every 1.6 seconds, then suddenly, there is a pause of 3.2ms, and the sprite then appears to jump 20 pixels. When this happens 3 or 4 times in close succession, the result is very ugly and not something I want in my game.
Therfore, my question is how does one deal with these 'pauses' and 'jumps' - I've read every article on game loops I can find (see below) and my loops are even based off of code from these articles. The articles specifically mention frame skipping but they don't make any reference to how to deal with visual glitches that result from it.
I've attempted various game-loops. My loop must have a mechanism in-place to allow rendering to be skipped to keep game-speed constant across multiple devices (or alternative, if one exists)
I've tried interpolation but this doesn't eliminate this specific problem (although it looks like it may mitigate the issue slightly as when it eventually draws the sprite it 'moves it back' between the old and current positions so the 'jump' isn't so big.
I've also tried a form of extrapolation which does seem to keep things smooth considerably, but I find it to be next to completely useless because it plays havoc with my collision detection (even when drawing with a 'display only' coordinate - see extrapolation-breaks-collision-detection)
I've tried a loop that uses Thread.sleep when drawing / updating completes with time left over, no frame skipping in this one, again fairly smooth, but runs differently on different devices so no good. And I've tried spawning my own, third thread for logic updates, but this, was extremely messy to deal with and the performance really wasn't good. (upon reading tons of forums, most people seem to agree a 2 thread loops ( so UI and GL threads) is safer / easier).
Now if I remove frame skipping, then all seems to run nice and smooth, with or without inter/extrapolation. However, this isn't an option because the game then runs at different speeds on different devices as it falls behind from not being able to render fast enough.
These are all great, but they don't touch on the issues I'm experiencing. I really have tried everything I can think of over the course of a year to eliminate these glitches to no avail, so any and all help would be appreciated.
From what I see, the game loops you are trying to use are somewhat specialized. I don't know why you chose those ones, but in my opinion you are trying to solve problems that don't exist in the first place.
A common idea in modern games is that it is more acceptable for the display logic to fall behind, than for the update logic to fall behind. That means that, if for example a frame takes longer to display than usual, the game state should still be running in real time, even if some frames are dropped.
Notice that we are fixing one update() call for each draw() call. With such a game loop, you will be showing all frames, while capping the frame rate. However, if one iteration of the loop takes more than draw_logic_step, then the game will slow down (but no frames will be dropped).
Those two game loops should suffice for the vast majority of games. Variations with interpolations, extrapolations, multiple threads and the like, are in my experience used only to optimize for corner cases where you want to push the update logic to the limit, yet keep the game running as smooth as possible.
Doing such optimizations though, is complex, and will make the game much more difficult to write and debug. In my opinion, you should start with a simple game loop as above, and you will see that it will work pretty well.
If your game is simple enough, and you are still dropping frames regardless of the game loop you use, then I would be inclined to think that the problem is not within the game loop but on your actual processing. What I would do is remove the fancy gameloop, use a simple one, and focus on understanding why are you skipping frames and fix that instead. Unfortunately, this changes the discussion from gameloops to how to debug and fix your code.
On a comment, you mentioned that your update logic is taking 4ms. For 60fps, that is quite a lot, as it's about 1/4th of all the time you have for each frame. 4ms is not borderline high, but you may want to ask yourself why is it taking so much.
If vsync is making your program stall for a whole frame, it is because you already missed the previous frame drawing deadline. Removing vsync won't solve this, and you still have to make your program run faster.
Remember that your program is written in Java, which is a garbage collected interpreted language. Even if you do everything right, garbage collection cycles will stop your program completely for a very noticeable length of time, and you have no control over this. If you want to have more predictable performance, you should consider writing your game with the JNI in C. I've heard Xamarin.Android has better performance, if C# is your thing.
But even so, remember that your program is running on a mobile processor in a multitasked environment. The OS will throttle the CPU, and will yield the CPU to other processes, meaning that the performance of your game is even less predictable. If you want complete predictability, write games for consoles instead.
In the grand scale, I wouldn't worry too much about the problem you're facing. I would dedicate much more time to making sure the game is fun, because that's what really matters. I don't think that a fun game will stop being fun because of an occasional dropped frame. In fact, with so many things going on in the screen at the same time, I doubt people will even notice dropped frames, but that is just my humble opinion.
Reduce your target frame-rate below 60: Some devices are just so poor in performance that you cannot expect 60fps. There are many examples of commercial games which run at or below 30 fps, and most people don't notice the difference. 60 is ideal, but you just can't expect many mobile devices to be able to handle 60fps for any serious game.
Code Optimizations: If there are things that you are doing every frame, which you could do less frequently, then you should consider having a secondary update function which occurs only every X frames. Look for bottlenecks. Do some benchmarking and determine what in your loop is taking the most time, and try to determine if there are faster algorithms for what you are doing. Try other algorithms and see if the benchmarks improve.
Reduce the game quality: Reduce the number of game objects; Do fewer draw calls; use faster shaders; Reduce shadow and lighting quality; Use lower polygons objects; etc. You could even allow the player to customize their own quality settings.
Release two different versions. A low-end version with 30fps and a high-end version with 60fps. Make it clear to the players that they are not the same. You could even consider removing features from the low-end version to make it even more obvious. ('Limited' and 'Full' versions.)
Don't support low-end devices: You just can't expect all devices to be able to handle 60fps. If you absolutely have to have 60fps, then drop support for any devices that cannot keep up. Try to optimize as much as you can and are willing to, but at some point you just have to say: "This device is not worth the effort to support it." The big game companies do this for good reasons!
What causes these multiple calls to glcompilershader? I can only guess happens because the shader is invalid but I get no errors at creation. Not sure if accessing attributes in the shader causes a recompile of the shader.Still trying to debug this nightmare.
SickGamer Fps Drops are From The Game Side. You have to install the 32 bit version of gameloop because 64 bit is facing lag. On the other Download Atlas Os as it will help you to reduce Latency and Increase Fps in Game.
I've tried to install Gameloop app (an android emulator) on my surface pro 7 ,but there are several errors popping up as soon as i start the installation,and most of them are ".dll" related.i've tried to download the required dll files manually,but it does not work.
I've installed bluestacks(another android emulator) though,and it runs perfectly on my device,butdue to some lag problems i need to install the gameloop.
tnx for your support
Haven't received your message a few days, was your issue resolved?If not, please reply and tell us what's going on to provide further assistance.
If the reply is helpful, please accept it as answer to help other community members quickly find useful responses.
If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Gameloop is built For High performance gaming on pc. There are two versions of tencent gaming buddy + gameloop beta 7.1. you need to install beta it's for windows version.
Gameloop Gobal
Gameloop beta 7.1