Tag Info

New answers tagged

0

You should do a bounds check as you mentioned then reduce the velocity so you don't get shaky behavior. You kind of got it but I'm not sure what displacement does. //This code goes after velocity is set if (position.x > 50) { position.x = 50; //If we're heading towards the bounds, stop if (velocity.x > 0) velocity.x = 0; } else if ...


1

dt, which I'm assuming is the time between frames, should be added to m_time at the beginning of the frame so that m_time will be the time since the start of the game when you use it later on in the frame, assuming that's what m_time is.


3

Here are some more thoughts to complement the existing answer. Gaffer On Games has a great article on game loops that has been referenced everywhere. Your game loop should have different independent stages: Input, Update, Render. You could for example read inputs 30 times per second (or in real-time for better responsiveness), do 30 updates per second and ...


41

tl;dr don't mix your event loop with your game loop. When you move your mouse, the game receives a load of pygame.MOUSEMOTION events. You don't actually use these events to update your mouse position though, you are getting the current state of the mouse using pygame.mouse.get_pos(). That's inefficient, but it's not the problem. The problem is you are ...


2

Your approach is unfortunately not framerate independent. You correctly notice the need to factor in the amount of time passed between each update in your physics calculations. However, you still specify the amount of time passed in units of frames. If your framerate changes, now your speeds have all changed with respect to the passing of real time. What you ...


0

When handling games with a fixed time step, which is what you would need to simulate a physics system, it is best not to go with the system Timer as it is not as precise as other methods (even though the difference is small). Here is an example of how you might go about running a game loop that iterates 60 times a second. public void run() { double ns = ...


2

System.currentTimeMillis() should be changed to System.nanoTime() / 1000000; currentTimeMillis has an issue in it that sometimes comes back with a weird number and in games causes twitching in animations and graphics


1

I'll answer multiple related questions at once, because it's easier to understand when everything related is at one place. The best way your game loop can be implemented is to have constant game speed and variable FPS. Note that this does not mean it's the easiest way. Why is it so and how it can be implemented is nicely described in deWitters article, ...


1

to 1, 3, 7: I assume by "the game falls behind and needs to catch up" you mean, your update-rendering cicles are taking more time than they should, depending on the desired UPS and FPS length. In that case: In the methods for updating physics I know, the physical behavior changes when you change the deltaT time step. This would mean, if you simply take the ...


4

Yes, generally, games are a single main loop. Games in Java may have a separate main loop for each menu/screen/mode due to Java's idioms, but that of course does not solve your animation wait problem. For things like the problem you are running into, consider using events. e.g., when your animation system finishes playing an animation, it can send out an ...


0

The power of writing things down. Ok so after writing my question I worked it out. My original OnDrawFrame() code was at fault. In it's presented form the delta time was not taking into consideration the milliseconds elapsed by anything outside of the OnDrawFrame() function. The updated code below time_delta = System.currentTimeMillis() - time_x0; ...



Top 50 recent answers are included