Consider depending on fixed crate for fixed point, instead of reimplementing

[ids1024]

The fixed crate seems to have a fairly good implementation of fixed point arithmetic, and with the cordic crate it can be used with trig functions. It may be better to use this crate instead of implementing fixed-point integers in gba.

Otherwise, a cordic feature to implement cordic::CordicNumber could be useful.

[Lokathor]

You make a good point.

I would like to make the crate still build with all zlib licensed code though.

I think that a minimal fixed point newtype as a placeholder and then the fixed crate is used as an optional dependency (on by default) would offer good functionality while satisfying my (perhaps silly) licensing ideology.

[Lokathor]

One concern though is that the trig functions provided by other crates couldn't be put into iwram so easily. That's not a huge concern, but it's something we probably want to note when documenting the cargo feature.

[ids1024]

If gba doesn't depend on fixed, it could also be useful to have a feature to at least provide From conversions, which should be fairly simple. Currently I have functions to convert from fixed types so I can use fixed/cordic to implement matrix transformations. (Which may not be the most optimal way of doing things but it works.)

Like cordic::CordicNumber this shouldn't be hard to add but would need to be in gba due to the dreaded orphan rule.