Everything being static inline makes it hostile to these older systems which have limited RAM. Use of float makes it unlikely that you’d run it on the PlayStation, which has no FPU.
> Everything being static inline makes it hostile to these older systems which have limited RAM.
Compilers can un-inline as well. In fact, since every function is defined in the header file, the static inline annotation means very little, it's more of a hint; the functions that were not marked static inline can be inlined just as well by the compiler.
Not just limited RAM, but limited RAM bandwidth, which seems like it would make this particularly painful on the N64 (ironic, given that the in-file README says that this came about specifically to support porting a game to the N64). That said, should be possible to wrap these with some non-inlined functions in a pinch, yeah?
Re: floats, I wonder how well it'd perform if compiled with soft-float support?
Only one of the consoles listed lacks an FPU, the other two (N64 and DreamCast) both have FPUs. Despite its age, the FPU on the N64 was plenty fast and it was used extensively.
The N64's FPU will usually be faster than doing fixed point on the CPU.
You are actually multiplier/divider bound, and the CPU can multiply about 10 bits per cycle and only divide 1 bit per cycle. Since you aren't multiplying the sign/exponent bits, it's faster to multiply/divide the 24 mantissa bits of a 32-bit float than it is to multiply/divide the 32 bits of an int.
And with fixed point, you then have to throw in the extra shift instruction (which floating point automatically does internally).
Though, this only applies to fixed point on the CPU. The RSP has no FPU, but it does have a 128 bit vector unit with 8 16bit lanes which is pretty good at fixed point stuff. If you can vectorise your algorithm, it will be faster on the RSP.
[delayed]
Everything being static inline makes it hostile to these older systems which have limited RAM. Use of float makes it unlikely that you’d run it on the PlayStation, which has no FPU.
> Everything being static inline makes it hostile to these older systems which have limited RAM.
Compilers can un-inline as well. In fact, since every function is defined in the header file, the static inline annotation means very little, it's more of a hint; the functions that were not marked static inline can be inlined just as well by the compiler.
Not just limited RAM, but limited RAM bandwidth, which seems like it would make this particularly painful on the N64 (ironic, given that the in-file README says that this came about specifically to support porting a game to the N64). That said, should be possible to wrap these with some non-inlined functions in a pinch, yeah?
Re: floats, I wonder how well it'd perform if compiled with soft-float support?
I was going to say, even the readme file only mentions N64 and DC.
Most of the older consoles don't have an FPU. Fixed point is king on those older systems.
Only one of the consoles listed lacks an FPU, the other two (N64 and DreamCast) both have FPUs. Despite its age, the FPU on the N64 was plenty fast and it was used extensively.
The N64's FPU will usually be faster than doing fixed point on the CPU.
You are actually multiplier/divider bound, and the CPU can multiply about 10 bits per cycle and only divide 1 bit per cycle. Since you aren't multiplying the sign/exponent bits, it's faster to multiply/divide the 24 mantissa bits of a 32-bit float than it is to multiply/divide the 32 bits of an int.
And with fixed point, you then have to throw in the extra shift instruction (which floating point automatically does internally).
Though, this only applies to fixed point on the CPU. The RSP has no FPU, but it does have a 128 bit vector unit with 8 16bit lanes which is pretty good at fixed point stuff. If you can vectorise your algorithm, it will be faster on the RSP.
It's hand written and should also work on microcontrollers like ESP32s or Pi Pico 2. Have you tried anything like that yet?
The Pico in particular has enough RAM and supports floating point math.
Sounds interesting, but there isn't any description or readme to go by.
The README is in the header file (picophysics.h)
why not in a readme
It's common enough to just copy single-file headers into a project. Now the docs come with it.
Yeah I didn’t think twice about clicking the header to read the docs. Standard practice.