POLY_FT4 - incorrect type for x0, y0?

[imeanreally]

Hi

https://github.com/Lameguy64/PSn00bSDK/blob/00abe5963fbead092f91935b90390aa5a9111c43/libpsn00b/include/psxgpu.h#L332C4-L332C4

x0 and y0 and the POLY_FT4 defn are unsigned ints, instead of signed. This doesn't seem to cause any issues when rendering these prim types, though. Is this just a typo or was there some intention behind it?

Thanks Appreciate all the work put into this SDK so far.

[EngineersBox]

Wanted to touch on two things, firstly, in the hardware docs it confirms that the vertices are indeed signed: https://psx-spx.consoledev.net/graphicsprocessingunitgpu/#gpu-render-polygon-commands

Vertex YYYYXXXX - required, two signed 16 bits values

And the second thing, assuming you are only using signed/unsigned numbers without any implicit casts generated by the compiler or explicit casts by the user, then it won't make any difference what the struct field is defined as as long as it occupies the same space and supports the same operations and type-specific behaviour.

So in this case, -12 and 65524 will be the exact same value in the field regardless of whether it is signed or not from the perspective of the hardware (and by extension emulators assuming correctness is preserved).

With regards to intention with implementation? Probably just an oversight as there are other polygon structs that have the same non-signed vertex fields.

I think the way to go here is make sure you are being very explicit about supplying a 16 bit value to the field explicitly, whether that be through a cast or by referencing a variable that is explicitly 16 bits when setting these values. If that is preserved then you should never encounter any issues. However, if you rely on the compiler to implicitly convert a different sized integer (or other type) into it, then it's possible you might seem some weird stuff depending on the expression complexity, number of intermediate casts, intermediate eliminations, etc