Home    LittleBigPlanet 2 - 3 - Vita - Karting    LittleBigPlanet 2    [LBP2] Tutorials
#1

Guide to Speed, Rotation and length units in LBP2 [UPDATED+SOME NEW INFO]

Archive: 40 posts

I made a quick experiment on speeds to find out what the units used in movers/rotators actually mean.

So, first of all, the grid:
each small grid square width equals ~0.38 meters (measured using gravity)
which means 1m = 2.63 small grid squares.

For speed measurements i used a mover operating on a cardboard box the size of a big grid square.
All results were taken after the mover reached it's maximum speed.
One speed unit will make the object move at about 3.9 small grid units per second, or 1.48 meters per second.

Some more conversions for convenience:

Speed Units
(movers, pistons, winches etc.)
1 km/h = 1.874 speed units
1 m/s = 1.482 speed units
1 km = 2630 small grid squares = 1315 medium grid squares = 657.5 big grid squares
1 m = 2.63 small grid squares = 1.315 medium grid squares = 0.6575 big grid squares
1 small grid square = 0.38m
1 med grid square = 0.76m
1 big grid square = 1.52m
1 speed unit = 1 big grid per second

Rotation Units
(Rotators, Bolts)
1 rotation unit = 0.00278 rotations per sec = 1 degree per sec
1 rotation per sec = 360 rotation units
1500 rotation units (max)= 4.167 rotations per sec = 250 rpm

Length Units
(pistons, sensors, connectors)
1 small grid square = 2.5 length units
1 med grid square = 5 length units
1 big grid square = 10 length units
1 length unit = 1.052m
1 length unit = 0.4 small grid squares = 0.2 med grid squares = 0.1 big grid squares

Some Useful Units
sackboy maximum running speed = 5 speed units
sackboy jump speed = about 1.5 speed units
sackboy height = 1 big grid square


NOTICE
Some information was updated thanks to comments,
Please take note that real life unit conversions are approximate and should be used as reference.

I hope you find these helpful!
Comments welcome!		2011-02-05 23:53:00

Author:
saarraz1
Posts: 86

Heh. IIRC Mm said somehwere Sackboy's about 8 cms high, which makes a small grid unit 0.8 cm. So, I guess you discovered gravity is different from reality. 2011-02-06 11:52:00

Author:
Rogar
Posts: 2284

@Rogar: wouldn't that make a small grid unit 0.04cm for a small grid unit, 0.8 for a medium grid unit?

You can't actually measure gravity in LBP, because any tests you do will be biassed by resistive forces - different objects fall at different speeds, so finding the gravitational constant is pretty difficult. Also, using SI units in this way gives no real benefit - it just leads to unwieldy values. Especially when the Americans get here and get confused by kilometers and such

I'm pretty sure the rotation is slightly off, too - I don't believe for one second that "1 rotation per sec = 361.45 rotation units" is accurate, not when that's ever so slightly off from the far more obvious value of 360. Pretty sure more accurate values were discovered when investigating Tamland's incremental bolts, can't be bothered to look it up right now 		2011-02-06 12:46:00

Author:
rtm223
Posts: 6497

This is really interesting saarraz, especially the rotation units calculations. I have been working on a rotating path switch that will rotate 90 degrees in each movement. I had assumed that each speed unit of the motor bolt would be equal to 1, and based on this theory, I connected the bolt to a timer switch. The motor bolt is set to a speed of 30 and (well I'm just renting the game right now and had to return it last night and cannot remember the timer setting but am sure that it is) a timer set to 3 seconds.

The rotating pieces appears to rotate 90 degrees, but upon further inspection, the rotating piece ends up about 5 degrees off after a two moves. This has been driving me crazy and I spent a lot of time trying to figure this out. Would have been great to have had your knowledge many sleepless nights ago

Luckily I live in the Pacific Northwest of the US, so I'm a little more comfortable with the metric system... : P

Thanks again!		2011-02-06 18:47:00

Author:
Unknown User

Having played with the rotating more, it seems there is a bug when controlling them from timers.

Basically, the rotation speed is degrees / second, but, the timers seem to activate the device for one clock tick less than the actual time on the timer. Which is strange as the correct number of clock ticks of activation are output when from the timer (which can be verified using a number of other devices).

This missing clock tick can be inferred from the following:

Pulsing single clock frames of activation into the motor bolt - 30 such pulses (i.e. a second of actual activation) will give the correct response.
triggering using a timer with 1s and 4s into a speed 360 bolt will end up offset by the same amount. This indicates that the error is absolute, not proportional to the speed of the bolt - as would be expected if the 361.45 rotation units in the OP was correct
If you add an extra frame of activation signal at the end of the timer then you will see correct behaviour, regardless of the time on the timer.		2011-02-06 19:03:00

Author:
rtm223
Posts: 6497

It will be a couple of days before I have an opportunity to buy the game and experiment again, but after reading your post rtm, I've come up with an idea.

What if the timer was used to interrupt a signal instead of directly powering the motor bolt? I'm thinking about an XOR (maybe AND) switch wired between a battery and the motor bolt. Then set the timer for reverse polarity so when active its out put is switched off.

Would this take the timer's issue out of the equation, or would the timer still affect the motor bolt the same way?

I have no electrical educational back-ground, so I hope I am at least making sense. I just know enough to be dangerous.

Also, what do you mean by adding one extra pulse?		2011-02-06 19:34:00

Author:
Unknown User

...the timers seem to activate the device for one clock tick less than the actual time on the timer.

...unless the timer is set to less than 0.5s, in which case it works correctly - go figure.

How exactly did you verify the timer is active for the correct number of ticks?		2011-02-07 20:37:00

Author:
Aya042
Posts: 2870

How exactly did you verify the timer is active for the correct number of ticks?

I'm guessing he used a counter, set to reset itself, as a way to generate a pulse as well as "run" the wheel. Stabbing at air, though.		2011-02-07 20:48:00

Author:
comphermc
Posts: 5338

@Rogar: wouldn't that make a small grid unit 0.04cm for a small grid unit, 0.8 for a medium grid unit?

No, 1 sackboy's height = 1 big grid = 8cm, so a medium grid is 4cm and a small grid is 2cm. What I meant to say earlier was, a length unit as used in tweaks (for example a piston's minimum and maximum length) is a 10th of a big grid, which is 0.8cm.		2011-02-07 21:21:00

Author:
Rogar
Posts: 2284

...unless the timer is set to less than 0.5s, in which case it works correctly - go figure.

Not on my Moon it doesn't - it's still one tick out. Interestingly, 0.1 - 0.4s seem to be right, so that's certainly weird.


How exactly did you verify the timer is active for the correct number of ticks?
If you output the timer into other devices - notably other timers, you can see that it's the right number of ticks (verified against a self-resetting counter device). The two devices inputting to the timer give sensible results. The two devices inputting to a bolt do not. Beyond that, you can see that the error is absolute and corresponds to the length of time of a single tick by doing a few tests with altered parameters and a little bit of maths.		2011-02-07 21:23:00

Author:
rtm223
Posts: 6497

Not on my Moon it doesn't - it's still one tick out. Interestingly, 0.1 - 0.4s seem to be right, so that's certainly weird.

That's generally what "less than 0.5s" means. Perhaps I should've said "less than or equal to 0.4s". Still, I'm wrong anyway.



Beyond that, you can see that the error is absolute and corresponds to the length of time of a single tick by doing a few tests with altered parameters and a little bit of maths.

Just seems unlikely it would be inherent to the motor bolt, but rather a rounding error on the timer.

I took a slightly different approach, using two out-of-phase 15Hz pulses ANDed each with the timer, and connected to two synchronous ripple counters connected to an 8-bit adder. My results:-

0.1s = 3 frames (0)
0.2s = 6 frames (0)
0.3s = 9 frames (0)
0.4s = 12 frames (0)
0.5s = 14 frames (-1)
0.6s = 18 frames (0)
0.7s = 20 frames (-1)
0.8s = 24 frames (0)
0.9s = 27 frames (0)
1.0s = 29 frames (-1)
1.1s = 33 frames (0)
1.2s = 36 frames (0)
1.3s = 39 frames (0)
1.4s = 41 frames (-1)
1.5s = 44 frames (-1)
1.6s = 48 frames (0)
1.7s = 51 frames (0)
1.8s = 54 frames (0)
1.9s = 56 frames (-1)
2.0s = 59 frames (-1)

Got bored after that, but seems "fail randomly" is as good an explanation as any.

Edit: In retrospect, I suspect the timer being short by one frame was deliberate, and the cases where it's 'correct' are actually the rounding errors.

You would assume that creating a 1 second timer and connecting the output to the reset (in order to create a pulse every second) would be quite a common use of timers, but since the reset takes 1 frame to occur, they deliberately fudged the figures so that your timer wouldn't go out of sync by one second for every 30.

I've confirmed the reset definately loses you a frame, so your 0.1s timer with output fedback to reset is not actually 10Hz, but 7.5Hz - also confirmed.		2011-02-07 21:56:00

Author:
Aya042
Posts: 2870

Strange... My experiments with rotation speed all seem to come back with the rather logical 1 unit = 1 degree / second. although with an interesting side note, ANY friction between the rotating object and anything else will affect the rotation, even if the rotator is operating at 100% strength.

(Tested using a 60 unit rotation running on a 6 second countdown timer. and repeated 100 times. every time, the rotor arm returned to the same position as it began. even a 1.45 degree error would have shown in this test.)

And Movers operate at 1 unit = 1 Large Block per Second.

Chain/piston length = 10 units = 1 Large LBP Block with a minimum distance of 2.5 units (at zero length) - or 1 small grid block - for the standard size of the connectors on either end of the chain/piston etc.

PS... Whats the reasoning for attributing external measurements to LBP units? Personally, I can't see that it serves any practical purpose.		2011-02-07 23:41:00

Author:
Unknown User

I read it as exactly 0.5s, opps. However




You would assume that creating a 1 second timer and connecting the output to the reset (in order to create a pulse every second) would be quite a common use of timers, but since the reset takes 1 frame to occur, they deliberately fudged the figures so that your timer wouldn't go out of sync by one second for every 30.

I've confirmed the reset definately loses you a frame, so your 0.1s timer with output fedback to reset is not actually 10Hz, but 7.5Hz - also confirmed.

I hypothesised this, yet couldn't make it happen then I tested it. Forget my test methodology now but the expected additional fram for the feedback was completely missing. I even wrote a whole section on why it was 7:5hz for the blog.... Before testing and failing to produce 7.5hz....		2011-02-07 23:55:00

Author:
rtm223
Posts: 6497

...you can see that the error is absolute and corresponds to the length of time of a single tick ...

Yes it is! I've been digging through rotations for quite a while now, basically the last pulse gets dropped, because it stops. I wanted to write a tutorial on this for months, this thread just gave me the final kick. so here it is: How-to-rotate-motor-bolts-at-precise-angles (https://lbpcentral.lbp-hub.com/index.php?t=48303-How-to-rotate-motor-bolts-at-precise-angles&p=766223). The sequel for LBP2 will come tomorrow or the day after, I still need some testing, for example I'm quite sure, that rotating speed has been capped by ten, 1500 in LBP2 equals 50 in LBP1.		2011-02-08 00:55:00

Author:
Xario
Posts: 238

I wanted to write a tutorial on this for months, this thread just gave me the final kick. so here it is: How-to-rotate-motor-bolts-at-precise-angles (https://lbpcentral.lbp-hub.com/index.php?t=48303-How-to-rotate-motor-bolts-at-precise-angles&p=766223).

You may also be interested in this thread (https://lbpcentral.lbp-hub.com/index.php?t=19915-Incremental-Bolt), which was a similar idea, but using flipper pistons rather than emitters in order to get a single-frame pulse (so, as you observered, it would rotate by exactly the number of degrees its speed was set to per pulse).



The sequel for LBP2 will come tomorrow or the day after, I still need some testing, for example I'm quite sure, that rotating speed has been capped by ten, 1500 in LBP2 equals 50 in LBP1.

Yes. The unit of measurement of angular velocity has changed from "degrees per simulation frame" to "degrees per second", and given 30fps, that would make sense.

Note that a Wobble Bolt whose angle of rotation is >= 360 degrees, and fed with a directional input actually acts like a Motor Bolt, in the sense it continually spins in one direction, so you can use one of those to create a greater range of speeds, anything up to the maximum possible rotational speed of any object (900rpm), equivalent to a Motor Bolt of speed 180 (in LBP1) or speed 5400 (in LBP2).		2011-02-08 06:46:00

Author:
Aya042
Posts: 2870

I'd say, are people really gonna use this and calculate every time they use a rotator, or simply tweak and edit it until they got it the way its gonna move, tho?

I mean, maybe the uber tach smarties will, tho most will probably twweak it 'till its right, you know? 		2011-02-08 09:02:00

Author:
Silverleon
Posts: 6707

Time an object takes to stick to another when activating a Material Tweaker: 0.6 seconds.2011-02-08 12:23:00

Author:
Antikris
Posts: 1340

I'd say, are people really gonna use this and calculate every time they use a rotator, or simply tweak and edit it until they got it the way its gonna move, tho?

I mean, maybe the uber tach smarties will, tho most will probably twweak it 'till its right, you know?

I am new to these boards and do not want to be a jerk, but comments like this are not really constructive and should be left unsaid. Your opinion on what people may or may not do does not advance knowledge and at the end of the day, is that not what the tutorial forums are for?		2011-02-08 18:24:00

Author:
Unknown User

You are attributing your errors to the wrong object... your errors are coming from the way you're using the Timer and not the rotator. By having multiple steps between the timer and the rotator you are adding the processing time to the output of your timer, and this is where your confusion is coming from. Simplify the way you are timing the rotation and you will see.

The rotator works correctly at 1 degree per second per unit of rotational speed...
(Tested over 100 runs, with a 6 second run of a 60 speed rotator, both Motor Bolt and Rotator (100 complete revolutions))		2011-02-08 19:34:00

Author:
Unknown User

You are attributing your errors to the wrong object...

I'm assuming that's addressed to the OP. I think it's pretty clear to everyone that the figure should be 360, but the OP hasn't logged into LBPC since making that post, so it's yet to be updated.		2011-02-08 20:06:00

Author:
Aya042
Posts: 2870

I am new to these boards and do not want to be a jerk, but comments like this are not really constructive and should be left unsaid. Your opinion on what people may or may not do does not advance knowledge and at the end of the day, is that not what the tutorial forums are for?

No worries, yer not being a jerk at all.
Anywho, you said it yourself, its an "Opinion."
I'm just saing my opinion on the matter at hand, nothing more.

Just like you're in your right to post your opinion towards my comment, I'm in my own to give my opinnion about the subject.
Also, a mod can correct me if I'm wrong, they'll, edit/ delete the post if necessary, or simply inform me to edit/ delete it myself if its something shouldn't post, so you don't have to worry. 		2011-02-08 20:13:00

Author:
Silverleon
Posts: 6707

Morelyn, I have tried to duplicate your test with the timer connected directly to the motor bolt, 6 second run and 60 speed. First try was a failure. Here are some images

Before
http://www.nwlistit.com/images/rotate-start.jpg
After
http://www.nwlistit.com/images/rotate-end.jpg

In addition, I have tried to use both a anti-grav and material tweaker on the wheel being rotated with no difference in the results.

Edit: Actually, I've now been thinking about your statement regarding simplifying the connect and I am beginning to wonder if that would really make a difference. If the timer opens or closes a circuit, then it should make no difference how many switch are on the circuit because the timer is independent of it.

Is this thinking correct? For example, if you place an XOR switch with two inputs between a motor bolt and a battery and connect an inverted timer to the second lead of the XOR switch, then the timer would only regulate the opening and closing of the XOR switch. Only the XOR switch would be affected by the timer pulse.

I really don't know anything about electrical engineering and LPB2 is my first introduction to analog switches, so this is all pretty new to me and I appreciate the opportunity to learn.		2011-02-08 21:47:00

Author:
Unknown User

Strange... My experiments with rotation speed all seem to come back with the rather logical 1 unit = 1 degree / second. although with an interesting side note, ANY friction between the rotating object and anything else will affect the rotation, even if the rotator is operating at 100% strength.

(Tested using a 60 unit rotation running on a 6 second countdown timer. and repeated 100 times. every time, the rotor arm returned to the same position as it began. even a 1.45 degree error would have shown in this test.)

And Movers operate at 1 unit = 1 Large Block per Second.

Chain/piston length = 10 units = 1 Large LBP Block with a minimum distance of 2.5 units (at zero length) - or 1 small grid block - for the standard size of the connectors on either end of the chain/piston etc.

PS... Whats the reasoning for attributing external measurements to LBP units? Personally, I can't see that it serves any practical purpose.
The primary reason for doing this is for people to be able to use the movers more intuitively with units they are familiar with.
i.e. if you want a car moving at 150kph it would be a pain figuring out how much exactly that is in LBP.		2011-02-09 17:31:00

Author:
saarraz1
Posts: 86

You can't actually measure gravity in LBP, because any tests you do will be biassed by resistive forces - different objects fall at different speeds, so finding the gravitational constant is pretty difficult.

Surely it's still impossible to determine even if there were no resistive forces - you'd need to make some assumptions, and making the assumption that the acceleration due to gravity is ~9.8 ms-2 is a big assumption to make. The code would more likely define everything in terms of grid squares and have no concept of metres.		2011-02-09 21:39:00

Author:
Aya042
Posts: 2870

Especially when the Americans get here and get confused by kilometers and such.
What's a kilometer?!?!
Note - to anyone who can't take a joke: Just kidding!		2011-02-09 21:50:00

Author:
Super_Clone
Posts: 849

Having played with the rotating more, it seems there is a bug when controlling them from timers.

Basically, the rotation speed is degrees / second, but, the timers seem to activate the device for one clock tick less than the actual time on the timer. Which is strange as the correct number of clock ticks of activation are output when from the timer (which can be verified using a number of other devices).

This missing clock tick can be inferred from the following:

Pulsing single clock frames of activation into the motor bolt - 30 such pulses (i.e. a second of actual activation) will give the correct response.
triggering using a timer with 1s and 4s into a speed 360 bolt will end up offset by the same amount. This indicates that the error is absolute, not proportional to the speed of the bolt - as would be expected if the 361.45 rotation units in the OP was correct
If you add an extra frame of activation signal at the end of the timer then you will see correct behaviour, regardless of the time on the timer.

I just tried to check that and found that connecting two timers in a chain with a total time of x seconds, will finish counting 1 NOR tick before 1 timer set to x seconds.
Is this what you were saying?
That would explain the slightly off timing i guess.		2011-02-11 12:41:00

Author:
saarraz1
Posts: 86

I found this myself trying to use timers for analog division. I had a known signal going in (100%), the timer set for a specific duration and set to speed scale, and the circuit set up to reset the timer, then expose it to the signal for exactly one frame. Then I read off the signal using a logic probe, and my tests exactly line up with what Aya042 listed.

But it's not random, it's any number divisible by certain values. From my testing, any time interval divisible by 5 or 7 produced the -1 frame effect. (In my case, the division output was dividing by 1 less than the expected value.) I didn't find any other numbers beyond those two, but from Aya042's chart it looks like any number divisible by 19 is also effected. Note that the effect does not stack. A 3.5s timer (divisible by 5 AND 7) will still only be 1 frame off.

I'm going to counter the arguments that this is intentional though.

Resetting takes a frame, so this counters that...
In my case, I was only RUNNING the timer for one frame. It was reset the same frame it was given a signal, then an AND gate cut the signal off from the timer. If it took a frame to reset, the timer would still read 0 after my logic, because a frame after the reset signal, there was no input signal.

Finally, if it were intentional I could understand the multiples of .5s. But .7s? And 1.9s? Neither of those make sense as targets for special cases.		2011-02-25 02:15:00

Author:
Tygers
Posts: 114

Small bump, but I happened to have the need to produce very small (but accurate) analog values for something I was building, so I revisited this whole Timer inaccuracy issue, and did some more experiments.



But it's not random, it's any number divisible by certain values.

My assertion that it "fails randomly" was mostly a joke, hence the 'smiley' at the end of the line. It's almost certainly entirely deterministic, but when faced with something deterministic, but too unpredictable to be as useful as it could be, I'll sometimes derisively accuse it of being "random", akin to many of the perjorative senses of the word in the jargon file (http://www.catb.org/jargon/html/R/random.html).



From my testing, any time interval divisible by 5 or 7 produced the -1 frame effect. (In my case, the division output was dividing by 1 less than the expected value.) I didn't find any other numbers beyond those two, but from Aya042's chart it looks like any number divisible by 19 is also effected. Note that the effect does not stack. A 3.5s timer (divisible by 5 AND 7) will still only be 1 frame off.

I hereby debunk your divisibility theory, as my new results (http://wiki.lbpcentral.com/Talk:Timer) prove it wrong.

I strongly suspect it's related to the representation of floating point values in the hardware, but I'm not sure how exactly. I'm still running experiments, but I may be working on the false assumption that PS3 floats are represented as per IEEE-754.		2011-03-04 21:42:00

Author:
Aya042
Posts: 2870

Small bump, but I happened to have the need to produce very small (but accurate) analog values for something I was building, so I revisited this whole Timer inaccuracy issue, and did some more experiments.




My assertion that it "fails randomly" was mostly a joke, hence the 'smiley' at the end of the line. It's almost certainly entirely deterministic, but when faced with something deterministic, but too unpredictable to be as useful as it could be, I'll sometimes derisively accuse it of being "random", akin to many of the perjorative senses of the word in the jargon file (http://www.catb.org/jargon/html/R/random.html).




I hereby debunk your divisibility theory, as my new results (http://wiki.lbpcentral.com/Talk:Timer) prove it wrong.

I strongly suspect it's related to the representation of floating point values in the hardware, but I'm not sure how exactly. I'm still running experiments, but I may be working on the false assumption that PS3 floats are represented as per IEEE-754.

its a BUG... and an acknowledged bug at that http://getsatisfaction.com/littlebigplanet/topics/timer_bug_in_lbp2		2011-03-05 21:30:00

Author:
Unknown User

its a BUG... and an acknowledged bug at that http://getsatisfaction.com/littlebigplanet/topics/timer_bug_in_lbp2

Well, if they acknowledged it as a bug, then I guess it's safe to call it one, although they could be lying if it's more PC than to say "we made it wrong on purpose".

TBH, it seemed more likely that it was an accidental thing when someone recently pointed out that if you create a brand new Timer (which by default is set to 4.0s) it runs for 120 frames, but if you change it to something else and back to 4.0s, it only runs for 119.

I still doubt it'll get fixed tho'.		2011-03-05 22:42:00

Author:
Aya042
Posts: 2870

... assumption that PS3 floats are represented as per IEEE-754.

The Cell SPUs use a limited subset of the IEEE floating point format according to http://www.research.ibm.com/cell/SPU.html		2011-03-06 09:20:00

Author:
tameturtle
Posts: 150

The Cell SPUs use a limited subset of the IEEE floating point format according to http://www.research.ibm.com/cell/SPU.html

Yeah. I found another article after posting that claiming that the internal representation was "compatible" with IEEE754, but there was another section which mentioned that mathematical operations wouldn't necessarily yield the same results as other processors, so my attempts to simulate the code by writing it on a PC might not lead to any valid conclusions.

Specifically, IIRC, if you cast a float to an int without explicitly rounding it, then the difference between 119.99999 and 120.00001 is quite significant - one will map to 119, and the other to 120, which could potentially account for the problem.		2011-03-06 14:51:00

Author:
Aya042
Posts: 2870

I'd expect basic arithmetic operations to be carried out exactly the same way as on any general-purpose CPU, and the bit pattern of the internal representation to match conventional 32-bit floats as well. After all, it's easier and a lot cheaper to copy these basic units of logic from an existing, working and already debugged chip design than to build them from scratch.

Corner cases like denormals or rounding behaviour may differ from convention though (it seems worth noting that for many audio and video DSP applications, the default handling of these issues as prescribed by IEEE 754 is pretty much exactly not what you want, so it would make sense for the Cell SPUs to deviate from the norm there).		2011-03-06 16:30:00

Author:
tameturtle
Posts: 150

I'd expect basic arithmetic operations to be carried out exactly the same way as on any general-purpose CPU, and the bit pattern of the internal representation to match conventional 32-bit floats as well. After all, it's easier and a lot cheaper to copy these basic units of logic from an existing, working and already debugged chip design than to build them from scratch.

Corner cases like denormals or rounding behaviour may differ from convention though (it seems worth noting that for many audio and video DSP applications, the default handling of these issues as prescribed by IEEE 754 is pretty much exactly not what you want, so it would make sense for the Cell SPUs to deviate from the norm there).

Sounds about right. From this PDF (http://www.research.ibm.com/people/m/mikeg/papers/2006_ieeemicro.pdf)...

Applications that require saturating arithmetic exploit floating-point operations, which are naturally saturating and offer a wide dynamic range. The SPU implements single-precision floating-point arithmetic optimized for graphics with an IEEE-compatible data format. The graphics-optimized format eliminates traps and exceptions associated with IEEE arithmetic and substitutes appropriate default values to avoid disrupting real-time media processing from overflow or underflow exception conditions.
...although it's still a little vague.

Still, tetsujin's analog probe seems to confirm the format matches, as fractions with denominators which are powers of two (0.5, 0.25, 0.125, etc) seem to be represented exactly. There does seem to be a discrepency with the representation of some of the other fractional values, however...
<table> <tr><th>Input Value</th><th>PC</th><th>PS3</th></tr> <tr><td>0.0</td><td>0.0</td><td>0.0</td></tr> <tr><td>0.1</td><td>0.100000001490116119384765625</td><td>0.1000000238418579...</td></tr> <tr><td>0.2</td><td>0.20000000298023223876953125</td><td>0.1999999880790710...</td></tr> <tr><td>0.3</td><td>0.300000011920928955078125</td><td>0.3000000119209289...</td></tr> <tr><td>0.4</td><td>0.4000000059604644775390625</td><td>0.3999999761581420...</td></tr> <tr><td>0.5</td><td>0.5</td><td>0.5</td></tr> <tr><td>0.6</td><td>0.60000002384185791015625</td><td>0.6000000238418579...</td></tr> <tr><td>0.7</td><td>0.699999988079071044921875</td><td>0.6999999880790710...</td></tr> <tr><td>0.8</td><td>0.800000011920928955078125</td><td>0.8000000119209289...</td></tr> <tr><td>0.9</td><td>0.89999997615814208984375</td><td>0.8999999761581420...</td></tr> <tr><td>1.0</td><td>1.0</td><td>1.0</td></tr> </table>...although from this set, only 0.1, 0.2, and 0.4 are affected.

It's tough to tell where the discrepency is occurring tho'.		2011-03-06 19:11:00

Author:
Aya042
Posts: 2870

The graphics-optimized format eliminates traps and exceptions associated with IEEE arithmetic and substitutes appropriate default values to avoid disrupting real-time media processing from overflow or underflow exception conditions.


...although it's still a little vague.

As an example of what the PDF is on about, consider an IIR filter, a very basic tool of DSP applications. The recursive nature lets its impulse response fade in an exponentially decaying amplitude. At some point, this amplitude becomes too small for the finite-precision floating point format to represent. The IEEE standard mandates that when this happens, an underflow exception/trap is triggered. On x86 for example, this results in an interrupt, causing your code to stall while it is handled in the OS kernel. In the case of the IIR filter, you want this too-small amplitude to be simply and silently flushed to zero instead - that is the "appropriate default value" the PDF is mentioning.

I think that the constants in that table you posted might differ because different compilers were used to build the game code and the code you used to generate them on your computer - just guessing though.		2011-03-08 09:23:00

Author:
tameturtle
Posts: 150

In the case of the IIR filter, you want this too-small amplitude to be simply and silently flushed to zero instead - that is the "appropriate default value" the PDF is mentioning.

That bit makes sense - it's fairly consistent with saturating arithmetic. Another thing I came across when I was writing a (very basic) 3D graphics system about 20 years ago, was that it was very common to have a divide-by-zero situation occurring, and it would've been nice if that had just substituted a sensible value rather than causing an interrupt.

The bit that was vague was the phrase "IEEE-compatible data format", which I interpreted as meaning that, although any given floating point representation would yield the same decimal fraction on any architecture, the means by which said representation was determined in any mathematical operation could vary between different architectures.

For example, given the same representation of an approximation of 0.1f, an operation to multiply that value by, say, itself, may not necessarily yield the same representation of an approximation of 0.01f on different architectures.

If so, then any attempts to reproduce the algorithm used to determine the framecounts aren't gonna be consistent across different architectures, which makes it much more difficult to determine why only certain values of timers produce the correct framecount.



I think that the constants in that table you posted might differ because different compilers were used to build the game code and the code you used to generate them on your computer - just guessing though.

That's also possible, but I can in theory work around that by explicitly defining the same constants as are used on the PS3. Still, I think there's still gonna be too many unknowns to determine what's going on, particularly when I don't have the ability to compile and run arbitrary code on the PS3.

So we're probably stuck with using introspection and/or lookup tables to determine the values produced when using timers to create small analog signals. You might think "What does it matter? You're gonna lose precision with arithmetic anyway", but I was hoping that by performing only addition and subtraction on fractions whose denominators were powers of two, that may not occur, which ought to be sufficient for some applications where accurate analog math is required.

The tricky bit is actually finding ways to produce these very small fractions accurately in the first place, due to this issue with timers.		2011-03-08 16:14:00

Author:
Aya042
Posts: 2870

Why do y'all darn townsfolk need to be so **** smart? My brain is operating at a frequency of 0,0000001.2011-03-08 17:38:00

Author:
BasketSnake
Posts: 2391

Sounds about right. From this PDF (http://www.research.ibm.com/people/m/mikeg/papers/2006_ieeemicro.pdf)...

...although it's still a little vague.

Still, tetsujin's analog probe seems to confirm the format matches, as fractions with denominators which are powers of two (0.5, 0.25, 0.125, etc) seem to be represented exactly. There does seem to be a discrepency with the representation of some of the other fractional values, however...
<table> <tr><th>Input Value</th><th>PC</th><th>PS3</th></tr> <tr><td>0.0</td><td>0.0</td><td>0.0</td></tr> <tr><td>0.1</td><td>0.100000001490116119384765625</td><td>0.1000000238418579...</td></tr> <tr><td>0.2</td><td>0.20000000298023223876953125</td><td>0.1999999880790710...</td></tr> <tr><td>0.3</td><td>0.300000011920928955078125</td><td>0.3000000119209289...</td></tr> <tr><td>0.4</td><td>0.4000000059604644775390625</td><td>0.3999999761581420...</td></tr> <tr><td>0.5</td><td>0.5</td><td>0.5</td></tr> <tr><td>0.6</td><td>0.60000002384185791015625</td><td>0.6000000238418579...</td></tr> <tr><td>0.7</td><td>0.699999988079071044921875</td><td>0.6999999880790710...</td></tr> <tr><td>0.8</td><td>0.800000011920928955078125</td><td>0.8000000119209289...</td></tr> <tr><td>0.9</td><td>0.89999997615814208984375</td><td>0.8999999761581420...</td></tr> <tr><td>1.0</td><td>1.0</td><td>1.0</td></tr> </table>...although from this set, only 0.1, 0.2, and 0.4 are affected.

It's tough to tell where the discrepency is occurring tho'.

Are you simulating how his probe works, or just using the standard library floating point formatting? I have a C program that exactly simulates how his probe works (Including simulating the NOT gates to invert the value by doing 1.0-val, subtracting 0.5 from the value at each bit if needed, then performing his modified double-dabble) and I can 100% match his results. So I think the difference here is how the number is processed for display, vs differences in representation. Right now there is no probe which displays more than 24 bits of precison in LBP, due to the NOT gate forcing that as the best precision possible. That's also why it's only values below 0.5 that are effected, anything above 0.5 only HAS 24 bits of precision.

I do like the theory that it is just integer truncation of a .99999999 result, that seems very plausible; though it is baffling why that would be an issue with values such as 0.5 and 1.0.

Also I'd already debunked myself that the pattern was not ALL numbers divisible by certain values; I just hadn't published it anywhere. I added my own results to the table on the wiki, as I went all the way up to 13.5s in 0.1s increments. It still seems to hold true in 2/3rds of the cases. Up to 13.5s, there are 55 values which are 1 frame off, and 19 values which I expected would be 0.1s off by my theory, which were actually accurate.		2011-03-08 22:08:00

Author:
Tygers
Posts: 114

Are you simulating how his probe works, or just using the standard library floating point formatting?

The latter, since I couldn't be bothered to work out how it worked.



...I can 100% match his results.

Okay. Thought that might've been all it was, but I still can't necessarily assume the results of arithmetic would be the same. I initially assumed they did it iteratively, something like...


void myfunc(float target_time)
{
int expected = (int) (target_time * 30.0f);
float delta = 1.0f/30.0f;
float current_time = 0.0f;
int i = 0;
for (;
{
current_time += delta;
if (current_time > target_time) break;
++i;
}
int offset = i - expected;
printf("%.1f = %d frames (%d)n", target_time, i, offset);
}

...which yields...


0.0 = 0 frames (0)
0.1 = 2 frames (-1)
0.2 = 6 frames (0)
0.3 = 9 frames (0)
0.4 = 12 frames (0)
0.5 = 15 frames (0)
0.6 = 17 frames (-1)
0.7 = 20 frames (-1)
0.8 = 23 frames (-1)
0.9 = 26 frames (-1)
1.0 = 29 frames (-1)

...which shows a certain amount of variance. But if the Timer is able to output an analog signal all the time, and that signal is always based on the framecounts, then an iterative calculation makes no sense.



I do like the theory that it is just integer truncation of a .99999999 result, that seems very plausible; though it is baffling why that would be an issue with values such as 0.5 and 1.0.

Could be accounted for by a deliberate fudge-factor in the algorithm, but that still doesn't explain why some above the correct value (like 0.3) and some below (like 0.9) both come out correctly.

Still, given the lookup table, that might be good enough - unless someone debunks my theory that the analog value is calculated by dividing one framecount by the other.		2011-03-08 22:38:00

Author:
Aya042
Posts: 2870

Here's something interesting... I tried a slight variant on that...


void main() {
int i;
for (i = 0; i < 135; i++) {
float f = 0.1f * i;
int frames = f * 30;
printf("%0.1fs = %d frames (%d)n", f, frames, frames - i * 3);
}
}

This produces...

0.0s = 0 frames (0)
0.1s = 3 frames (0)
0.2s = 6 frames (0)
0.3s = 9 frames (0)
0.4s = 12 frames (0)
0.5s = 15 frames (0)
0.6s = 18 frames (0)
0.7s = 20 frames (-1)
0.8s = 24 frames (0)
0.9s = 27 frames (0)
1.0s = 30 frames (0)
1.1s = 33 frames (0)
1.2s = 36 frames (0)
1.3s = 39 frames (0)
1.4s = 41 frames (-1)
1.5s = 45 frames (0)
1.6s = 48 frames (0)
1.7s = 51 frames (0)
1.8s = 54 frames (0)
1.9s = 56 frames (-1)
2.0s = 60 frames (0)

It's not exact, but everything that lists as a -1 up to 13.5 is a -1 in LBP. (I didn't try further.)		2011-03-08 23:32:00

Author:
Tygers
Posts: 114


LBPCentral Archive Statistics
Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Datenschutz
Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.