4 ms·

As someone who has started out making games on Playstation 1 that didn't have floating point hardware, I can with authority say that developing games with only

As someone who has started out making games on Playstation 1 that didn't have floating point hardware, I can with authority say that developing games with only integers suck. Floating point number are far easier and robust to use.

pfraze 6y ago
Only integers? Wow. Were int pairs used to represent numbers with decimals or what?
- timerol 6y ago
  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.
- salicideblock 6y ago
  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.
  - okl 6y ago
    The Wikipedia page explains the operations: https://en.wikipedia.org/wiki/Q_(number_format) https://en.wikipedia.org/wiki/Q_(number_format)
- linkdd 6y ago
  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)
- coopierez 6y ago
  The GPU made use of fixed point numbers. So you have a set number of decimal places for a number.
scrooched_moose 6y ago
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 https://www.youtube.com/watch?v=VLTqIXZ1jQQ#t=15m00s I never had a PS1 but it always bugged me when playing on someone elses.
- codetrotter 6y ago
  > 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 https://github.com/dsoft20/psx_retroshader
- coopierez 6y ago
  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).
- quelsolaar 6y ago
  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.
- edflsafoiewq 6y ago
  No. The DS uses only fixed point numbers and does not wobble.
ajuc 6y ago
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.

pfraze 6y ago

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

timerol 6y ago
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.
salicideblock 6y ago
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.
- okl 6y ago
  The Wikipedia page explains the operations: https://en.wikipedia.org/wiki/Q_(number_format) https://en.wikipedia.org/wiki/Q_(number_format)
linkdd 6y ago
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)
coopierez 6y ago
The GPU made use of fixed point numbers. So you have a set number of decimal places for a number.

scrooched_moose 6y ago

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 https://www.youtube.com/watch?v=VLTqIXZ1jQQ#t=15m00s I never had a PS1 but it always bugged me when playing on someone elses.

codetrotter 6y ago
> 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 https://github.com/dsoft20/psx_retroshader
coopierez 6y ago
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).
quelsolaar 6y ago
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.
edflsafoiewq 6y ago
No. The DS uses only fixed point numbers and does not wobble.

ajuc 6y ago

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.