Talk:PPU attribute tables: Difference between revisions
(→Всё для любящих родителей: new section) |
m (Reverted edits by 94.27.70.240 (talk) to last revision by Kasumi) |
||
Line 15: | Line 15: | ||
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. | 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) | --[[User:Kasumi|Kasumi]] 02:24, 27 September 2011 (UTC) | ||
Revision as of 22:27, 29 June 2013
- 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:
value = (topleft << 0) | (topright << 2) | (bottomleft << 4) | (bottomright << 6)
ordered like this:
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)