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.
wren6991 9 hours ago [-]
> Everything being static inline makes it hostile to these older systems which have limited RAM
If you don't define `PICOPHYSICS_IMPLEMENTATION` then you just get prototypes and a few struct definitions. From what I could tell the static inline functions are just used as helpers by the non-static functions defined in the implementation TU. It's similar to the stb[1] implementation pattern.
Also, inlining improves code size more often than you might think. There is a lot of ceremony in a function call, and the compiler has to make pessimistic assumptions about what is trashed by the call, causing unnecessary spills and fills. Things like the simple vec3 operations here should pretty much always be made available for inlining; whether the compiler actually decides to inline them is a different story.
> Use of float makes it unlikely that you’d run it on the PlayStation, which has no FPU.
I think this sentence just made me realize what made the PSX graphics look so "PSX", I'm guessing all the positions/translations and similar stuff were actually not floating point which they typically are (today at least), hence the classic look of triangles/meshes kind of "jumping"? Huh...
ndepoel 9 hours ago [-]
The jumpy polygons are because the PSX's GPU only accepts vertex positions in screen coordinates, meaning that vertices always snap to hard integer values. There is no sub-pixel accuracy. That's not a limitation caused by the PSX's lack of an FPU though. A large part of the render pipeline and standard libraries are built around the use of fixed point math, i.e. using integers to simulate decimal values. The GTE co-processor which handles 3D math makes use of standardized fixed-point types. So the PSX would have been capable of calculating sub-pixel coordinate values, it's just that the communication between CPU and GPU was designed to use only integer screen coordinate values.
spicyjpeg 8 hours ago [-]
It's slightly more complicated than that. The PlayStation's geometry pipeline uses fixed-point coordinates with a decent amount of fractional precision (12 bits), however the GPU lacks support for subpixel rendering and operates entirely in screen space using integer X/Y pixel coordinates; all transformed vertices thus have to be rounded CPU-side before they reach the GPU. The GPU is also a 2D rasterizer only, with no perspective correction nor depth buffering, so transformed Z values are used on the CPU to sort polygons back to front (typically using hardware-assisted linked list bucket sorting) and dropped afterwards [1].
The reason is that the PlayStation doesn't have perspective-correct texcoord interpolation.
unleaded 7 hours ago [-]
That's a separate issue from the wobbling.
anthk 9 hours ago [-]
Integers. You could almost emulate a PSX in a potato (Pentium MMX) with -ffast-math -O3 except for Alpha channel (transparencies) in textures.
gsliepen 10 hours ago [-]
> 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.
yellowapple 12 hours ago [-]
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?
ColdStream 14 hours ago [-]
I was going to say, even the readme file only mentions N64 and DC.
aaaronic 16 hours ago [-]
Most of the older consoles don't have an FPU. Fixed point is king on those older systems.
klodolph 15 hours ago [-]
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.
phire 11 hours ago [-]
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.
inigyou 7 hours ago [-]
According to Kaze Emanuar, the N64 is actually memory bandwidth bound in almost everything it does.
Attummm 18 hours ago [-]
Sounds interesting, but there isn't any description or readme to go by.
bouchard 17 hours ago [-]
The README is in the header file (picophysics.h)
monkpit 17 hours ago [-]
why not in a readme
Retr0id 16 hours ago [-]
It's common enough to just copy single-file headers into a project. Now the docs come with it.
abnercoimbre 14 hours ago [-]
Yeah I didn’t think twice about clicking the header to read the docs. Standard practice.
iamcoder18 18 hours ago [-]
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.
chrisjj 10 hours ago [-]
Perhaps add README.md?
songhonglei1985 12 hours ago [-]
single-file physics for old consoles is such a neat constraint to build under. reminds me of the n64 homebrew stuff i was looking at - wonder if this actually runs on real hardware or just emulators, the psx/n64 have such tight memory limits. anyone benchmarked it on a real dev kit?
Rendered at 18:43:20 GMT+0000 (UTC) with Wasmer Edge.
If you don't define `PICOPHYSICS_IMPLEMENTATION` then you just get prototypes and a few struct definitions. From what I could tell the static inline functions are just used as helpers by the non-static functions defined in the implementation TU. It's similar to the stb[1] implementation pattern.
Also, inlining improves code size more often than you might think. There is a lot of ceremony in a function call, and the compiler has to make pessimistic assumptions about what is trashed by the call, causing unnecessary spills and fills. Things like the simple vec3 operations here should pretty much always be made available for inlining; whether the compiler actually decides to inline them is a different story.
[1]: https://github.com/nothings/stb
I think this sentence just made me realize what made the PSX graphics look so "PSX", I'm guessing all the positions/translations and similar stuff were actually not floating point which they typically are (today at least), hence the classic look of triangles/meshes kind of "jumping"? Huh...
[1] https://github.com/spicyjpeg/ps1-bare-metal/blob/main/src/08...
The reason is that the PlayStation doesn't have perspective-correct texcoord interpolation.
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.
Re: floats, I wonder how well it'd perform if compiled with soft-float support?
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.
The Pico in particular has enough RAM and supports floating point math.