Fixed point can still fit a good 30 seconds or so worth of whole milliseconds, can't it? Are you ever going to have updates more than 30 seconds apart?
Even if you are, you can just convert to seconds. Use the integer representing portion of the fixed point from 1<<16 up for whole seconds. Use the fraction representing portion below that for the remainder. That said, I'm working on a game where all the values passed to OpenGL are fixed point and most of the calculations are as well. I just pass the time delta around as a non-fixed point integer, however. It's never a fraction and never passed to OpenGL directly, so you aren't forced to convert it. The various speed constants in the game take into account that it is much smaller than if it were shifted into fixed point is all. By the way, you may want to use SystemClock.uptimeMillis() instead of System.currentTimeMillis(). System.currentTimeMillis() is documented as jumping around occasionally: http://developer.android.com/reference/android/os/SystemClock.html On Dec 29, 10:25 am, Mika <[email protected]> wrote: > Like the topic of the thread says. In my game I would like to turn all > the calculations into FP format. I can eliminate pretty much > everything else but I still need to do the the following calculation > in long format. > > Code: > long t = this.lastUpdateTime - System.currentTimeMillis(); > > The value I get from this is the time passed since last frame, which > is like.. two digit millisecond value, which naturally is more than > good for FP stuff. After that calculation I turn the resulting value > into FP integer and use it with the rest of my calculations but I'd > like to get rid of that long calculation too. Any ideas how to go > around this to do it in FP format? > > I mean, I'm pretty sure I cannot just go and do a normal conversion to > FP format in this style: > Code: > int fpT = t * (1<<16); > > because there is always the change that it'll overflow and as the > numbers that System.currentTimeMillis() give out are BIG. > > So any advice how to keep the same "accuracy" of the timer but get rid > of the long calculation and have it replaced with nice and fast FP > calculation. Any advices on how to trim down the > System.currentTimeMillis() or what ever to get around this are greatly > appreciated. > > Cheers guys. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
