Maybe floating point isn't that bad of an idea.
Moderator: Moderators
Forum rules
 For making cartridges of your Super NES games, see Reproduction.

 Posts: 2949
 Joined: Wed May 19, 2010 6:12 pm
Maybe floating point isn't that bad of an idea.
Let's say you have an 8bit mantissa, and a 5bit exponent and a sign bit like this:
00seeeee mmmmmmmm
Lets say an exponent of "16" is a whole number. In order to multiply a number you could add the exponent bytes together, then subtract 16. Then multiply the 8bit mantissas together, and then shift the 16bit product right until it's less than 256, while incrementing the exponent byte.
For the signed bit, just as long as the 5bit exponent doesn't overflow, the sign bits should automatically EOR eachother when adding, followed by AND #$3F to clear out the top 2 bits.
Now with converting it back into fixed point, there's several ways:
1) Use an extremely long LUT
2) Split up the exponent byte between the low 3 bits and the high 2 bits. Use the low 3 bits to count how many times you shift the accumulator left, and use the top two bits as an index.
3) Do the same except use a LUT for accumulator shifts instead.
00seeeee mmmmmmmm
Lets say an exponent of "16" is a whole number. In order to multiply a number you could add the exponent bytes together, then subtract 16. Then multiply the 8bit mantissas together, and then shift the 16bit product right until it's less than 256, while incrementing the exponent byte.
For the signed bit, just as long as the 5bit exponent doesn't overflow, the sign bits should automatically EOR eachother when adding, followed by AND #$3F to clear out the top 2 bits.
Now with converting it back into fixed point, there's several ways:
1) Use an extremely long LUT
2) Split up the exponent byte between the low 3 bits and the high 2 bits. Use the low 3 bits to count how many times you shift the accumulator left, and use the top two bits as an index.
3) Do the same except use a LUT for accumulator shifts instead.
 Señor Ventura
 Posts: 138
 Joined: Sat Aug 20, 2016 3:58 am
Re: Maybe floating point isn't that bad of an idea.
I'm lost, What is it for?.
Re: Maybe floating point isn't that bad of an idea.
When writing code in a highlevel language, floatingpoint avoids the need to keep track of many differing types with different levels of range and precision. It also makes it practical to have libraries that can be used for many different purposes that would involve numbers with different ranges. From a computational efficiency standpoint, almost anything that can be done with floatingpoint could be done more efficiently with suitablychosen fixedpoint formats if one evaluated the required size and range of each object before writing the code.psycopathicteen wrote:Then multiply the 8bit mantissas together, and then shift the 16bit product right until it's less than 256, while incrementing the exponent byte.
The amount of absolute precision that a particular object needs generally won't diminish with the scale of the value that happens to be within it. If one has a game with acceleration, velocity values may need more precision than absoluteposition values, and a single floatingpoint type may handle that job better than would a single fixedpoint type, but using separate fixedpoint position, velocity, and acceleration types would be better yet.
Re: Maybe floating point isn't that bad of an idea.
There are a few other complications involved.
Addition is nowhere near as simple, as you need to align the exponents first. The barrel shifting for that will not be quick in '816.
Catching and handling exponent overflow and underflow do need to be done.
Usually you want to have zero be special cased, with an exponent of 0, which mostly lets the usual comparisons work (aside from catching/eliminating 0)
For the proposed format, s00eeeee mmmmmmmm would probably be a bit better, as then you can check the sign as if it were a normal 16 bit integer.
On the upside, treating them as 16 bit signed integers for comparison generally Just Works.
Addition is nowhere near as simple, as you need to align the exponents first. The barrel shifting for that will not be quick in '816.
Catching and handling exponent overflow and underflow do need to be done.
Usually you want to have zero be special cased, with an exponent of 0, which mostly lets the usual comparisons work (aside from catching/eliminating 0)
For the proposed format, s00eeeee mmmmmmmm would probably be a bit better, as then you can check the sign as if it were a normal 16 bit integer.
On the upside, treating them as 16 bit signed integers for comparison generally Just Works.

 Posts: 2949
 Joined: Wed May 19, 2010 6:12 pm
Re: Maybe floating point isn't that bad of an idea.
I'm trying to make a 3D spinning ring of ball sprites and it's taking a lot of CPU power to do the math on 16 balls, because it's taking 8 multiplications and 2 divisions per sprite. I'm trying not to use the mode7 multiplication registers because I might want to later do this effect during a mode7 level, but I'll do it as a last resort. Floating point looks like a good idea, because I only need to do one 8x8 multiplication. The downside is the need to convert back into fixed point, so I would have to count cycles, before making the decision to use it or not.Señor Ventura wrote:I'm lost, What is it for?.
Re: Maybe floating point isn't that bad of an idea.
No need for a floating number then, made in fixedpoint numbers.
You know that the PS1 had no floating numbers?
All the 3D calculations was 16 bits
(It seems to me that the Sega Saturn too)
The PS2 also has a 16bit fixedpoint (for vertices / textures), but you perform floatingpoint calculations (with FTOI and ITOF instructions for conversions). Sony has kept 16bits fixedpoint to speed up transfers between RAM and memory VU.
And the GPU also takes only 16bit fixedpoint ah ah so forced to do a lot of conversion (but the instruction is fast you can run 2 instructions / cycles if you pay attention to the pipeline).
Dreamcast allowed 16bit floating numbers for texture coordinates (to reduce transfers)
You know that the PS1 had no floating numbers?
All the 3D calculations was 16 bits
(It seems to me that the Sega Saturn too)
The PS2 also has a 16bit fixedpoint (for vertices / textures), but you perform floatingpoint calculations (with FTOI and ITOF instructions for conversions). Sony has kept 16bits fixedpoint to speed up transfers between RAM and memory VU.
And the GPU also takes only 16bit fixedpoint ah ah so forced to do a lot of conversion (but the instruction is fast you can run 2 instructions / cycles if you pay attention to the pipeline).
Dreamcast allowed 16bit floating numbers for texture coordinates (to reduce transfers)
Last edited by Kannagi on Fri Jun 14, 2019 2:22 pm, edited 1 time in total.
 rainwarrior
 Posts: 7841
 Joined: Sun Jan 22, 2012 12:03 pm
 Location: Canada
 Contact:
Re: Maybe floating point isn't that bad of an idea.
What doesn't the exponent fill the whole byte? What are those two 0 bits for? I do second the notion that the sign bit should be in the high bit at least, but why not make that whole byte a signed 8bit number and keep it simpler that way?
FWIW I think software floating points can be very useful for some specific purposes, though I must admit those purposes have never come up in my retro game platform endeavours.
FWIW I think software floating points can be very useful for some specific purposes, though I must admit those purposes have never come up in my retro game platform endeavours.
 Señor Ventura
 Posts: 138
 Joined: Sat Aug 20, 2016 3:58 am
Re: Maybe floating point isn't that bad of an idea.
That is interesting, How much processing, more or less, can you gain with the multipliers of the PPU1?.psycopathicteen wrote:I'm trying to make a 3D spinning ring of ball sprites and it's taking a lot of CPU power to do the math on 16 balls, because it's taking 8 multiplications and 2 divisions per sprite. I'm trying not to use the mode7 multiplication registers because I might want to later do this effect during a mode7 level, but I'll do it as a last resort. Floating point looks like a good idea, because I only need to do one 8x8 multiplication. The downside is the need to convert back into fixed point, so I would have to count cycles, before making the decision to use it or not.Señor Ventura wrote:I'm lost, What is it for?.

 Posts: 2949
 Joined: Wed May 19, 2010 6:12 pm
Re: Maybe floating point isn't that bad of an idea.
I was thinking of a way to avoid making the LUT too big, but I realize that I can get around that by checking if floating point value is in range and using the LUT if in the range, and loading a #0 if not it range. It should take about 12kB.rainwarrior wrote:What doesn't the exponent fill the whole byte? What are those two 0 bits for? I do second the notion that the sign bit should be in the high bit at least, but why not make that whole byte a signed 8bit number and keep it simpler that way?
 Señor Ventura
 Posts: 138
 Joined: Sat Aug 20, 2016 3:58 am
Re: Maybe floating point isn't that bad of an idea.
By the way, Do you mean using multiplications out of the mode 7?.

 Posts: 2949
 Joined: Wed May 19, 2010 6:12 pm
Re: Maybe floating point isn't that bad of an idea.
Something that just occurred to me, is I could reduce the number of multiplications from 8 per sprite to 6 per sprite by calculating a 2x3 rotational matrix first, and then do matrix multiplication on every sprite in the 3d ring.
I'm talking about $211b and $211c.Señor Ventura wrote:By the way, Do you mean using multiplications out of the mode 7?.

 Posts: 914
 Joined: Tue Feb 07, 2017 2:03 am
Re: Maybe floating point isn't that bad of an idea.
Something like this you probably need to "fake it".
you can make a parabola with fixed maths addition right, and a circle can be made with 2 of them. So basically you fake it. Or add the C4 chip, or SuperFX.
you can make a parabola with fixed maths addition right, and a circle can be made with 2 of them. So basically you fake it. Or add the C4 chip, or SuperFX.
 Señor Ventura
 Posts: 138
 Joined: Sat Aug 20, 2016 3:58 am
Re: Maybe floating point isn't that bad of an idea.
I have here noted that the registers for the PPU are $4202 and $4203, and the registers of the mode 7 are $211b, $211c, $211d, and $211epsycopathicteen wrote:I'm talking about $211b and $211c.
So, Do i must understand that you are in mode 7, but you can use that multipliers for sprites?

 Posts: 2949
 Joined: Wed May 19, 2010 6:12 pm
Re: Maybe floating point isn't that bad of an idea.
There are two sets of multiplication registers:Señor Ventura wrote:I have here noted that the registers for the PPU are $4202 and $4203, and the registers of the mode 7 are $211b, $211c, $211d, and $211epsycopathicteen wrote:I'm talking about $211b and $211c.
So, Do i must understand that you are in mode 7, but you can use that multipliers for sprites?
$211b/$211c/$2134 for signed 8x16 multiplication
$4202/$4203/$4216 for unsigned 8x8 multiplication
However the first set of registers also control the Mode7 layer, so if you're using mode7 using the signed 8x16 multiplication will screw up the mode7 layer.

 Posts: 257
 Joined: Mon Jan 23, 2006 7:47 am
 Location: Germany
 Contact:
Re: Maybe floating point isn't that bad of an idea.
PPU = $2100..$2183Señor Ventura wrote:I have here noted that the registers for the PPU are $4202 and $4203
5A22 = $4016..$4017 and $4200..$437F
My current setup:
Super Famicom ("2/1/3" SNSCPUGPM02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNSCPUGPM02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10