Jump to content

  • Log In with Google      Sign In   
  • Create Account

thok

Member Since 23 Dec 2011
Offline Last Active Mar 21 2016 01:50 AM

Posts I've Made

In Topic: Fixed time step clarifications

07 March 2016 - 03:05 AM


I have been trying to wrap my mind around incorporating a fixed time step (dewitters game loop) into my game for almost three months now, but I just can't seem to conceptualize it in my mind for my game. I've read posts upon posts, articles upon articles, but still have a lot of questions.
 
So in short most of the articles say (and my understanding is), you separate the "updates" from the "render" and then use the difference in time and pass to the render to interpolate. 

 

Others have mentioned it and I'm sure you've read it already, but this article is what helped me to fully understand this concept: http://gafferongames.com/game-physics/fix-your-timestep/. 

 

To quote from the article, this sentence specifically describes conceptually what needs to happen:

"The renderer produces time and the simulation consumes it in discrete dt sized chunks."

What does this mean? It means that in your game loop, the first thing you do is check the time (t0), render a frame, and check the time again (t1). Assume for example that time elapsed between t0 and t1 (t1 - t0) is 34 milliseconds. Assume also that your "fixed timestep" for your physics/updates is 10 milliseconds (dt). The "render" stage produces 34ms, and the the "update" stage consumes the time in "discrete dt sized chunks"--that is, 10 ms chunks. That means that for this frame, you will run your update procedure 3 times, stepping forward by 10ms each time. Then you're going to have some time leftover: 4 ms. It is with this remaining value that you interpolate on your next render call.

 

 

 

When they say render are they speaking the actual process of drawing on the screen or the setting of values in the render (sprite x/y)?

 

Yes. When drawing, you interpolate position based on how far you are "between frames". In this case, you're about halfway between. I imagine this would not only to sprite position, but also to animation states, assuming those movements are also time-based.

 

To summarize, you basically end up with an update system which lags 1 frame behind the rendering. This may seem "wrong" somehow, but it works.

 

I can't help much with the networking portion of things (I've never programmed networked games), but I think using a queue somehow is the right approach.

 

If it helps, here's a real working example of such a loop that I wrote in Java: https://github.com/larsbutler/gamedemo/blob/master/src/com/larsbutler/gamedemo/core/Kernel.java#L68-L104

 

It's been a few years since I wrote that and some of the code is there is pretty odd, but that particular game loop is pretty solid, IMO.

 

Hope that helps.


In Topic: Unity vs. a more "lean" game engine

02 February 2016 - 08:15 AM


I just don't find it exciting to work on actual game, but I like to see when the game builds on all the fundamental blocks delivered by the tech.

 

I can really relate to this, actually.


In Topic: Unity vs. a more "lean" game engine

02 February 2016 - 04:13 AM


So yeah, maybe try to step outside your own shoes and think about what would make your artist friend more productive. Chances are he will have MUCH more work to do than you as a programmer, depends on the project you are working on of course. But with the engine taking away lots of the low level plumbing, if the game is actually reasonable simple, the code might not be so hard to do anyway, while the amount of assets and level design needed might still be quite overwhelming.
If he is able to work faster in Unity, and you just "don't like it because the code looks unclean", but can work in it, maybe you should give in and let him have his way.

 

This is good advice. When we first discussed using Unity, by my reaction he was pretty sure I was going to say no. We've talked about since then and have decided to give it a try, but in a few months after my game development course is over. [I don't really have the mental bandwidth to learn two game engines at once, go to school, and work 100%. =) ] But we are going to give Unity a try.

 

In the meantime, we're going to work on something together using Blender and jMonkeyEngine. He's already done not only modeling but entire level design (relatively simple stuff) purely in blender, so we'll see how it goes. I'm going to be alert to the pains of the modeling/level design/art pipeline which are likely to come up, and then I'll probably have more of an appreciation for Unity. =)


In Topic: Unity vs. a more "lean" game engine

02 February 2016 - 03:58 AM


The first time I started up Unity I was like dude...? Where the hell is my main? Where do I start typing!?

 

This was also my first thought. Glad to hear I'm not alone. =)


In Topic: Unity vs. a more "lean" game engine

02 February 2016 - 03:56 AM


I wouldn't worry too much about your first impression. There's an easy way for you too find out: just make a simple game in Unity, finish it and then look back and reflect. It doesn't have to take long, you could probably do it in a weekend.

 

I think this is the single best piece of advice in this thread.


PARTNERS