What is a subpixel in Super Mario Bros, and how does it relate to wall clipping?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{
margin-bottom:0;
}
What are "subpixels" in Super Mario Bros on the NES? How does it relate to wall clipping?
At 4:42 in the following video, the notion is mentioned in the context of how it relates to "wall clipping":
https://youtu.be/4CgC2g43smA?t=282
My own reasoning:
Subpixels is a term used to describe Mario's x,y coordinates as a float. This float increments (in "subpixels") as a function of time multiplied by some gravity constant (y axis), player input (x and y), etc. Eventually the increment is enough for a full pixel of movement. This allows for more smooth acceleration of the movement of Mario in the game.
It appears the collision detection is not perfect in this game. Not every pixel of Mario is checked for collision with every pixel of solid sprites such as pipes and bricks.
This is probably due to optimizations, but exactly how the collision detection in Super Mario Bros works eludes me, and I believe it is key to understand the collision detection in order to understand the wall clipping.
graphics nes sprite
add a comment
|
What are "subpixels" in Super Mario Bros on the NES? How does it relate to wall clipping?
At 4:42 in the following video, the notion is mentioned in the context of how it relates to "wall clipping":
https://youtu.be/4CgC2g43smA?t=282
My own reasoning:
Subpixels is a term used to describe Mario's x,y coordinates as a float. This float increments (in "subpixels") as a function of time multiplied by some gravity constant (y axis), player input (x and y), etc. Eventually the increment is enough for a full pixel of movement. This allows for more smooth acceleration of the movement of Mario in the game.
It appears the collision detection is not perfect in this game. Not every pixel of Mario is checked for collision with every pixel of solid sprites such as pipes and bricks.
This is probably due to optimizations, but exactly how the collision detection in Super Mario Bros works eludes me, and I believe it is key to understand the collision detection in order to understand the wall clipping.
graphics nes sprite
3
It's not a float, it's a fixed point fractional number. A float would have an additonal field telling where the boundary between full and sub pixels is.
– Janka
May 27 at 11:58
add a comment
|
What are "subpixels" in Super Mario Bros on the NES? How does it relate to wall clipping?
At 4:42 in the following video, the notion is mentioned in the context of how it relates to "wall clipping":
https://youtu.be/4CgC2g43smA?t=282
My own reasoning:
Subpixels is a term used to describe Mario's x,y coordinates as a float. This float increments (in "subpixels") as a function of time multiplied by some gravity constant (y axis), player input (x and y), etc. Eventually the increment is enough for a full pixel of movement. This allows for more smooth acceleration of the movement of Mario in the game.
It appears the collision detection is not perfect in this game. Not every pixel of Mario is checked for collision with every pixel of solid sprites such as pipes and bricks.
This is probably due to optimizations, but exactly how the collision detection in Super Mario Bros works eludes me, and I believe it is key to understand the collision detection in order to understand the wall clipping.
graphics nes sprite
What are "subpixels" in Super Mario Bros on the NES? How does it relate to wall clipping?
At 4:42 in the following video, the notion is mentioned in the context of how it relates to "wall clipping":
https://youtu.be/4CgC2g43smA?t=282
My own reasoning:
Subpixels is a term used to describe Mario's x,y coordinates as a float. This float increments (in "subpixels") as a function of time multiplied by some gravity constant (y axis), player input (x and y), etc. Eventually the increment is enough for a full pixel of movement. This allows for more smooth acceleration of the movement of Mario in the game.
It appears the collision detection is not perfect in this game. Not every pixel of Mario is checked for collision with every pixel of solid sprites such as pipes and bricks.
This is probably due to optimizations, but exactly how the collision detection in Super Mario Bros works eludes me, and I believe it is key to understand the collision detection in order to understand the wall clipping.
graphics nes sprite
graphics nes sprite
asked May 27 at 6:35
AlphaCentauriAlphaCentauri
5282 silver badges12 bronze badges
5282 silver badges12 bronze badges
3
It's not a float, it's a fixed point fractional number. A float would have an additonal field telling where the boundary between full and sub pixels is.
– Janka
May 27 at 11:58
add a comment
|
3
It's not a float, it's a fixed point fractional number. A float would have an additonal field telling where the boundary between full and sub pixels is.
– Janka
May 27 at 11:58
3
3
It's not a float, it's a fixed point fractional number. A float would have an additonal field telling where the boundary between full and sub pixels is.
– Janka
May 27 at 11:58
It's not a float, it's a fixed point fractional number. A float would have an additonal field telling where the boundary between full and sub pixels is.
– Janka
May 27 at 11:58
add a comment
|
2 Answers
2
active
oldest
votes
Subpixels in general are invisible fractional pixels that you cannot see, but are used internally to represent the positions of objects at a finer level than they're capable of being displayed at.
So far as Super Mario goes they're represented as an integer with 16 subpixels per visible pixel. This allows inertia to be loosely modeled so that you can start off moving slowly, but gradually speed up in a more realistic fashion than modeling by exact pixels would give.
Wall glitching tricks involve manipulating this value - by very short movements against the direction you're moving in to decrease it and jumping directly into a block to increase it - to get it to carry over and increase your pixel position so that the code that would normally push you back out of a wall results instead in sucking you further in.
1
Not completely related follow-up question: does that imply that the levels are at most 16*256 = 4096 pixels wide? I'm trying to reason as to why a four bit fraction was selected; fitting global ordinates into two bytes is a guess.
– Tommy
May 27 at 7:28
1
No, the subpixel count is an entirely different byte to the position in the level which is stored in two bytes. While this would theoretically allow for 256 subpixels (and you'll see some people give that answer for that reason) that's way more precision than the game needs.
– Matthew Barber
May 27 at 22:42
Right; I see from your other comment that an entire byte is used for the subpixel component, it's just that only the top nibble contains values. I was otherwise imaging an exactly-the-most-awkward-possible shift by four to convert to an integer, rather than a more standard just-ignore-a-byte fixed point scheme. So I started from a false premise.
– Tommy
May 28 at 3:45
@Tommy: normally when a program uses fixed-point math, you use the lown
bits of a wider integer type. e.g. treating the low 5 bits of anint32_t
as fractional gives you a certain range (32-5 integer bits), and 5 fractional precision bits. It's certainly reasonable to guess that Mario would use a 16-bit integer with a 12:4 bit fixed-point split, but on an 8-bit CPU even 16-bit requires extended precision so I can see why there might be some advantages to having the integer part accessible separately without a byte-crossing right shift.
– Peter Cordes
May 28 at 9:24
add a comment
|
In many 8 bit games the position of the player's sprite is stored as the pixel coordinates it rests on. For many games that is adequate, but it has some limitations.
If the game only uses whole pixel coordinates then the minimum movement speed is 1 pixel. In other words the resolution of the player's speedometer is 1 pixel. They can be moving at 1 pixel per frame, or 2 pixels per frame, but not 1.5 pixels per frame.
In Super Mario Bros. that is inadequate. Mario has a lot of momentum and a major part of the game is managing it. If his speedometer had a 1 pixel/frame resolution he would feel "stiff" to control. One of the major innovations of that game, which many others soon adopted, was sub-pixel positioning and speed.
Super Mario Bros divides each pixel up into 256 sub-pixel divisions. 256 is used because it's the range of an 8 bit number, which the 8 bit Famicom / NES could handle easily. So Mario's position and speed has a resolution of 1/256th of a pixel.
When Mario reaches an obstacle the game pushes him away from it, so that he ends up outside of any solid blocks. However, the check for collisions with solid objects is only performed every other frame, so there is 1 frame where Mario can be inside a solid block before it starts pushing him. If he is moving fast enough to get deep inside the block it can end up pushing him the wrong way, allowing him to pass through solid walls. This is only possible because sub-pixel accuracy allows him to partially inside the block for two consecutive frames.
13
Just to add that, although there are 256 possible values in a byte, the subpixel mathematics is all done in multiples of 16, hence there are effectively 16 of them as per my answer.
– Matthew Barber
May 27 at 22:52
add a comment
|
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f11126%2fwhat-is-a-subpixel-in-super-mario-bros-and-how-does-it-relate-to-wall-clipping%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Subpixels in general are invisible fractional pixels that you cannot see, but are used internally to represent the positions of objects at a finer level than they're capable of being displayed at.
So far as Super Mario goes they're represented as an integer with 16 subpixels per visible pixel. This allows inertia to be loosely modeled so that you can start off moving slowly, but gradually speed up in a more realistic fashion than modeling by exact pixels would give.
Wall glitching tricks involve manipulating this value - by very short movements against the direction you're moving in to decrease it and jumping directly into a block to increase it - to get it to carry over and increase your pixel position so that the code that would normally push you back out of a wall results instead in sucking you further in.
1
Not completely related follow-up question: does that imply that the levels are at most 16*256 = 4096 pixels wide? I'm trying to reason as to why a four bit fraction was selected; fitting global ordinates into two bytes is a guess.
– Tommy
May 27 at 7:28
1
No, the subpixel count is an entirely different byte to the position in the level which is stored in two bytes. While this would theoretically allow for 256 subpixels (and you'll see some people give that answer for that reason) that's way more precision than the game needs.
– Matthew Barber
May 27 at 22:42
Right; I see from your other comment that an entire byte is used for the subpixel component, it's just that only the top nibble contains values. I was otherwise imaging an exactly-the-most-awkward-possible shift by four to convert to an integer, rather than a more standard just-ignore-a-byte fixed point scheme. So I started from a false premise.
– Tommy
May 28 at 3:45
@Tommy: normally when a program uses fixed-point math, you use the lown
bits of a wider integer type. e.g. treating the low 5 bits of anint32_t
as fractional gives you a certain range (32-5 integer bits), and 5 fractional precision bits. It's certainly reasonable to guess that Mario would use a 16-bit integer with a 12:4 bit fixed-point split, but on an 8-bit CPU even 16-bit requires extended precision so I can see why there might be some advantages to having the integer part accessible separately without a byte-crossing right shift.
– Peter Cordes
May 28 at 9:24
add a comment
|
Subpixels in general are invisible fractional pixels that you cannot see, but are used internally to represent the positions of objects at a finer level than they're capable of being displayed at.
So far as Super Mario goes they're represented as an integer with 16 subpixels per visible pixel. This allows inertia to be loosely modeled so that you can start off moving slowly, but gradually speed up in a more realistic fashion than modeling by exact pixels would give.
Wall glitching tricks involve manipulating this value - by very short movements against the direction you're moving in to decrease it and jumping directly into a block to increase it - to get it to carry over and increase your pixel position so that the code that would normally push you back out of a wall results instead in sucking you further in.
1
Not completely related follow-up question: does that imply that the levels are at most 16*256 = 4096 pixels wide? I'm trying to reason as to why a four bit fraction was selected; fitting global ordinates into two bytes is a guess.
– Tommy
May 27 at 7:28
1
No, the subpixel count is an entirely different byte to the position in the level which is stored in two bytes. While this would theoretically allow for 256 subpixels (and you'll see some people give that answer for that reason) that's way more precision than the game needs.
– Matthew Barber
May 27 at 22:42
Right; I see from your other comment that an entire byte is used for the subpixel component, it's just that only the top nibble contains values. I was otherwise imaging an exactly-the-most-awkward-possible shift by four to convert to an integer, rather than a more standard just-ignore-a-byte fixed point scheme. So I started from a false premise.
– Tommy
May 28 at 3:45
@Tommy: normally when a program uses fixed-point math, you use the lown
bits of a wider integer type. e.g. treating the low 5 bits of anint32_t
as fractional gives you a certain range (32-5 integer bits), and 5 fractional precision bits. It's certainly reasonable to guess that Mario would use a 16-bit integer with a 12:4 bit fixed-point split, but on an 8-bit CPU even 16-bit requires extended precision so I can see why there might be some advantages to having the integer part accessible separately without a byte-crossing right shift.
– Peter Cordes
May 28 at 9:24
add a comment
|
Subpixels in general are invisible fractional pixels that you cannot see, but are used internally to represent the positions of objects at a finer level than they're capable of being displayed at.
So far as Super Mario goes they're represented as an integer with 16 subpixels per visible pixel. This allows inertia to be loosely modeled so that you can start off moving slowly, but gradually speed up in a more realistic fashion than modeling by exact pixels would give.
Wall glitching tricks involve manipulating this value - by very short movements against the direction you're moving in to decrease it and jumping directly into a block to increase it - to get it to carry over and increase your pixel position so that the code that would normally push you back out of a wall results instead in sucking you further in.
Subpixels in general are invisible fractional pixels that you cannot see, but are used internally to represent the positions of objects at a finer level than they're capable of being displayed at.
So far as Super Mario goes they're represented as an integer with 16 subpixels per visible pixel. This allows inertia to be loosely modeled so that you can start off moving slowly, but gradually speed up in a more realistic fashion than modeling by exact pixels would give.
Wall glitching tricks involve manipulating this value - by very short movements against the direction you're moving in to decrease it and jumping directly into a block to increase it - to get it to carry over and increase your pixel position so that the code that would normally push you back out of a wall results instead in sucking you further in.
answered May 27 at 6:57
Matthew BarberMatthew Barber
1,3442 silver badges9 bronze badges
1,3442 silver badges9 bronze badges
1
Not completely related follow-up question: does that imply that the levels are at most 16*256 = 4096 pixels wide? I'm trying to reason as to why a four bit fraction was selected; fitting global ordinates into two bytes is a guess.
– Tommy
May 27 at 7:28
1
No, the subpixel count is an entirely different byte to the position in the level which is stored in two bytes. While this would theoretically allow for 256 subpixels (and you'll see some people give that answer for that reason) that's way more precision than the game needs.
– Matthew Barber
May 27 at 22:42
Right; I see from your other comment that an entire byte is used for the subpixel component, it's just that only the top nibble contains values. I was otherwise imaging an exactly-the-most-awkward-possible shift by four to convert to an integer, rather than a more standard just-ignore-a-byte fixed point scheme. So I started from a false premise.
– Tommy
May 28 at 3:45
@Tommy: normally when a program uses fixed-point math, you use the lown
bits of a wider integer type. e.g. treating the low 5 bits of anint32_t
as fractional gives you a certain range (32-5 integer bits), and 5 fractional precision bits. It's certainly reasonable to guess that Mario would use a 16-bit integer with a 12:4 bit fixed-point split, but on an 8-bit CPU even 16-bit requires extended precision so I can see why there might be some advantages to having the integer part accessible separately without a byte-crossing right shift.
– Peter Cordes
May 28 at 9:24
add a comment
|
1
Not completely related follow-up question: does that imply that the levels are at most 16*256 = 4096 pixels wide? I'm trying to reason as to why a four bit fraction was selected; fitting global ordinates into two bytes is a guess.
– Tommy
May 27 at 7:28
1
No, the subpixel count is an entirely different byte to the position in the level which is stored in two bytes. While this would theoretically allow for 256 subpixels (and you'll see some people give that answer for that reason) that's way more precision than the game needs.
– Matthew Barber
May 27 at 22:42
Right; I see from your other comment that an entire byte is used for the subpixel component, it's just that only the top nibble contains values. I was otherwise imaging an exactly-the-most-awkward-possible shift by four to convert to an integer, rather than a more standard just-ignore-a-byte fixed point scheme. So I started from a false premise.
– Tommy
May 28 at 3:45
@Tommy: normally when a program uses fixed-point math, you use the lown
bits of a wider integer type. e.g. treating the low 5 bits of anint32_t
as fractional gives you a certain range (32-5 integer bits), and 5 fractional precision bits. It's certainly reasonable to guess that Mario would use a 16-bit integer with a 12:4 bit fixed-point split, but on an 8-bit CPU even 16-bit requires extended precision so I can see why there might be some advantages to having the integer part accessible separately without a byte-crossing right shift.
– Peter Cordes
May 28 at 9:24
1
1
Not completely related follow-up question: does that imply that the levels are at most 16*256 = 4096 pixels wide? I'm trying to reason as to why a four bit fraction was selected; fitting global ordinates into two bytes is a guess.
– Tommy
May 27 at 7:28
Not completely related follow-up question: does that imply that the levels are at most 16*256 = 4096 pixels wide? I'm trying to reason as to why a four bit fraction was selected; fitting global ordinates into two bytes is a guess.
– Tommy
May 27 at 7:28
1
1
No, the subpixel count is an entirely different byte to the position in the level which is stored in two bytes. While this would theoretically allow for 256 subpixels (and you'll see some people give that answer for that reason) that's way more precision than the game needs.
– Matthew Barber
May 27 at 22:42
No, the subpixel count is an entirely different byte to the position in the level which is stored in two bytes. While this would theoretically allow for 256 subpixels (and you'll see some people give that answer for that reason) that's way more precision than the game needs.
– Matthew Barber
May 27 at 22:42
Right; I see from your other comment that an entire byte is used for the subpixel component, it's just that only the top nibble contains values. I was otherwise imaging an exactly-the-most-awkward-possible shift by four to convert to an integer, rather than a more standard just-ignore-a-byte fixed point scheme. So I started from a false premise.
– Tommy
May 28 at 3:45
Right; I see from your other comment that an entire byte is used for the subpixel component, it's just that only the top nibble contains values. I was otherwise imaging an exactly-the-most-awkward-possible shift by four to convert to an integer, rather than a more standard just-ignore-a-byte fixed point scheme. So I started from a false premise.
– Tommy
May 28 at 3:45
@Tommy: normally when a program uses fixed-point math, you use the low
n
bits of a wider integer type. e.g. treating the low 5 bits of an int32_t
as fractional gives you a certain range (32-5 integer bits), and 5 fractional precision bits. It's certainly reasonable to guess that Mario would use a 16-bit integer with a 12:4 bit fixed-point split, but on an 8-bit CPU even 16-bit requires extended precision so I can see why there might be some advantages to having the integer part accessible separately without a byte-crossing right shift.– Peter Cordes
May 28 at 9:24
@Tommy: normally when a program uses fixed-point math, you use the low
n
bits of a wider integer type. e.g. treating the low 5 bits of an int32_t
as fractional gives you a certain range (32-5 integer bits), and 5 fractional precision bits. It's certainly reasonable to guess that Mario would use a 16-bit integer with a 12:4 bit fixed-point split, but on an 8-bit CPU even 16-bit requires extended precision so I can see why there might be some advantages to having the integer part accessible separately without a byte-crossing right shift.– Peter Cordes
May 28 at 9:24
add a comment
|
In many 8 bit games the position of the player's sprite is stored as the pixel coordinates it rests on. For many games that is adequate, but it has some limitations.
If the game only uses whole pixel coordinates then the minimum movement speed is 1 pixel. In other words the resolution of the player's speedometer is 1 pixel. They can be moving at 1 pixel per frame, or 2 pixels per frame, but not 1.5 pixels per frame.
In Super Mario Bros. that is inadequate. Mario has a lot of momentum and a major part of the game is managing it. If his speedometer had a 1 pixel/frame resolution he would feel "stiff" to control. One of the major innovations of that game, which many others soon adopted, was sub-pixel positioning and speed.
Super Mario Bros divides each pixel up into 256 sub-pixel divisions. 256 is used because it's the range of an 8 bit number, which the 8 bit Famicom / NES could handle easily. So Mario's position and speed has a resolution of 1/256th of a pixel.
When Mario reaches an obstacle the game pushes him away from it, so that he ends up outside of any solid blocks. However, the check for collisions with solid objects is only performed every other frame, so there is 1 frame where Mario can be inside a solid block before it starts pushing him. If he is moving fast enough to get deep inside the block it can end up pushing him the wrong way, allowing him to pass through solid walls. This is only possible because sub-pixel accuracy allows him to partially inside the block for two consecutive frames.
13
Just to add that, although there are 256 possible values in a byte, the subpixel mathematics is all done in multiples of 16, hence there are effectively 16 of them as per my answer.
– Matthew Barber
May 27 at 22:52
add a comment
|
In many 8 bit games the position of the player's sprite is stored as the pixel coordinates it rests on. For many games that is adequate, but it has some limitations.
If the game only uses whole pixel coordinates then the minimum movement speed is 1 pixel. In other words the resolution of the player's speedometer is 1 pixel. They can be moving at 1 pixel per frame, or 2 pixels per frame, but not 1.5 pixels per frame.
In Super Mario Bros. that is inadequate. Mario has a lot of momentum and a major part of the game is managing it. If his speedometer had a 1 pixel/frame resolution he would feel "stiff" to control. One of the major innovations of that game, which many others soon adopted, was sub-pixel positioning and speed.
Super Mario Bros divides each pixel up into 256 sub-pixel divisions. 256 is used because it's the range of an 8 bit number, which the 8 bit Famicom / NES could handle easily. So Mario's position and speed has a resolution of 1/256th of a pixel.
When Mario reaches an obstacle the game pushes him away from it, so that he ends up outside of any solid blocks. However, the check for collisions with solid objects is only performed every other frame, so there is 1 frame where Mario can be inside a solid block before it starts pushing him. If he is moving fast enough to get deep inside the block it can end up pushing him the wrong way, allowing him to pass through solid walls. This is only possible because sub-pixel accuracy allows him to partially inside the block for two consecutive frames.
13
Just to add that, although there are 256 possible values in a byte, the subpixel mathematics is all done in multiples of 16, hence there are effectively 16 of them as per my answer.
– Matthew Barber
May 27 at 22:52
add a comment
|
In many 8 bit games the position of the player's sprite is stored as the pixel coordinates it rests on. For many games that is adequate, but it has some limitations.
If the game only uses whole pixel coordinates then the minimum movement speed is 1 pixel. In other words the resolution of the player's speedometer is 1 pixel. They can be moving at 1 pixel per frame, or 2 pixels per frame, but not 1.5 pixels per frame.
In Super Mario Bros. that is inadequate. Mario has a lot of momentum and a major part of the game is managing it. If his speedometer had a 1 pixel/frame resolution he would feel "stiff" to control. One of the major innovations of that game, which many others soon adopted, was sub-pixel positioning and speed.
Super Mario Bros divides each pixel up into 256 sub-pixel divisions. 256 is used because it's the range of an 8 bit number, which the 8 bit Famicom / NES could handle easily. So Mario's position and speed has a resolution of 1/256th of a pixel.
When Mario reaches an obstacle the game pushes him away from it, so that he ends up outside of any solid blocks. However, the check for collisions with solid objects is only performed every other frame, so there is 1 frame where Mario can be inside a solid block before it starts pushing him. If he is moving fast enough to get deep inside the block it can end up pushing him the wrong way, allowing him to pass through solid walls. This is only possible because sub-pixel accuracy allows him to partially inside the block for two consecutive frames.
In many 8 bit games the position of the player's sprite is stored as the pixel coordinates it rests on. For many games that is adequate, but it has some limitations.
If the game only uses whole pixel coordinates then the minimum movement speed is 1 pixel. In other words the resolution of the player's speedometer is 1 pixel. They can be moving at 1 pixel per frame, or 2 pixels per frame, but not 1.5 pixels per frame.
In Super Mario Bros. that is inadequate. Mario has a lot of momentum and a major part of the game is managing it. If his speedometer had a 1 pixel/frame resolution he would feel "stiff" to control. One of the major innovations of that game, which many others soon adopted, was sub-pixel positioning and speed.
Super Mario Bros divides each pixel up into 256 sub-pixel divisions. 256 is used because it's the range of an 8 bit number, which the 8 bit Famicom / NES could handle easily. So Mario's position and speed has a resolution of 1/256th of a pixel.
When Mario reaches an obstacle the game pushes him away from it, so that he ends up outside of any solid blocks. However, the check for collisions with solid objects is only performed every other frame, so there is 1 frame where Mario can be inside a solid block before it starts pushing him. If he is moving fast enough to get deep inside the block it can end up pushing him the wrong way, allowing him to pass through solid walls. This is only possible because sub-pixel accuracy allows him to partially inside the block for two consecutive frames.
answered May 27 at 8:37
useruser
8,8402 gold badges16 silver badges35 bronze badges
8,8402 gold badges16 silver badges35 bronze badges
13
Just to add that, although there are 256 possible values in a byte, the subpixel mathematics is all done in multiples of 16, hence there are effectively 16 of them as per my answer.
– Matthew Barber
May 27 at 22:52
add a comment
|
13
Just to add that, although there are 256 possible values in a byte, the subpixel mathematics is all done in multiples of 16, hence there are effectively 16 of them as per my answer.
– Matthew Barber
May 27 at 22:52
13
13
Just to add that, although there are 256 possible values in a byte, the subpixel mathematics is all done in multiples of 16, hence there are effectively 16 of them as per my answer.
– Matthew Barber
May 27 at 22:52
Just to add that, although there are 256 possible values in a byte, the subpixel mathematics is all done in multiples of 16, hence there are effectively 16 of them as per my answer.
– Matthew Barber
May 27 at 22:52
add a comment
|
Thanks for contributing an answer to Retrocomputing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f11126%2fwhat-is-a-subpixel-in-super-mario-bros-and-how-does-it-relate-to-wall-clipping%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
It's not a float, it's a fixed point fractional number. A float would have an additonal field telling where the boundary between full and sub pixels is.
– Janka
May 27 at 11:58