How am I susposed to write bytes to the attribute table? The attribute table must be part of the PPU... and it sits under the nametable, I think.tokumaru wrote:This means that the program can easily write the attribute bytes straight to the attribute table
8x16 and whatever else unreg wants to know
Moderator: Moderators
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
You write the high, then low byte of the address of the attribute byte you want to update to $2006, then you write the byte you want written to that attribute byte to $2007. This must be done during vblank or while rendering is disabled.
See this for the addresses: http://wiki.nesdev.com/w/index.php/PPU_attribute_tables
See this for the addresses: http://wiki.nesdev.com/w/index.php/PPU_attribute_tables
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
I think this means that this value byte would contain the bit order bottomright,bottomleft,topright,topleft... which seems backward to me. Could it be 00000000b instead?http://wiki.nesdev.com/w/index.php/PPU_attribute_tables wrote: value = (topleft << 0) | (topright << 2) | (bottomleft << 4) | (bottomright << 6)
It is how the wiki says it is... You can't really change how the PPU works, the best you can do if a particular order of bits doesn't please you is to use a translation table, to convert from your format to the hardware format.
There's little advantage in that though, because you'd be wasting 256 bytes of ROM and some CPU time reading from the table instead of directly writing values to VRAM without any benefit other than making the attribute data easier for you to type.
There's little advantage in that though, because you'd be wasting 256 bytes of ROM and some CPU time reading from the table instead of directly writing values to VRAM without any benefit other than making the attribute data easier for you to type.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Does the wiki say this value byte contains the bit order bottomright,bottomleft,topright,topleft? (Thank you for helping me so much though tokumaru! )unregistered wrote:http://wiki.nesdev.com/w/index.php/PPU_attribute_tables wrote: value = (topleft << 0) | (topright << 2) | (bottomleft << 4) | (bottomright << 6)
Heh, I always have to check, but yeah, it seems that the attribute bits are arranged like this:
It may look kind backwards since we read numbers from left to right, but when you consider that numbers grow from right to left it's not so weird.
Code: Select all
Attribute byte:
DDCCBBAA
Attribute block:
+--+--+
|AA|BB|
+--+--+
|CC|DD|
+--+--+
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
^ I don't remember anything about pattern table bytes.
Thank you, kind sir!tokumaru wrote:Heh, I always have to check, but yeah, it seems that the attribute bits are arranged like this:
Code: Select all
Attribute byte: DDCCBBAA Attribute block: +--+--+ |AA|BB| +--+--+ |CC|DD| +--+--+
It took me a bit to understand because I've never ever thought about numbers growing from right to left... but they do!tokumaru wrote:It may look kind backwards since we read numbers from left to right, but when you consider that numbers grow from right to left it's not so weird.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Is there a possible way to make the 6 labels a part of the machine? Like, well, make them local labels that I could use. Would I have to make each label different in every file? I'd like to make an assembly object... something like jmp bg0.@MetatileCollision. Is that possible?tokumaru[color=olive], on [/color][url=http://nesdev.com/bbs/viewtopic.php?t=7451&postdays=0&postorder=asc&start=360][color=olive]page 25[/color][/url][color=olive],[/color] wrote:You could arrange the metatiles in ROM kinda like this:
Here I have 3 metatiles, each using 6 bytes. If I want to get the collision info for any given tile, I can just put its index in X or Y and read it from the MetatileCollision table.Code: Select all
MetatileTile0: .db $00, $04, $08 MetatileTile1: .db $01, $05, $09 MetatileTile2: .db $02, $06, $0a MetatileTile3: .db $03, $07, $0b MetatileCollision: .db %00001010, %01001100, $00011010 MetatilePalette: .db %10101010, %00000000, %01010101
Sweet thank you for explaining to me how to use 4bit numbers. I hope, after playing with them a bit, I'll get comfortable using them.tokumaru[color=olive], on [/color][url=http://nesdev.com/bbs/viewtopic.php?t=7451&postdays=0&postorder=asc&start=360][color=olive]page 25[/color][/url][color=olive],[/color] wrote:So, if your screenArray is an array of 16x15 metatile indexes, you can do something like this to read the collision info of any metatile:
Just as easily you now can use lda MetatileTile0, x to read the index of its top left tile, and the other tables to find out anything you want about the metatile in that position.Code: Select all
;use 2 4-bit coordinates to calculate ;how far in the array the metatile is lda metatileY asl asl asl asl ora metatileX tax ;get the index of the metatile lda screenArray, x tax ;get its collision information lda MetatileCollision, x
I didn't really understand the question... Why would you JMP to a data table? That would most likely crash the program!unregistered wrote:Is there a possible way to make the 6 labels a part of the machine? Like, well, make them local labels that I could use. Would I have to make each label different in every file? I'd like to make an assembly object... something like jmp bg0.@MetatileCollision. Is that possible?
Do you want to use different data for each level or something like that? If that's the case, then the answer is the indirect indexed addressing mode (i.e. LDA ($XX), Y). With that addressing mode you use pointers to define the tables that will be read, and you can alter the pointers as much as you want.
For example, you could have a different name for each collision table (or whatever table you want), and then make a table with all the addresses:
Code: Select all
MetatileCollisionAdresses:
.dw MetatileCollisionLevel1, MetatileCollisionLevel2, MetatileCollisionLevel3
Code: Select all
lda LevelIndex ;get the level's index
asl ;multiply by 2 because each address is 2 bytes
tax ;use that as an index into the table of addresses
lda MetatileCollisionAdresses+0, x ;copy the low byte
sta MetatileCollision+0
lda MetatileCollisionAdresses+1, x ;copy the high byte
sta MetatileCollision+1
Code: Select all
;get collision information
lda (MetatileCollision), y
There are lots of ways to use 4-bit numbers. In this case it was convenient to use 4-bit values because 4 bits are enough to represent the metatile coordinates inside a single screen.thank you for explaining to me how to use 4bit numbers.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
hahaha hahaha hahaha (laughing at myself) hahaha ok hahaha! No I shouldn't have typed JMP... ... ...should have gone with lda bg0.@MetatileCollision, 3. I was trying to say I would make an assembly object named bg0. And then I would try to access the third entry of its MetatileCollision array (labeled @MetatileCollision). I wanted to use @MetatileCollision because it is a local label/variable and then hopefully I could leave each file with a label named @MetatileCollision. Or would I need to have a unique label name in each .NAC (nametable & collision) file? We would replace each .NAM file with a .NAC file.tokumaru wrote:I didn't really understand the question... Why would you JMP to a data table? That would most likely crash the program!unregistered wrote:Is there a possible way to make the 6 labels a part of the machine? Like, well, make them local labels that I could use. Would I have to make each label different in every file? I'd like to make an assembly object... something like jmp bg0.@MetatileCollision. Is that possible?
tokumaru, thank you so very much for your explanation of the indirect indexed addressing mode and for the code examples. : )
tokumaru wrote:There are lots of ways to use 4-bit numbers. In this case it was convenient to use 4-bit values because 4 bits are enough to represent the metatile coordinates inside a single screen.thank you for explaining to me how to use 4bit numbers.
Ah yes! That's amazing!
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Ok here's^ 3 metatiles,each using 6 bytes. Does this mean each new metatile will use 6 bytes? It's confusing trying to complete one .NAC (Nametable & Collision) file. For the attribute bytes we have 64 bytes (8 * 8 ). For the Collision part we will have 240 bytes (16 * 15). So 64 != 240.......... My solution is to increase our metatile size to 32x32. Then we would have 64 bytes for both of them, I think. But, then it's confusing to think about, for me at least. I need some help. Dear God, please help me. Thank you God! Amen.unregistered wrote:tokumaru[color=olive], on [/color][url=http://nesdev.com/bbs/viewtopic.php?t=7451&postdays=0&postorder=asc&start=360][color=olive]page 25[/color][/url][color=olive],[/color] wrote:You could arrange the metatiles in ROM kinda like this:
Here I have 3 metatiles, each using 6 bytes. If I want to get the collisionCode: Select all
MetatileTile0: .db $00, $04, $08 MetatileTile1: .db $01, $05, $09 MetatileTile2: .db $02, $06, $0a MetatileTile3: .db $03, $07, $0b MetatileCollision: .db %00001010, %01001100, $00011010 MetatilePalette: .db %10101010, %00000000, %01010101
info for any given tile, I can just put its index in X or Y and read it from the MetatileCollision table.