2

The PlayStation 1 performed all calculations in fixed point. On the face of it, this is straightforward enough; it couldn't afford floating-point hardware, which was introduced only later, with the PS2, thereby allowing the PS2 to perform 3D calculations with better accuracy.

But there are a few reasons I'm not quite satisfied with this account.

For one thing, fixed point is not necessarily cheaper to calculate than floating point, e.g. 32-bit fixed-point multiply actually costs more than 32-bit floating point multiply: https://electronics.stackexchange.com/questions/368862/transistor-count-of-floating-point-multiplier

For another thing, it's also not necessarily inferior, e.g. a commenter on https://www.quora.com/Why-didnt-the-original-Playstation-support-floating-point

You don't really need floating-point numbers for most things. The only time you "need" them is for astronomical or molecular calculations where the values are so large and/or so small that precision is not important.

Fixed-point values a greater precision (using the same number of bits because there are no bits wasted on the exponent) and 32-bits offer enough dynamic range for any video-game simulation to appear fluid. It's actually more work to use floating-point numbers because they introduce more instabilities due to their quirky rounding behaviors and conversion between internal formats and IEEE-754 format and you have to ensure all the code is written taking this into account. (e.g. You can't just normalize 32-bit floating-point vectors once ... you have to normalize them twice for them to end up actually normal.)

Even today, if you want speed and stability you still use fixed-point values. Floating-point computations are toys for research to make it easier. When it's time to engineer a real product, fixed-point dominates.

Now, I'm not endorsing that view as the whole truth. For example, fixed point requires all code plus input data a given program to agree on the required dynamic range, so at the least, floating point would have become mandatory for games by the PS3 era when, as Sweeney observed, it became commonplace for a game to incorporate 10-20 middleware libraries. Still, it does indicate that the story is not as simple as it looked at first glance.

But one thing fixed point does give you is the opportunity to cheat, to take shortcuts, to use less than full 16.16 precision. Maybe that was the tradeoff made on the PS1.

What precision did PlayStation 1 games typically use for 3D calculations?

6
  • 3
    The Geometry Transformation Engine (a coprocessor) did most of the fixed point math – Brian Jan 11 at 21:12
  • 1
    The GTE uses different fixed point formats for different types of objects, all either 16 or 32 bit wide. For example, vectors are triples of signed 31 bit integers, while matrices have signed 15 bit coefficients of format 3.12. But various other fixed point precisions are used. But that’s just the GTE, no idea what tricks games actually used. – WimC Jan 12 at 12:01
  • 1
    For machines in the 1960s that lacked floating point operations, there was the so-called Minsky circle algorithm. Useful also for calculating sin and cos without a lot of arthmetic. forums.parallax.com/discussion/161967/… – Walter Mitty Jan 12 at 12:35
  • 3
    Having spent a career developing software for numerical algorithms, IMO the first and third sentences of paragraphs of your quote are ridiculous nonsense, and the second is somewhere between "very misleading" and "a rant about IEEE floating point." Lawrence Tech U had Steve Ballmer as a student (if only for one year) but it doesn't seem to have taught Shannon Barber very well. – alephzero Jan 12 at 13:07
  • 2
    You don't "need" floating point very often, but very often you need either linearly or logarithimically scaling precision and/or range (depending on whether your key ops are additive or multiplicative), and floats let a programmer in a hurry do both without even thinking about which they want (until they maybe shoot their own foot off with a numerically unstable algorithm because they really need both, but that's another story). – Dan Sheppard Jan 12 at 18:34
5

For one thing, fixed point is not necessarily cheaper to calculate than floating point, e.g. 32-bit fixed-point multiply actually costs more than 32-bit floating point multiply: https://electronics.stackexchange.com/questions/368862/transistor-count-of-floating-point-multiplier

The conclusion is only true when accepting a good amount of restrictions, wich make it a rather useless point most important as it ignores all additional measures to handle float - not at least normalizing. For all practical purpose a integer multiplication will needless hardware and thus be less expensive.

Here lies BTW the only real advantage of float: A 32 bit float multiplied by a 32 bit float will always return a 32 bit float , as the exponent covers more magnitudes than its precision is.

Fixed point is in next to all applications superior to float when it comes to calculations - float'sadvantage is in storage, as it contains a 'description' what is stored.

For another thing, it's [fixed point] also not necessarily inferior,

Of course not. An integer (fixpoint) can display all values within it's range, while float only covers 0%.

Now, I'm not endorsing that view as the whole truth. For example, fixed point requires all code plus input data a given program to agree on the required dynamic range,

Which would be very easy to do for a game, as it has to be done only within the game. Games do usually not care for interfaces and data transfer, or do they?

But more important here, intermediate values outside the precision used for display do simply not matter. In reality calculations will be already clipped, for performance, way before reaching these limits.

so at the least, floating point would have become mandatory for games by the PS3 era when, as Sweeney observed, it became commonplace for a game to incorporate 10-20 middleware libraries.

There is no principal issue to why these middle ware units (aka libraries) can't made using fixed point. In fact, there is only a single sub operation within a single operation were the structure of a fixed point number has to be known: picking the valid digits after a fixed point multiplication.

But one thing fixed point does give you is the opportunity to cheat, to take shortcuts, to use less than full 16.16 precision. Maybe that was the tradeoff made on the PS1.

Not really. For one the PS1 hardware did much of the nasty parts, but more important, there are not many shortcuts to be taken. 3D math is usually centered around a small set of operations, all based on addition, subtraction (each a simple machine instruction) and multiplication used direct or as combinations (dot-product, cross-product) on vectors. In addition some tigonometrics may be used to generate 3D data, but that's negotiable in realtion to the former. Off all of them, multiplication is the only complex one, and only here some optimization may pay off. The only one reliably reduceing is defining teh point at unit borders (e.g along word/byte lines), as it reduces the neccessary shift to a simple address operation.

So, why Float with the PS3?

The hardware or performance reason why float is used nowadays - the only one is convenience. During the 1990s FPUs became a common place, so using them, despite their disadvantage was simply the more convenient way. Why adding something custom (like the PS1 geometry engine) when a FPU can be bought off the shelf and offers sufficient performance?

11
  • 1
    @rwallace True, but we're talking game development environments, were delivery in source is common. But as mentioned, the position of the binary point is only relevant at a single sub operation to extract the result from a multiplication. This can easy be parameterised, or deffered to a rather small callback function. So for example when the library is in general written for a 32 bit fixed point, all operation except for multiplication can be done without hat knowledge, while multiplication will call a user function to return the result. Something like int32 extract(int64) ... – Raffzahn Jan 11 at 23:59
  • 1
    @rwallace The function itself simply selects the 32 bits according to were the binary point is. For example if the format is 20:12, then it'll select bits 2^33.downto.2^12. For most CPUs a rather simple shift. When delivered (full or partitial) as source this can be done by inlining. Even when external the overhead can be extreme small (like just CALL and RETURN), depending on calling convention. Or, since it's only a few constants/instructions, a binary patchtool could be delivered with the object code patching this single instance. It's software, be creative :)) – Raffzahn Jan 12 at 0:06
  • 2
    @rwallace And before you ask, details are present as I had to tackle this just today. My granddaughter is a CS freshman at TUM and they got an assignment over Christmas. It got returned with less than full grade, so we had a look into the code. It was about using x86-32 (80386) Assembler on 64 bit fixed integer (38:26). Task was to create exactly these mentioned basic functions. So yeah, kismet. – Raffzahn Jan 12 at 0:12
  • 1
    Abbreviations are good, but both Fixed Point and Floating Point has the same abbreviation... – UncleBod Jan 12 at 8:01
  • 2
    @another-dave / UncleBod well, AFAIR I only used FP for floating point, as that's the common abbreviation, while not shortening fixed point. But point taken. So let me point it out. – Raffzahn Jan 12 at 18:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.