TL;DR they work exactly the same; the difference comes from trade-offs like performance, value range and (sometimes) syntax.
It's is possible to simulate floating- or fixed-point math, you just have to write all logic yourself (or use library). The only limits are your creativity and resulting performance overhead.
Fixed-point math may be considered a subset of floating-point math, where exponent is constant. This leads to fewer instructions (no need to read exponent and do calculations on it) and smaller data types (no need to store exponent).
If your language of choice supports operator overloading, then syntax won't be too much different from floating-point universe:
x * y is same thing in both worlds. Copy-pasting some premade physics engine and replacing data types it operates on might just work. In case you are less lucky with language, then I wish you patience, because turning every
b*x + a into
add(mul(b, x), a) is tedious task.
Next, because exponent is fixed, the possible range of fixed-point numbers is severely limited. It's not a problem for storing things like coordinates, because even in floating-point engines objects don't go too far from origin — but when they do, coordinates start to loose precision and physics becomes wonky, so game designers try to avoid that.
But for intermediate operations this loss of range matters. If numbers go out of range during fixed-point calculations, information will be lost. (Yes, you can go out of range with floating points too, but it's much harder to do so.) This issue can be mitigated by promoting values to bigger types during calculations, but it incurs further performance costs.
To avoid underflow and overflow issues, it's better to choose all units of measurements such that most variables (and constants) will be as close to
1.0 as possible. For instance, distance of
x = 0.001 units may seem not too bad for
int16 fixed-point data type, but calculating area
x*x will blow out of range.
Using very small units of measurements stored as integers (as proposed in comments) is possible as well. Integer values may be considered special case of fixed-point without fractional part. In some calculations, using pure integers will result in even faster code.
As a side note, I presume it'll be impossible to get rid of fixed-point completely, because they have nice property of shrinking values by multiplication. You'll also would need them for all sorts of unit-less multipliers that must be compatible with any other unit type — imagine scaling object's size, weight and acceleration with same curve.
At last, it may be good idea to assign and display all values via conversion functions:
meters(3) looks more readable than
3 * 0xFFFF and allows to easily change unit representation later, would the need arise. Again, some programming languages (C++) allow to introduce measurement units into type system to protect you from mistakes and even allow to define custom suffixes, so it will be possible to write previous example as