Better yet, use std::chrono. Yes, it's C++. But this is an example of how properly applied bits from C++ can make things easier to reason about and type-safe, rather than "let's avoid C++ as much as possible".
No ambiguity for the programmer as to what the underlying units are, and no unnecessary int/float conversions. All the book-keeping and conversions are taken care of by the compiler with zero run-time size or perf overhead.
std::chrono is a terribly overengineered API even for the STL, and many game companies have banned parts or all of the STL for good reasons (usually not std::chrono related though).
Using an uint64_t (instead of uint32_t or double) to carry "opaque ticks", and a handful conversion function to convert to real-world time units is fine and just a few lines of code.
Comments
Better yet, use std::chrono. Yes, it's C++. But this is an example of how properly applied bits from C++ can make things easier to reason about and type-safe, rather than "let's avoid C++ as much as possible".
No ambiguity for the programmer as to what the underlying units are, and no unnecessary int/float conversions. All the book-keeping and conversions are taken care of by the compiler with zero run-time size or perf overhead.
std::chrono is a terribly overengineered API even for the STL, and many game companies have banned parts or all of the STL for good reasons (usually not std::chrono related though).
Using an uint64_t (instead of uint32_t or double) to carry "opaque ticks", and a handful conversion function to convert to real-world time units is fine and just a few lines of code.
This is exactly what we do.