Isn't that what caused the PS1 graphics "wobble"? I remember you could just stare at a wall, rotate the camera, and the textures would slightly jitter and move. It's really obvious in some the Metal Gear cutscenes, especially this conversation with Donald Anderson where the camera pans up from the floor (at 15m) or the sweep(15m31s):

https://www.youtube.com/watch?v=VLTqIXZ1jQQ#t=15m00s

I never had a PS1 but it always bugged me when playing on someone elses.

This is because of two things: the affine texture mapping was incorrect, and there was no sub-pixel precision. The sub-pixel part is kinda float-related (though you could make use of fixed point too).

> I never had a PS1 but it always bugged me when playing on someone elses.

Conversely I like the fact a lot that it does. And some others that probably have fond memories of PS1 too recreated this on modern computers using shaders.

https://github.com/dsoft20/psx_retroshader

yes, and the PS1 had a vector unit built in to the CPU that was used for world transform and it was only 24 bits.

Early PS1 games fit the entire world in to a 24 bit space, and you can tell that there is steping if you drive very slow in a game like Ridge Racer. Later games moved the world around in the coordinate system to manage precision.

Another reason why the graphics looks extra "popy" on PS1 (And early DirectX games) is that vertices where computed at a pixel accuracy. OpenGL, Doom, Quake and more modern hardware have sub pixel accuracy.

No. The DS uses only fixed point numbers and does not wobble.

Did you use macros/operator overloading for all that bit shifting or just hardcoded it everywhere?

We made a simple 3d demo for uni using fixed math (and we were clueless then and weren't using macros because sometimes you could refactor some operations out that way and we wanted all the speed). There were lots of bugs caused by this.

Can't imagine how painful writing a whole game this way would be.

Only integers? Wow. Were int pairs used to represent numbers with decimals or what?

In signal processing on constrained domains (constrained including the lack of an FPU), the usual alternative to floating point is "fixed point" arithmethic.

Basically you use the platform's native types (e.g. uint32) and decide which of the bits are for the integer part and which are for the fractional. uint32 can be interpreted as 20/12 for example. Your register went from representing "units" to representing "2^-12 increments of an unit". The ALU can do sum/comparison/subtractions transparently, but multiplications and (god forbid) divisions require shifting to return to the original representation.

The choice of how to split the bits is a tradeoff between range and precision. It can vary from one routine to another. It's a pain to compose code with it.

Short story: native float types are a blessing for programmer productivity and library interoperability.

The Wikipedia page explains the operations: https://en.wikipedia.org/wiki/Q_(number_format)

To use only integers, you generally try to express all numbers in units of the smallest quantity. So any money is in integer cents, any distance is in integer (spatial resolution size). It gets annoying with derived units: Time can be stored in integer frames, but then you'll need a rational type of some kind to properly handle velocity. Or you just round to the nearest (spatial resolution) per frame and hope the errors don't look too weird on the other side.

Let's say you have two 4 bits integer to form an 8 bit decimal number:

1111.1111 is (1 + 2 + 4 + 8) + (1/2 + 1/4 + 1/8 + 1/16)

The GPU made use of fixed point numbers. So you have a set number of decimal places for a number.