Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (769)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (855)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Could someone explain to me the update method?  (Read 1810 times)
0 Members and 1 Guest are viewing this topic.
Offline nelsongames

Junior Devvie


Medals: 3



« Posted 2018-04-08 05:03:40 »

Can someone explain to me why you need an update method that udpates the game 60 times / second, and why generally it's a bad idea to run the updates in the method where you're rendering the screen?

If anyone can link me to an article about this that'd be awesome.
Offline Phased
« Reply #1 - Posted 2018-04-08 05:36:42 »

separation of concerns.

You want to make your code as easily understandable as possible, trying to bake a cake by mixing the ingredients while its cooking is not ideal. We should mix the ingredients, then cook (bake) it.

In game development we should update the game then render it, not try and update it as we render it.

Another good reasoning is, we can control the updating separately to the game FPS, some games will cap the amount of updates per second, or run at a higher update rate (e.g. with physics). Having the update tied to fps would also make the game less smooth when a player has lower fps.
Offline nelsongames

Junior Devvie


Medals: 3



« Reply #2 - Posted 2018-04-08 06:19:11 »

Having the update tied to fps would also make the game less smooth when a player has lower fps.

Yes that's what I mean, when you're calling the delta time from one frame to another and using that to only update the game (not render) 60 times / second, wouldn't that hinder performance? Or am I missing something.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Phased
« Reply #3 - Posted 2018-04-08 06:43:03 »

Having the update tied to fps would also make the game less smooth when a player has lower fps.

Yes that's what I mean, when you're calling the delta time from one frame to another and using that to only update the game (not render) 60 times / second, wouldn't that hinder performance? Or am I missing something.

I am confused on what you are trying to say.

Are you saying updating the game every frame is a performance hit? Of course it is, but it also can't be helped, unless you your game never changes, at that point, it is just a single image.

If you are trying to say you want to reduce the update rate from 60 updates per second to 10 updates per second because you are using delta time, that is possible, but your game will feel not feel very responsive unless you make another update like function that processes user input / menu control / what ever else, and only let the game logic be updated at 10 updates per second (may be acceptable for a turn based game).

My quote was more towards not using delta time. Also remember, you need smarter collision detection when you are using  delta time, if my character moves at 10 meters a second, and for some reason my game freezes for 10 seconds, the delta time would then mean my character moved 100 meters in the update, if you are doing collision by checking to see if your hitbox is inside of another hitbox, I would teleport over all objects that are less then 100 meters away.

So having a lower delta time for the above situation would increase the accuracy of the collision detection. So forcing 60 updates per second would ensure that the collision detection is always accurate to that precision.
Offline nelsongames

Junior Devvie


Medals: 3



« Reply #4 - Posted 2018-04-08 18:30:53 »

snip


No no, I'm saying why update the game 60 times a second vs just letting it update continuously as the game is rendering. So for example why do this



When you can just do something like

1  
2  
3  
4  
public void run() {
    update();
    render();
}
Offline nsigma
« Reply #5 - Posted 2018-04-08 19:12:42 »

So that people with slow computers don't play at an advantage. Eg. game logic happens at a constant rate even if the rendering can't keep up.

Praxis LIVE - hybrid visual IDE for (live) creative coding
Offline ByerN
« Reply #6 - Posted 2018-04-09 21:31:45 »

The best is having game logic in another thread. Separated from game view as far as possible.

Making game logic dependent from rendering will cause for example: slowdown of logic if rendering got slowdown.

Bad implementation can cause bugs like: bad collision detection on frame drop (long time ago there were bugs in old FPS games for example), slowing rendering if logic is "hardly thinking" (freezing). Usually, you don't want something like this.

Separation of concern in this case could make your game "thinking" not dependent from "showing" which is helping in readability a lot (as said in previous comments) and will help you with critical situations of unsuspected client behaviors (frame drop/frame kick) or game logic braindeading.

Ofc you can workaround it various ways (for example: get rid of state update -> make it as a function) with some more or less great result but it's much better to separate your model from view.

Offline KevinWorkman

« JGO Plugged Duke »


Medals: 285
Projects: 12
Exp: 12 years


HappyCoding.io - Coding Tutorials!


« Reply #7 - Posted 2018-04-10 02:18:50 »

No no, I'm saying why update the game 60 times a second vs just letting it update continuously as the game is rendering.

Different devices run at different framerates. Let's say my computer can run at 120 FPS, whereas my phone can only render 30 FPS. If I program a game for my computer, then it'll be very slow on my phone. If I program a game for my phone, then it'll be too fast on my computer.

The code you posted in the screenshot solves this problem by running the update function multiple times on slower devices. That way my phone will step 4 times for every drawn frame, so it will look like it's running at the same speed as my computer.

I actually don't like this approach, as it's a bit hard to understand and feels a little bit hacky.

Instead, I like the approach that libGDX takes. You can update your game for each rendered frame pretty much exactly like you're describing, but you then have to take into account the amount of time that has elapsed since the last frame and move your scene relative to that. So if you want something to move 60 pixels per second, then on my phone you have to move it 2 pixels per frame, and on my computer you'd have to move it .5 pixels per frame.

HappyCoding.io - Coding Tutorials!
Happy Coding forum - Come say hello!
Offline nelsongames

Junior Devvie


Medals: 3



« Reply #8 - Posted 2018-04-10 02:38:42 »

Different devices run at different framerates. Let's say my computer can run at 120 FPS, whereas my phone can only render 30 FPS. If I program a game for my computer, then it'll be very slow on my phone. If I program a game for my phone, then it'll be too fast on my computer. (snip)

Ah this explains it perfectly, thank you so much and thank you to everyone else that helped explain Smiley, I understand why now.

So basically even though one machine can render 500 frames per second, if your game logic isn't fixed to a specific number of updates per frame (so 30-60FPS), then this can cause issues with compatibility across several devices. So we have to take into consideration that we want the game to run exactly the same across devices, and not faster on some, and then slower on others.
Offline nsigma
« Reply #9 - Posted 2018-04-10 08:50:52 »

The best is having game logic in another thread. Separated from game view as far as possible.

Making game logic dependent from rendering will cause for example: slowdown of logic if rendering got slowdown.

Actually while making game logic truly independent from rendering is possible, and perhaps desirable, it needs careful architectural thought.  Just been having a similar conversation with someone on the Processing forum trying to do this and running into lots of exceptions (CME, etc.) because of a lack of understanding of concurrency.  Kevin's approach on delta time is probably the best approach for most projects, at least until there's a demonstrable benefit to be had from parallelizing this.  I'm not sure bad collision detection algorithms count!  Wink

Praxis LIVE - hybrid visual IDE for (live) creative coding
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline fenaryh
« Reply #10 - Posted 2018-04-17 00:51:50 »

I recommend these two links to a better understand for games in general:

http://gameprogrammingpatterns.com/game-loop.html
http://gameprogrammingpatterns.com/update-method.html

And also recommend this whole book, lol

Regards
Offline Damocles
« Reply #11 - Posted 2018-04-18 15:11:18 »

A good overview is here:

https://github.com/SilverTiger/lwjgl3-tutorial/wiki/Game-loops

this is a gameloop with a fixed logic-timestep
and a variable render timestep:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
public void gameLoop() {
    float delta;
    float accumulator = 0f;
    float interval = 1f / targetUPS;
    float alpha;

    while (running) {
        delta = timer.getDelta(); //eg: = timeNow - timeLastCall
        accumulator += delta;

        input();

        while (accumulator >= interval) {
            update();
            accumulator -= interval;
        }

        alpha = accumulator / interval; // between 0 and 1, used to smooth animations and movement
        render(alpha);  

        window.update();
    }
}


It has the advantage of frame rate independent constant-time logic updates, while allowing frames to draw as fast as the client can do it.
Constant-time logic ticks are way easier to program, and avoid edge cases when the framerate drops too low or runs too fast.
Pages: [1]
  ignore  |  Print  
 
 

 
EgonOlsen (1577 views)
2018-06-10 19:43:48

EgonOlsen (1662 views)
2018-06-10 19:43:44

EgonOlsen (1148 views)
2018-06-10 19:43:20

DesertCoockie (1577 views)
2018-05-13 18:23:11

nelsongames (1177 views)
2018-04-24 18:15:36

nelsongames (1668 views)
2018-04-24 18:14:32

ivj94 (2426 views)
2018-03-24 14:47:39

ivj94 (1634 views)
2018-03-24 14:46:31

ivj94 (2725 views)
2018-03-24 14:43:53

Solater (888 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!