Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
This occurred to me when comicalflop told me to jump less on rayman 2 because there was a speed loss of 1/55th of the maximum speed while in the air.
EDIT: this generally only applies to 3d games
Basically, you may lose/gain speed due to computer rounding. In Rayman 2 for example, you maximum running speed is 55. I'm assuming this is units (being the smallest unit in the game) per second. Obviously traveling along the x or y axis will give the speed 55 exactly, because 55^2 = 0^2 + 55^2. This is of course, given from Pythagoras' theorem. However, traveling along other directions will most likely give irrational answers for x and y. Say you're traveling on a 45 degree angle, since the speed is 55 and x=y, x and y are both approximately equal to 38.89 . The emulator would not use the floating point values of this number, because 1 is the smallest measurable unit in the game, and there is no greater precision. One way of dealing with this is to just ignore the numbers after the decimal point, so the difference for x or y is then 38. Therefore, your actual speed is 53.7 rather that the maximum of 55. in this case, jumping, and decreasing your speed to 54 may not have any effect on your actual speed.
however, if the game decides to round up instead of down, a number of angles would increase the maximum running speed to over 56 maybe.
Another item for consideration would be if the straight line between A and B requires an angle that would decrease the speed of your character a considerable amount, it may be wiser to deviate slightly in order to achieve greater speeds.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
While your reasoning is correct, most platformers don't use the pythagorian theorem for calculating speed. In most platformer, your horiztonal speeds are the same when running and when jumping. The most common reason why jumping may be slower than walking is that you stop for one or more frames when starting the jump and/or landing from the jump.
In some games, like Batman for NES, it gets a bit more complicated. Although our hero stops for a few frames before each jump, his horizontal speed is actually greater while in air than when he's walking! So if you were to make a long enough jump, it would save time, but normally jumping wastes time.
I can mostly speak for NES games though, perhaps there are game for SNES or Genesis that use the Pythagorian theorem when calculating your speed components when jumping.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
What I'm talking about here is when two dimensions are ambiguous. For example, a 3d game, where there are two horizontal ambiguous directions and one distinguishable height dimension. The horizontal speed is generally independent of the vertical positions or speeds. However traveling along a flat piece of ground will have the same approximate speed no matter which direction.
Also Pythagorean theorem is just a clear method of showing my point, the actual game would most likely use standard trigonometric functions in order to find speed and direction.
This theory generally applies to 3 dimensional games and I would be surprised if there are more than 10 two dimensional games that would benefit from this theory.
Unless the game is specifically centered around motion physics (like the rubber wire in Umihara Kawase), it's usually much simplier: there are different subpixel values for each type of motion in the game. If Comicalflop says the maximum speed is 55 units per frame, it likely means there are (assuming here; never played Rayman 2) each pixel is treated by the game as 16 said units, making the maximum speed 3.44 pixels per frame (check if it looks so), or 1.72 if it's 32 units per pixel.
Position-based triggers, as well as the sprites' on-screen positions, are pretty much always rounded down relatively to your movement direction (i.e., they don't update until you've hit the next "integer" part — a full pixel). In case with more complex motion, various factors ("wind", "slope" and other such effects) may be applied to your speed, but more often than not they just shift your position forward by a pre-determined amount on each frame of effect. The rounding doesn't even happen in calculation per se most of the time, it's just a post-effect pertaining to the display output.
Also, in regards to one of your questions: horizontal and vertical speeds are tracked separately; they won't magically combine to produce a value higher than usual for each of them separetely due to rounding.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Actually in most games, horizontal and vertical speeds are stored separately, for ease of use. But for stuff like racing it may be a question of magnitude+direction, yeah.
oh curse you moozooh
Perhaps some 3D platformers use the pythagorean method for calculating X and Z speed, but I imagine that in those, the calculation is camera relative, and additionally that any floating point rounding error is so small as to be negligible within the size of a single level.
But even in cases where all of the conditions for andymac's thesis are true, it's usually not going to be useful to take those diagonals. Because the added speed gained when travelling at angles to the straight line is only ever going to be added perpindicular to the direction of motion.
Let's take a hypothetical example where there's a game where your max speed is 6 pixels per frame, but it uses the pythagorean method to calculate your speed on two separate axes, given one total speed value.
Let us say that when going straight forward, you get 6 pixels per frame forward, but when going 3 degrees to the left of forward, you get 6 pixels per frame forward, and 1/3rd pixel per frame left due to rounding error.
If your goal is a straight line forward from the starting point, the result will be that you reach the goal in the same time period, but you'll be a few pixels further to the left when you collide with it. Which I suppose could be useful enough in arriving at point A in an optimal position to get quickly to point B, but would not be helpful at all if point A is the only point you need to visit.
Edit: Oh damn, four posts between me hitting reply and hitting submit.
How fleeting are all human passions compared with the massive continuity of ducks.
Q3's motion physics is ridiculously complex compared to any 2D platformer, period. :)
Though that's the exact reason it has been subjected to these ridiculous amounts of abuse.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Upthorn is the only person who gets what I'm talking about here. The gain for keeping this in mind might be a frame every five minutes saved.
At 55 units per frame, say you save half a unit every frame, it's only four seconds before you save a frame, and beleive me, there are enough for-second treks in a game like Rayman 2. Also a lot of people are assuming that Rayman 2 is a 2d sidescrolling platformer (moozooh). It is not. Rayman 2 is a sandbox 3d platformer. I don't blame you, because you stated that you've never played it before.
Also you need two ambiguous dimensions for this to work. horizontal and vertical do not count. you would need both horizontal or both vertical (obviously not possible). sometimes, there are three ambiguous dimensions, generally in games where there is no gravity/ flying sims. The mathematics then gets more complex.
Games that will not benefit from this theorem:
sonic games
side scrolling mario
megaman
Games that will benefit:
3d games
top down racing games
SUPER MARIO 64 (only when moving normally. while blj ing, the rounding errors become insignifcant and it would require about a full minute of blj ing to save a single frame)
next person doing an sm64 TAS might save 2 or 3 frames by doing this
There actually is a 2D version of Rayman 2 (GBC), which might have been the thing that confused me. :)
I'm pretty sure I even had it somewhere among the GBC ROMs on my player.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
All you'd really need to do is compare the total distance moved at various angles with ones along the straight X and Y axis. Possibly even just 1/4 of the total.
Although I honestly think the gain from something like this would not be worth the trouble. As you said, one frame in 5 minutes really isn't worth anything. Even in a hour long movie, that would be just barely 12 frames.
SUPER MARIO 64 (only when moving normally. while blj ing, the rounding errors become insignifcant and it would require about a full minute of blj ing to save a single frame)
next person doing an sm64 TAS might save 2 or 3 frames by doing this
Mario's normal top speed it 55, thats assumming you're diving or LJing on a perfectly level surface. What many don't know about LJing is that Mario's forward momentum is infinite, it will only reset when Mario hits the ground or a wall. When BLJing Mario's speed is approxiametly increases by 45% each time, and the game will crash if Mario's speed exceeds 65526. Sadly bljing causes Mario to move so fast that your whole straight line theory would be non applicable. While for running, the distances are so short it's non appicable as well. Since the first 0 star run speed values have been used to perfect bljing and to maintain perfectly straight lines while the camera angles are changing.
Let's take a hypothetical example where there's a game where your max speed is 6 pixels per frame, but it uses the pythagorean method to calculate your speed on two separate axes, given one total speed value.
Let us say that when going straight forward, you get 6 pixels per frame forward, but when going 3 degrees to the left of forward, you get 6 pixels per frame forward, and 1/3rd pixel per frame left due to rounding error.
If your goal is a straight line forward from the starting point, the result will be that you reach the goal in the same time period, but you'll be a few pixels further to the left when you collide with it.
Keep in mind that the position of a character is most likely stored as X/Y/Z. How often is your goal at the same exact X or Y coordinate as where you're starting?
Although most 3D games are likely to have several decimal places of accuracy one way or another specifically to avoid this sort of bug, and early 3D games that don't probably don't give you enough control in your direction to abuse the rounding in your favor either. I don't see many games at all getting much out of this idea, to be honest.
Then again, I have a habit of over-estimating programing in games.
kwinse wrote:
Kejardon wrote:
Kriole wrote:
Samus is damaged by a Rinka in the opening.
That's a script action; no damage.
... it just dawned on me I know way too much about SM.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
A number of things:
AKA was wrong, the game crashes when Mario's speed reaches 65536/5 it's 65536 in one direction and 65535 in the other (actually scratch that, Im not thinking straight, it would be an unsigned short integer. Its 65536) . I'm not sure quite which, because I haven't experimented with this value, but it definitely is not 65526. I'm assuming that Mario's x,y,z,Dx,Dy,Dz, and direction and magnitude are all stored in the RAM and that none of these values can exceed a certain amount before something unexpected happens like overflow.
3d games are precise enough. 55 is in units per frame. Generally speed is measured in subpixels for 2d games and that is generally considered to be precise enough. This is basically the same precision, but the equivalent for 3d. There are no decimal places.
I have an example in front of me that proves what Im talking about. Its where your maximum speed is 25 units per frame and you travel in a straight line at a 45 degree angle. your velocity rounds down to 24.04 units per frame. If you deviate on a gradient of 17/18 for one frame and 18/17 for the next, your velocity increases to 24.74 units per second at 45 degrees.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
In this example it was impossible to travel at 25 unless traveling straight along the x or y axis. it's not about gaining speed, it's more about minimising the loss.
How is it misleading? If the straight line from A to B is at an angle which leads to negative rounding errors, then perhaps some almost straight but more complicated path from A to B wold be faster. Seems reasonable to me, though I agree that this probably is negligible.
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
to tell the absolute truth, Personally I think that the speed gain is slightly less than that of the smw hopping glitch. The speed gain is small, but remember, you're gaining units 30 times a second, so it adds up. As for examples try the one on the previous page, I have provided enough info for you to construct this for yourself. I would gladly provide an image but it's too much work finding a suitable host that won't crash.
EDIT: off topic, but I'm now a member and not a newbie anymore! 30th post!
I think that the speed gain is slightly less than that of the smw hopping glitch. The speed gain is small, but remember, you're gaining units 30 times a second, so it adds up
The gains are most likely to be neligible.
Games like SMW store movement as an 8-bit integer; my best guess is that a speed of "37" = 2 5/16 pixels/frame (remember, this is just estimation).
Without the speed oscillation trick via hopping glitch, his average speed is 35.8. His max speed is 37; the improved value is 1.2, or about 3%.
Games that run on newer hardware and utilize more bits for movement/position are very likely will have rounding errors that are much smaller. The gains from these would, by my guess, be far less than even 1%. If average movement speed is ~4000units/frame, your best change is going to be at best 1 or 2 units (no smaller unit), and that's assuming the game doesn't have higher precision in its movement.
In short: I believe this concept to be completely useless except in either strange circumstances or very badly programmed games.
Games that run on newer hardware and utilize more bits for movement/position are very likely will have rounding errors that are much smaller. The gains from these would, by my guess, be far less than even 1%. If average movement speed is ~4000units/frame, your best change is going to be at best 1 or 2 units (no smaller unit), and that's assuming the game doesn't have higher precision in its movement.
In short: I believe this concept to be completely useless except in either strange circumstances or very badly programmed games.
This is basically what I was saying in my two posts on the first page.
How fleeting are all human passions compared with the massive continuity of ducks.
