Ggez: Why the library use the f32 and i32 types and not the f64 and i64?
I'm building a physics simulation with ggez as graphics library, and I'd noticed all the construct use 32-bit precision type (for example Circle's tolerance, accepted Point2 and Vector2).
Why this particular design decision?
There is the possibility to build a generics interface for generalizing the library to 32 and 64-bit precision type?
eisterman
All 3 comments
The resolution of screens is low enough that the extra precision from f64s is invisible. Partially because of this, most GPUs handle f32 far more efficiently and generally expect them. So supporting them in the API doesn't really bring any benefit.
Generics could add support for f64 in the drawing API but would make life more difficult, and it's harder to read code and docs that uses a big tangle of generics and traits to let you do conversions. So again, more cost, small (but nonzero) benefit.
icefoxen
on 27 Apr 2018
How ggez draws things shouldn't affect your physics in any way: nothing is stopping you from using 64-bit types for the simulation and truncating/casting them to 32-bit ones for drawing via ggez. If timestep resolution is a concern, it's possible to roll your own update loop - there is an example for that, I think.
Ratysz
on 27 Apr 2018
Feel free to re-open if you have other questions or suggestions.
icefoxen
on 30 Apr 2018
Related issues
Kasran
路
3Comments
t-veor
路
5Comments
TakWolf
路
4Comments
icefoxen
路
4Comments
icefoxen
路
5Comments
Most helpful comment
The resolution of screens is low enough that the extra precision from f64s is invisible. Partially because of this, most GPUs handle f32 far more efficiently and generally expect them. So supporting them in the API doesn't really bring any benefit.
Generics could add support for f64 in the drawing API but would make life more difficult, and it's harder to read code and docs that uses a big tangle of generics and traits to let you do conversions. So again, more cost, small (but nonzero) benefit.