![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://voyager.lemmy.ml/api/v3/image_proxy?url=https%3A%2F%2Fbeehaw.org%2Fpictrs%2Fimage%2Ffed50129-04e7-4dbc-8f54-4ba5bae58370.png)
To be more specific: most often a game would run its physics calculation at the framerate it’s designed for, like 30 or 60 fps, and in case it displays with a higher framerate, try and interpolate the graphical data based on the physics calculations. It’s possible to make the physics run faster as well, but carelessly adapting things may make things go wrong (a good example is Quake 3, where your jump height changes based on the com_maxfps
value).
A racing game that runs its physics at 60 frames per second can, at best, calculate time in 0.016666...
second intervals. To have a precise 3-decimal-points clock, a game would need to run its physics calculations at 1000 frames per second.
(It is also worth noting that a game developer can try to interpolate a more precise finish time by looking at the last pre-finish frame position of the vehicle and the first post-finish frame position and calculating at what point “between the frames” the finish line would be crossed, but I don’t know how difficult and/or buggy actually implementing that would be.)
What you’re describing sounds like an issue with either A-GPS (a mechanism by which sat navs can receive initial data over a cellphone connection, without which the initial location search can last up to 10 minutes, but afterwards it will be as smooth as always) or approximate location (a mechanism in which Google uses a huge database of cell tower and Wi-Fi data to quickly get your approximate position).
I would suggest checking the permissions on the OSMAnd app – maybe it’s lacking something that Google Maps has?