I say it's a timer design error because getTime() can return some huge numbers. On my XP system right now it returns an integer 1393827623 which isn't a problem until you start doing floating point math with it. Most people will not be aware of this and could see major precision errors in their time based math. I think this is one of the design flaws in the timing within the engine. A short term fix would be to have getTime() return milliseconds from engine start.
It could also be considered a bug that animateWaterSurface() passes this huge time number right into sin() and cos() which results in very jerky wave animation. For now to fix this i suggest changing the time variable in animateWaterSurface() from...
Code: Select all
f32 time = os::Timer::getTime() / WaveSpeed;
Code: Select all
f32 time = (f32)fmod( os::Timer::getTime() / WaveSpeed, core::PI * 2.0f );
Long term I believe that the use of time in the engine needs to be completely re-written. First of all as long as you use absolute time values in the engine you will either run into precision issues or wrap around. Most games use delta times so that the wrap around is handled within the timer code and precision issues are the responsibility of the code accumulating deltas.
For further reading check out the "Time in games" notes from a presentation given by Brian Eiserloh from Ritual at http://www.dallasigda.org/notes.htm.