开云体育

Oh, I completely missed that... Frame rate has a specific meaning vis-脿-vis the number of screen refreshes.

Once we have separated the rendering from the time keeper, you are correct. However, previously we(I?) was using "frame rate" as a simple term to refer to how often the function gets called. (Before

One more question regarding the actual calculation. The question that comes to mind is "what is the trigger that causes the penguin to be rendered on the screen?" Is there some internal timer?

Ron Jeffries wrote on 17.2.2013 13:39: If we happen to have some domain knowledge of game development and common patterns in game design, we might decide to decouple the physics time step from the

This email needs to be posted as an article online so we can easily reference it when we talk to our clients, coworkers, and friends.

Hi Amir, Of course it didn't have to do with TDD. It has to do with the laws of physics. It has to do with understanding the problem and is possible solutions. It has to do with understanding what

So to sumerize, 1. Research the problem to work around unknowable areas. 1a. Become convinced that its possible to know the unknowable in an abstract way. 2. Abstract the things which cause the

Sorry for not being clear. I meant that the derivation of the formulae that you THEN implemented in TDD did not have anything to do with TDD. From: testdrivendevelopment@...

Hi Amir, Let me suggest that you read again, and think again ... Ron Jeffries www.XProgramming.com You never know what is enough unless you know what is more than enough. -- William Blake

Amir, Look again. That's what I was talking about when I said, Abstracting external systems, even ones as ubiquitous as the system clock, is essential i

Great job analyzing this, Ron (seriously). Thing is, none of it had anything to do with TDD...

OK, that makes it even simpler. This is where TDD can tell you whether you've reached your final destination or not. You can calculate the exact point where the penguin should stop "in the real

Ron, very impressive, thank you. Part of what was tricking me, is the fact that I don't know that I want the penguin to go 900 pixels in 2 seconds. I want the penguin to go as far as it can, for as

You are correct, you multiply the velocity by the dt not add. Another change I'll have to make to this old system :) brought to you by the letters A, V, and I and the number 47

Hi Avi � I was supposing that dt is some kind of a time value. I imagined that it meant "delta time" or "change in time since last time". Its dimensions must surely be "seconds" or some other time

My comparison was supposed to be regarding the culmative calculation, not the per tick calculation. Ill have to look up when velocity is multiplied vs when it's added.

I may be missing something about this whole discussion, but isn't the dt part supposed to take care of the delta in time? I.e., the variation should be in that, rather than in some factor.

All, 30/32 = 0.9375 Ron Jeffries www.XProgramming.com Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

Hi Avi, yes, I think the solution described in that article will solve this problem and is a good way to do it. But the other option should be ok, too. I use something very simple like this: x +=

Hi Avi � That formula (x += dt + v) doesn't seem right to me. if velocity is v meters per second, then the distance travelled in time interval dt is v*dt, isn't it? so I'd expect x += v*dt always. I