If you've been trying to write some games on a modern system (ie. your PC), you probably already know about using floats to implement momentum and jumping physics in a 2D platformer, or have something move towards a direction specified in degrees rather than X,Y velocity values to have said object move at an angle, like a ship in an Asteroids style game or a car in a top-down racer... On the PlayStation, these principles still apply. But there's a problem; the PlayStation does not have a hardware floating point unit.

Whilst you can still use floats on the PlayStation as the compiler will resort to software emulation to perform such operations, which you might be able to get away with, it's not exactly the most ideal method as software emulation of floats is quite slow, and will become an issue if used for collision detection or processing movement of a hundred projectile entities... The alternative that's better suited for a system without a floating point unit is to use a integer based fractional number system commonly known as fixed point math.

As the name suggests, fixed point math is a trick for storing fractional numbers with fixed points, in this case an integer scale of 4096 will have a range between zero to 4095 representing a fractional value, with 4096 representing a integer value of 1. Fixed point math is used heavily in games made for systems that lacked a floating point unit (5th generation and older consoles), or where integer math is considerably faster than floating point math and not all systems feature a floating point unit (ie. IBM compatible PCs).

This chapter covers the general idea and basics of performing fixed point integer arithmetic. This is a highly essential chapter when getting into PlayStation homebrew development, as learning it will increase the range of games you can write for the console immensely. If you've already learned some binary encoding of numeric values this chapter might be a bit easier to understand.

**Compatible with PSn00bSDK:** Yes

- Principle of Fixed Point Math
- Fixed Point Arithmetic Basics
- Implementing Tank Controls with Fixed Point
- Asteroids Style Physics with Fixed Point
- Bonus: Fixed Point Sprite Rotation
- Limitations of Fixed Point Math
- Conclusion and Further Reading

The basic principle of fixed point integer math is instead of representing
a real number of 1.25 as a floating point number, you instead represent
the number as an integer value from a scale value, in this case 4096 which is
defined as **ONE** in the GTE library headers. So a real value of 1.25
will look like 5120 when converted to fixed point math with a scale of 4096.
Converting a floating point number to a fixed point number is achieved by
simply multiplying the real number against the scale value and rounding off
the fractions, turning the result into a plain integer value. The following
table shows some sample floating point values represented in fixed point.

Floating point representation | Fixed point representation |
---|---|

1.25 | 5120 |

0.75 | 3072 |

0.2 | 819 |

21.284 | 87179 |

Using a scale value of 4096 is most ideal for PlayStation projects not only because it provides a good balance between precision and the maximum decimal value it can store, alongside allowing fixed point values to be rounded and divided quickly with simple bit shift operations and AND masks, but also because the Geometry Transformation Engine (GTE) also uses the same scale value for some of its registers. Any scale value can be used to gain more precision or to increase the decimal range limit. Generally a power of two scale value is recommended for performance reasons.

Bits |
31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

Description |
Sign | Decimal (19 bits) | Fractional (12 bits) |

The table above illustrates a fixed point value with a scale value of 4096 in a signed 32-bit integer. As there's only 19 bits available for the decimal portion the maximum range for the decimal value is -524288 to 524287.

Simple mathematical operations in fixed point such as addition and subtraction is not that much different to performing the same operations with integers, only values have to be based around the scale value.

fixed_value += 4096; // += 1.0 fixed_value -= 4096; // -= 1.0 fixed_value += 2048; // += 0.5 fixed_value -= 6144; // -= 1.5

For decimal multiplication and divide operations, the value for the dividend or multiplicand stays as-is.

fixed_value *= 5; // *= 5; fixed_value /= 10; // /= 10;

The equation for performing fractional multiplications is a little tricky, but still not too complicated.

multiplicand = 2048; // multiplicand = 0.5; fixed_value = (fixed_value*multiplicand)>>12; // fixed_value *= multiplicand; multiplicand = 6144; // multiplicand = 1.5; fixed_value = (fixed_value*multiplicand)>>12; // fixed_value *= multiplicand;

For fractional divisions, the value will need to be multiplied by the scale value and then divided by the dividend. Keep in mind that division by zero would still occur if the dividend is zero.

dividend = 2048; // dividend = 0.5; fixed_value = (fixed_value*4096)/dividend; // fixed_value /= dividend; dividend = 6144; // dividend = 1.5; fixed_value = (fixed_value*4096)/dividend; // fixed_value /= dividend;

As a little exercise, this part of the chapter will go through using fixed point math to implement tank controls. The basic jist of this is that instead of moving the player position directly by which direction of the D-pad is pressed, instead, left and right will adjust the angle the player is facing while up and down moves the player forward and backward perpendicular to where the player is facing. To do this requires using sine and cosine values and conveniently, the GTE libraries of both SDKs feature integer based sine and cosine functions which is exactly what's needed for this exercise.

In the official PsyQ or Programmer's Tool SDKs there are two integer based
sine and cosine functions which are **rsin()**/**rcos()** and
**csin()**/**ccos()**. The differences between the two is that
**rsin()**/**rcos()** takes up less code but is slower, whereas
**csin()**/**ccos()** takes up more code but is faster. PSn00bSDK on
the other hand only has one set of functions called **isin()/icos()**,
which are based on a Taylor series implementation which is both small and fast.
PSn00bSDK provides definitions for **rsin()**/**rcos()** and
**csin()**/**ccos()** that simply points to **isin()/icos()**
for compatibility with PsyQ / Programmer's Tool projects and sample code.

These functions also take degrees in a fixed point range of 0 to 4096 where 4096 equals to 360 degrees, so a value of 45 degrees will be specified as 512. The value returned is also in a fixed point notation with a scale of 4096, where 4096 equals to 1.0.

Working from code from the controllers chapter, rewrite the code that
defines the initial values of the player position to begin at the center
of the screen. Because the player coordinates will be in fixed point, the
screen center coordinate must be multiplied by **ONE**.

pos_x = ONE*(disp[0].disp.w>>1); pos_y = ONE*(disp[0].disp.h>>1);

Then, define a new variable for the player's angle and set the initial value to zero.

int angle; angle = 0;

The player will be represented as a rotating triangle in this chaper, so a simple array of vector coordinates will define the shape of the triangle. The triangle will be rotated with, you guessed it, fixed point math as well.

SVECTOR player_tri[] = { { 0, -20, 0 }, { 10, 20, 0 }, { -10, 20, 0 } };

Then ditch the code for sorting **TILE** and **SPRT** primitives
and replace it with the following routine that sorts a rotating triangle.

POLY_F3 *tri; ... // Rotate the triangle coordinates based on the player's angle // as well as apply the position for( i=0; i<3; i++ ) { v[i].vx = (((player_tri[i].vx*ccos( angle )) -(player_tri[i].vy*csin( angle )))>>12)+(pos_x>>12); v[i].vy = (((player_tri[i].vy*ccos( angle )) +(player_tri[i].vx*csin( angle )))>>12)+(pos_y>>12); } // Sort the player triangle tri = (POLY_F3*)nextpri; setPolyF3( tri ); setRGB0( tri, 255, 255, 0 ); setXY3( tri, v[0].vx, v[0].vy, v[1].vx, v[1].vy, v[2].vx, v[2].vy ); addPrim( ot[db], tri ); nextpri += sizeof(POLY_F3);

And then replace the input code with the following. If you've written something that played like Asteroids in the past, this may look pretty familiar.

if( !(pad->btn&PAD_UP) ) // test UP { pos_x += csin( angle ); pos_y -= ccos( angle ); } else if( !(pad->btn&PAD_DOWN) ) // test DOWN { pos_x -= csin( angle ); pos_y += ccos( angle ); } if( !(pad->btn&PAD_LEFT) ) // test LEFT { // Turns counter-clockwise angle -= 16; } else if( !(pad->btn&PAD_RIGHT) ) // test RIGHT { // Turns clockwise angle += 16; }

Next is to finally add some text drawing so the player coordinates can be
displayed on screen, so you can see how fixed point numbers work while
interacting with the sample program more easily. This can be done with the
debug font functions provided by

Start by loading the debug font texture to VRAM using **FntLoad()**,
then, initialize a font window using **FntOpen()**. Ideally, you should
put these calls inside the **init()** function.

// Load the font texture on the upper-right corner of the VRAM FntLoad( 960, 0 ); // Define a font window of 100 characters covering the whole screen FntOpen( 0, 8, 320, 224, 0, 100 );

Text can be printed using **FntPrint()** which works more or less like
**printf()**, only text output is directed to the specified font window.
The first argument specifies which font window the text should go to, the
value of which is obtained through the return value of **FntOpen()**.
Specifying -1 directs text to the last opened font window. The debug font
routines can only draw uppercase text, and text color and font cannot be
customized.

In PsyQ / Programmers tool the first argument can be omitted, but modern GNU GCC does not support this convention anymore.

// Print player coordinates FntPrint( -1, "POS_X=%d (%d.%d)\n", pos_x, (pos_x>>12), (pos_x&0xfff) ); FntPrint( -1, "POS_Y=%d (%d.%d)\n", pos_y, (pos_y>>12), (pos_y&0xfff) ); FntPrint( -1, "ANGLE=%d\n", angle );

Then to make the text actually appear, call **FntFlush()** to draw the
characters 'printed' by **FntPrint()** and flush the character buffer.
This should be called immediately before the **display()** call in the
sample code.

// Draw and flush the character buffer FntFlush( -1 );

The finished code should look like the following (the texture stuff remains for future samples):

#include <sys/types.h> // This provides typedefs needed by libgte.h and libgpu.h #include <stdio.h> // Not necessary but include it anyway #include <psxetc.h> // Includes some functions that controls the display #include <psxgte.h> // GTE header, not really used but libgpu.h depends on it #include <psxgpu.h> // GPU library header #include <psxapi.h> #define OTLEN 8 // Ordering table length (recommended to set as a define // so it can be changed easily) DISPENV disp[2]; // Display/drawing buffer parameters DRAWENV draw[2]; int db = 0; // PSn00bSDK requires having all u_long types replaced with // u_int, as u_long in modern GCC that PSn00bSDK uses defines it as a 64-bit integer. u_int ot[2][OTLEN]; // Ordering table length char pribuff[2][32768]; // Primitive buffer char *nextpri; // Next primitive pointer int tim_mode; // TIM image parameters RECT tim_prect,tim_crect; int tim_uoffs,tim_voffs; // Pad stuff #define PAD_SELECT 1 #define PAD_L3 2 #define PAD_R3 4 #define PAD_START 8 #define PAD_UP 16 #define PAD_RIGHT 32 #define PAD_DOWN 64 #define PAD_LEFT 128 #define PAD_L2 256 #define PAD_R2 512 #define PAD_L1 1024 #define PAD_R1 2048 #define PAD_TRIANGLE 4096 #define PAD_CIRCLE 8192 #define PAD_CROSS 16384 #define PAD_SQUARE 32768 typedef struct _PADTYPE { unsigned char stat; unsigned char len:4; unsigned char type:4; unsigned short btn; unsigned char rs_x,rs_y; unsigned char ls_x,ls_y; } PADTYPE; u_char padbuff[2][34]; // For the player triangle SVECTOR player_tri[] = { { 0, -20, 0 }, { 10, 20, 0 }, { -10, 20, 0 } }; void display() { DrawSync(0); // Wait for any graphics processing to finish VSync(0); // Wait for vertical retrace PutDispEnv(&disp[db]); // Apply the DISPENV/DRAWENVs PutDrawEnv(&draw[db]); SetDispMask(1); // Enable the display DrawOTag(ot[db]+OTLEN-1); // Draw the ordering table db = !db; // Swap buffers on every pass (alternates between 1 and 0) nextpri = pribuff[db]; // Reset next primitive pointer } // Texture upload function void LoadTexture(u_int *tim, TIM_IMAGE *tparam) { // Read TIM parameters (PsyQ) //OpenTIM(tim); //ReadTIM(tparam); // Read TIM parameters (PSn00bSDK) GetTimInfo(tim, tparam); // Upload pixel data to framebuffer LoadImage(tparam->prect, tparam->paddr); DrawSync(0); // Upload CLUT to framebuffer if present if( tparam->mode & 0x8 ) { LoadImage(tparam->crect, tparam->caddr); DrawSync(0); } } void loadstuff(void) { TIM_IMAGE my_image; // TIM image parameters extern u_int tim_my_image[]; // Load the texture LoadTexture(tim_my_image, &my_image); // Copy the TIM coordinates tim_prect = *my_image.prect; tim_crect = *my_image.crect; tim_mode = my_image.mode; // Calculate U,V offset for TIMs that are not page aligned tim_uoffs = (tim_prect.x%64)<<(2-(tim_mode&0x3)); tim_voffs = (tim_prect.y&0xff); } // To make main look tidy, init stuff has to be moved here void init(void) { // Reset graphics ResetGraph(0); // First buffer SetDefDispEnv(&disp[0], 0, 0, 320, 240); SetDefDrawEnv(&draw[0], 0, 240, 320, 240); // Second buffer SetDefDispEnv(&disp[1], 0, 240, 320, 240); SetDefDrawEnv(&draw[1], 0, 0, 320, 240); draw[0].isbg = 1; // Enable clear setRGB0(&draw[0], 63, 0, 127); // Set clear color (dark purple) draw[1].isbg = 1; setRGB0(&draw[1], 63, 0, 127); nextpri = pribuff[0]; // Set initial primitive pointer address // load textures and possibly other stuff loadstuff(); // set tpage of lone texture as initial tpage draw[0].tpage = getTPage( tim_mode&0x3, 0, tim_prect.x, tim_prect.y ); draw[1].tpage = getTPage( tim_mode&0x3, 0, tim_prect.x, tim_prect.y ); // apply initial drawing environment PutDrawEnv(&draw[!db]); // Initialize the pads InitPAD( padbuff[0], 34, padbuff[1], 34 ); // Begin polling StartPAD(); // To avoid VSync Timeout error, may not be defined in PsyQ ChangeClearPAD( 1 ); // Load the font texture on the upper-right corner of the VRAM FntLoad( 960, 0 ); // Define a font window of 100 characters covering the whole screen FntOpen( 0, 8, 320, 224, 0, 100 ); } int main() { int i; int pos_x,pos_y,angle; PADTYPE *pad; POLY_F3 *tri; SVECTOR v[3]; TILE *tile; // Pointer for TILE SPRT *sprt; // Pointer for SPRT // Init stuff init(); pos_x = ONE*(disp[0].disp.w>>1); pos_y = ONE*(disp[0].disp.h>>1); angle = 0; while(1) { // Parse controller input pad = (PADTYPE*)padbuff[0]; // Only parse inputs when a controller is connected if( pad->stat == 0 ) { // Only parse when a digital pad, // dual-analog and dual-shock is connected if( ( pad->type == 0x4 ) || ( pad->type == 0x5 ) || ( pad->type == 0x7 ) ) { if( !(pad->btn&PAD_UP) ) // test UP { pos_x += csin( angle ); pos_y -= ccos( angle ); } else if( !(pad->btn&PAD_DOWN) ) // test DOWN { pos_x -= csin( angle ); pos_y += ccos( angle ); } if( !(pad->btn&PAD_LEFT) ) // test LEFT { angle -= 16; } else if( !(pad->btn&PAD_RIGHT) ) // test RIGHT { angle += 16; } } } ClearOTagR(ot[db], OTLEN); // Clear ordering table // Rotate the triangle coordinates based on the player's angle // as well as apply the position for( i=0; i<3; i++ ) { v[i].vx = (((player_tri[i].vx*icos( angle )) -(player_tri[i].vy*csin( angle )))>>12)+(pos_x>>12); v[i].vy = (((player_tri[i].vy*icos( angle )) +(player_tri[i].vx*csin( angle )))>>12)+(pos_y>>12); } // Sort the player triangle tri = (POLY_F3*)nextpri; setPolyF3( tri ); setRGB0( tri, 255, 255, 0 ); setXY3( tri, v[0].vx, v[0].vy, v[1].vx, v[1].vy, v[2].vx, v[2].vy ); addPrim( ot[db], tri ); nextpri += sizeof(POLY_F3); // Print player coordinates FntPrint( -1, "POS_X=%d (%d.%d)\n", pos_x, (pos_x>>12), (pos_x&0xfff) ); FntPrint( -1, "POS_Y=%d (%d.%d)\n", pos_y, (pos_y>>12), (pos_y&0xfff) ); FntPrint( -1, "ANGLE=%d\n", angle ); // Draw and flush the character buffer FntFlush( -1 ); // Update the display display(); } return 0; }

Compile and execute the code and you should get a triangle that controls more or less like a tank. Press the left and right directional buttons to turn the triangle while pressing up and down moves the triangle forwards and backward perpendicular to where the triangle is pointing.

Now to make the tank controls sample a little more interesting by making it control like an Asteroids or Spacewar game. Basically, instead of accumulating the player coordinates directly with values based on the player's angle you accumulate them to a velocity vector, which in turn accumulates on the player's coordinates. This way, simple momentum based physics are archieved.

This can be done by implementing some changes to the last sample. Start
by adding variables in **main()** that'll be used to store the player's
velocity coordinates.

int vel_x,vel_y; ... // just to make sure they don't contain garbage vel_x = 0; vel_y = 0;

Next, modify some of the pad code to accumulate player movement towards the velocity variables instead of the player's coordinates. Put some bit shifts that divides the sin/cos values by 8 otherwise the 'ship' will accelerate too quickly.

if( !(pad->btn&PAD_UP) ) // test UP { vel_x += csin( angle )>>3; vel_y -= ccos( angle )>>3; } else if( !(pad->btn&PAD_DOWN) ) // test DOWN { vel_x -= csin( angle )>>3; vel_y += ccos( angle )>>3; }

Immediately after the pad code add a few lines that accumulates the velocity coordinates to the player's coordinates.

// accumulate player coordinates by its velocity pos_x += vel_x; pos_y += vel_y;

And to keep the player from going off-screen, place the following lines immediately after the above code to wrap the player's coordinates when they go off-screen.

// wrap player coordinates from going off-screen if( (pos_x>>12) < 0 ) { pos_x += (320<<12); } if( (pos_x>>12) > 320 ) { pos_x -= (320<<12); } if( (pos_y>>12) < 0 ) { pos_y += (240<<12); } if( (pos_y>>12) > 240 ) { pos_y -= (240<<12); }

Then place some additional **FntPrint()** calls that displays the
values from the velocity variables. You'll also need to increase the
character buffer size of the **FntOpen()** call (the last argument)
from 100 to 150.

FntPrint( -1, "VEL_X=%d (%d.%d)\n", vel_x, (vel_x>>12), (vel_x&0xfff) ); FntPrint( -1, "VEL_Y=%d (%d.%d)\n", vel_y, (vel_y>>12), (vel_y&0xfff) );

Compile the sample demo and the triangle should behave a lot like an Asteroids ship.

If you want velocity to slowly diminish overtime, add the following lines just before the velocity vectors are accumulated to the player coordinates. It also acts as a velocity constraint as well.

// equivalent to multiplying each axis by 0.9765625 vel_x = (vel_x*4000)>>12; vel_y = (vel_y*4000)>>12;

Since it is something new programmers would find incredibly handy and to show off some of what the 32-bit console can do, especially for PSn00bSDK folk as it does not have an equivalent to libgs, here's a fixed point based sprite rotation and scaling routine that draws a rotated and scaled sprite with a single quad. The math for rotation is more or less the same as how the player triangle is rotated.

void sortRotSprite( int x, int y, int pw, int ph, int angle, int scale ) { POLY_FT4 *quad; SVECTOR s[4]; SVECTOR v[4]; int i,cx,cy; // calculate the pivot point (center) of the sprite cx = pw>>1; cy = ph>>1; // increment by 0.5 on the bottom and right coords so scaling // would increment a bit smoother s[0].vx = -(((pw*scale)>>12)-cx); s[0].vy = -(((ph*scale)>>12)-cy); s[1].vx = (((pw*scale)+2048)>>12)-cx; s[1].vy = s[0].vy; s[2].vx = -(((pw*scale)>>12)-cx); s[2].vy = (((ph*scale)+2048)>>12)-cy; s[3].vx = (((pw*scale)+2048)>>12)-cx; s[3].vy = s[2].vy; // a simple but pretty effective optimization trick cx = ccos( angle ); cy = csin( angle ); // calculate rotated sprite coordinates for( i=0; i<4; i++ ) { v[i].vx = (((s[i].vx*cx) -(s[i].vy*cy))>>12)+x; v[i].vy = (((s[i].vy*cx) +(s[i].vx*cy))>>12)+y; } // initialize the quad primitive for the sprite quad = (POLY_FT4*)nextpri; setPolyFT4( quad ); // set CLUT and tpage to the primitive setTPage( quad, tim_mode&0x3, 0, tim_prect.x, tim_prect.y ); setClut( quad, tim_crect.x, tim_crect.y ); // set color, screen coordinates and texture coordinates of primitive setRGB0( quad, 128, 128, 128 ); setXY4( quad, v[0].vx, v[0].vy, v[1].vx, v[1].vy, v[2].vx, v[2].vy, v[3].vx, v[3].vy ); setUVWH( quad, tim_uoffs, tim_voffs, pw, ph ); // add it to the ordering table addPrim( ot[db], quad ); nextpri += sizeof(POLY_FT4); }

By this point, it should be easy to figure out how to use this function
in the sample above. The *angle* and *scale* arguments are of a
fixed point notation, where 4096 is 360 degrees on the former and 4096 is
1.0 on the latter.

One limitation that becomes apparent when performing 32-bit fixed point math arithmetic is when performing fractional multiplication operations with large fixed point values due to the C compiler usually always performing multiplication and bit shifting operations with 32-bit registers, as multiplying a large fixed point value by a large fixed point multiplicand will likely exceed the capacity of a 32-bit word, yielding a faulty result.

The MIPS R3000 CPU of the PlayStation can actually return a 64-bit multiplication result, but the C compiler doesn't really make use of this trait when performing multiplication operations with 32-bit integers. So the only way to effectively take advantage of this is to use some in-line assembly code. Should be pretty self explanatory on how and where it should be used.

/* in-line assembly macro for performing multiplication */ /* operations with 12-bit fractions. Uses what is effectively */ /* 64-bit maths with both hi and lo result registers to avoid */ /* overflow bugs when using 32-bit maths. */ /* */ /* Performs r2 = ( r0 * r1 )>>12 with 64-bit arithmetic */ /* */ #define mult12( r0, r1, r2 ) __asm__ volatile ( \ "mult %1, %0;" /* multiply values (small * large is faster) */\ "mflo $t0;" /* retrieve the 64-bit result in two regs */\ "mfhi $t1;" \ "srl $t0, 12;" /* equivalent to dividing LO by 4096 */\ "and $t1, 0x0fff;" /* mask HI result to fit in upper 12 bits of */\ "sll $t1, 20;" /* LO result, then shift bits to position */\ "or $t0, $t1;" /* combine the bits */\ "sw $t0, ( %2 );" /* store the result to r2 */\ : \ : "r"( r0 ), "r"( r1 ), "r"( r2 ) \ : "lo", "hi", "t0", "t1", "memory" )

Though naturally, fixed point math can't really be as precise as floating point math in certain operations. You can try increasing precision by increasing the base value, alloting more bits for the fractional part of a fixed point value, but there will still be something rough about it.

This chapter only really covers some pretty basic but highly essential math operations with fixed point math, but it should be enough to get you started in learning the practice. Interestingly fixed point math is still somewhat talked about around the modern Internet, so you may want to look around for those for further reading if need-be.

Previous | Back to Index | Next |