Talk:PPU attribute tables: Difference between revisions
(Created page with '- Even if the NES does not display a picture of 256x256 pixels, it's technically possible to do. I studied the Mega Man II gfx engine a few years ago, and my level editor renders…') |
No edit summary |
||
| Line 1: | Line 1: | ||
- Even if the NES does not display a picture of 256x256 pixels, it's technically possible to do. I studied the Mega Man II gfx engine a few years ago, and my level editor renders a full picture of 256x256 pixels. In other words, even if the NES cuts off 2xF8 by half, it's still technically possible to render it. | - Even if the NES does not display a picture of 256x256 pixels, it's technically possible to do. I studied the Mega Man II gfx engine a few years ago, and my level editor renders a full picture of 256x256 pixels. In other words, even if the NES cuts off 2xF8 by half, it's still technically possible to render it. | ||
== Attribute Equation Order == | |||
It may be a little better to have this: | |||
Code: | |||
value = (topleft << 0) | (topright << 2) | (bottomleft << 4) | (bottomright << 6) | |||
ordered like this: | |||
Code: | |||
value = (bottomright << 6) | (bottomleft << 4) | (topright << 2) | (topleft << 0) | |||
Obviously the result is the same, but the second one keeps the order they'd be in the byte after the actual bit shifts. Bottomright would be in the far left of the byte, etc. It makes it easier to quickly glance and see the order. Just a thought, since I don't know if the current way is the standard way of representing bit shift equations or something. | |||
--[[User:Kasumi|Kasumi]] 02:24, 27 September 2011 (UTC) | |||
Revision as of 02:24, 27 September 2011
- Even if the NES does not display a picture of 256x256 pixels, it's technically possible to do. I studied the Mega Man II gfx engine a few years ago, and my level editor renders a full picture of 256x256 pixels. In other words, even if the NES cuts off 2xF8 by half, it's still technically possible to render it.
Attribute Equation Order
It may be a little better to have this:
Code: value = (topleft << 0) | (topright << 2) | (bottomleft << 4) | (bottomright << 6)
ordered like this:
Code: value = (bottomright << 6) | (bottomleft << 4) | (topright << 2) | (topleft << 0)
Obviously the result is the same, but the second one keeps the order they'd be in the byte after the actual bit shifts. Bottomright would be in the far left of the byte, etc. It makes it easier to quickly glance and see the order. Just a thought, since I don't know if the current way is the standard way of representing bit shift equations or something.
--Kasumi 02:24, 27 September 2011 (UTC)
