开云体育

let f = new framerate let g = old framerate x += dt*(g/f) + f*v f = 32 and g = 30 gives me g/f = 30/32 = 0.9375

Actually, this reminds me of my microcontrollers course back in college where we had to bridge between two different sampling rates... In that course we had to actually use three different sampling

I would expect that the 0.937 factor is a calculated factor that somehow incorporates the fact that you are comparing framerates of 30 and 32 fps... In other words, your calculations are relativistic

Avi, I have to agree with Stefan. If I assume that the calculations do not work the same for different framerates, then that would imply that I need to write custom code to alter the calculations for

In the case of a flying penguin it doesn't work. The basic formula for the penguin flying through the air is x += dt + v If this is calculated 30 times per second you basically get x += dt + 30v, but

Avi, the first option should work. When your test is ok for 30 fps, you can safely assume that it will work for higher framerates. Best, Stefan Am 16.02.2013 20:07, schrieb Avi Kessner:

The first option won't work, because a 30 to 60 fps has to be assumed. That second option might be what is needed however. However, not the fixed time step but rather the " Free the physics" section.

Avi, It sounds like a typical problem of not abstracting the external source of timing. You should be able to calculate into the future without being tied to the system clock. - George

I don't think this is very heisenbergish... :) The first option is to assume a sensible minimum framerate (perhaps 30 FPS) and make that a specification for your game. (With 10 FPS it probably won't

Yes, the code is the same. See http://www.niksula.hut.fi/~hkankaan/Homepages/gravity.html from http://news.ycombinator.com/item?id=4934855 for another example, where how accurate your timer or

Avi, Is the calculation of the penguin's movement and the calculation of the marker position both done by the unit under test?

Avi, Have you considered refactoring so that the algorithm is extracted? You could then inject a very simple, predictable one back in for your tests. That still leaves the real, complicated algorithm

Avi, I think you are expecting something unrealistic from TDD. TDDing only facilitates 2 things: 1. Verifying that the code does what the programmer thinks the code should do. 2. Growing the code in a

As has already been suggested, it potentially sounds like there is a lack of adequate separation of front-end from the underlying model, which is making it difficult to have practical tests. You say:

"// check the position of our hero assert( penguin.position, whereEverYouWantItToBe );" Yes, that is exactly what I want to know :) I don't know where I want the penguin to end up. What I have done

Hi Avi, I'm still new to TDD and I'm not sure, if I really understand your specific problem, so maybe this is rubbish not how it should be done. I'll try anyway: If I understand this correctly, there

Avi47, One thing that tells you this is going to be hard is the name of the test. In this case, I keep getting names like this: -

It still seems to me that you're trying to use TDD to derive the equations. The programming departments are sometimes called R&D departments. The last D is the same last D in TDD. Research (and you

Hi Angel, Thanks for what you wrote. However, I don't understand the last section. I think it is the most important part! "We wrote many test files, and a test that loads a file, run it, and compare

Hi people! Ah! Thanks for the detail, Avi. I have more context. Ok, short phrases, English is not in my expertise ;-) If I were to implement something like you describe (I had some similar projects):