8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Super Mario Bros. decodes 16x208-pixel slices of the map to a 13-byte-long column buffer, where each byte represents one metatile. It passes this column to the screen drawing code (which prepares packets to be sent to the nametables), and then it copies the column to a 32x13-metatile buffer that holds a sliding window on the decoded map. One way you could use the data in such a window would be to give each metatile some properties, such as whether it can be walked through, and then use that map in your collision code.
Last edited by tepples on Mon Sep 12, 2011 12:55 pm, edited 1 time in total.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

I believe it's another thing that's just any way you want to do it. But collision tables can't be that big, so maybe leave uncompressed. Whatever you feel like doing. :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Ok, one more question. Would it be possible to make the game using a regular 1x1 tile size of 8x8 pixels? It would take twice as much memory as yall's recomendation of using a 2x2 tile metatile of 16x16 pixels... like SMB uses. Thank you, tepples, for that SMB info. :D It helped me think! :) Thank you also 3gengames... I think I understand now; it's up to me to make these choices. :)
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Well, 16x16 is used because 1 tile is SMALL. And, then, most tiles you won't be able to put because of color differences, and it'll take 4x more memory to do it probably, because it's 4x more tiles. I think 16x16 tiles should be used pretty much always, unless you use MMC5 and can get single colored tiles. But even then it may be a waste. It'd certainly be waste of a mapper.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

No matter what size you use, you have to decode the blocks all the way down to the 8x8 tiles for rendering, so you might as well go that deep for collision too, it's your choice. What doesn't make sense is not using any kind of compression (larger blocks, RLE, anything), because each screen would take an insane amount of ROM (with NROM you'd hardly be able to store more than 16 screens).

Working with bigger blocks sure makes the levels more compact, and easier to handle because there's less data to work with. On the NES, 32x32-pixel blocks are particularly interesting, because that's the size of the area affected by each attribute byte.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

I can't find my list of addressing modes info. :( I just want to find out what each mode does and how I could use them. 6502.txt is not helpful for me.. neither is the Addressing Modes part of the Programming Manual's Appendixes. Do you know of another list of addressing modes info?

Sorry, I've been working on this collision detection for a good amount of time... I'm not ready to reply to yall tokumaru and 3gengames.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi »

unregistered wrote:I can't find my list of addressing modes info
http://www.obelisk.demon.co.uk/6502/reference.html

That shows which addressing modes are available for each instruction.

If you need something more specific than that, then I'm not quite sure what you're asking.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Thank you Kasumi. :) I was looking for a page like this http://www.obelisk.demon.co.uk/6502/addressing.html#ZPX
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

unregistered wrote:I was looking for a page like this http://www.obelisk.demon.co.uk/6502/addressing.html#ZPX
This page describes how the various addressing modes work, but the full reference linked by Kasumi shows which addressing modes can be used by each instruction. You might have noticed that some combinations are not possible.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

tokumaru wrote:
unregistered wrote:I was looking for a page like this http://www.obelisk.demon.co.uk/6502/addressing.html#ZPX
This page describes how the various addressing modes work, but the full reference linked by Kasumi shows which addressing modes can be used by each instruction. You might have noticed that some combinations are not possible.
http://www.obelisk.demon.co.uk/6502/reference.html

Click instruction, get learned.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Uh... that's the link I just said Kasumi posted... Why are you posting it again?
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Found it!! :D It says "Assembly in One Step" at the top of the first page. This is my favorite explanation of how each addressing mode works.
edit: How do you keep your collision info while you are scrolling?
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

3gengames wrote:Well, 16x16 is used because 1 tile is SMALL. And, then, most tiles you won't be able to put because of color differences,
What? :?
3gengames wrote: and it'll take 4x more memory to do it probably, because it's 4x more tiles. I think 16x16 tiles should be used pretty much always, unless you use MMC5 and can get single colored tiles. But even then it may be a waste. It'd certainly be waste of a mapper.
That's right, 4x more tiles means 4x more memory. Thanks 3gengames! :D That's quite alotlotlotlotlotlotlotlotlotlotlotlotlotlot of space... maybe I have a solution. :)
tokumaru wrote:No matter what size you use, you have to decode the blocks all the way down to the 8x8 tiles for rendering, so you might as well go that deep for collision too, it's your choice. What doesn't make sense is not using any kind of compression (larger blocks, RLE, anything), because each screen would take an insane amount of ROM (with NROM you'd hardly be able to store more than 16 screens).

Working with bigger blocks sure makes the levels more compact, and easier to handle because there's less data to work with.
ok I've beeen thinking. Maybe I could use 2x2tiles for collision and break each byte up into 4 parts..... 1 part for each tile. That may work... 4 different collision blocks. There are rocks that need to be destroyed... Could those be sprites instead of counting as one of the collision blocks? Cause if so, that'd be sweet! :D Though........., I guess maybe not. But, I can hope. :)
tokumaru wrote:On the NES, 32x32-pixel blocks are particularly interesting, because that's the size of the area affected by each attribute byte.
ha! I'm not even sure what the attribute bytes do... :?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

In games that use 16x16 pixel blocks, or 2x2 tiles, you can put ANY block there. But if you do a 1 tile per byte way, you won't be able to put pretty much any type of tile except one of the same colors, making it difficult to have an advantage at all of not using 2x2 tiles.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

unregistered wrote:
3gengames wrote:Well, 16x16 is used because 1 tile is SMALL. And, then, most tiles you won't be able to put because of color differences,
What? :?
He said that because the NES uses the same palette for all tiles in a 16x16-pixel area. If you try to put tiles that use different palettes in the same 16x16-pixel area you'll have problems.
ok I've beeen thinking. Maybe I could use 2x2tiles for collision and break each byte up into 4 parts..... 1 part for each tile. That may work... 4 different collision blocks.
That would give you 4 different collision attributes... In my opinion that's too little, but could work in a simple game. Two types are mandatory: "empty" and "solid", and you have 2 left to choose from "water", "lava" (or anything that hurts), "platform" (only solid at the top), "conveyor belt", and so on. If your game can get away with only 4 types, that's OK, but many games need more.
There are rocks that need to be destroyed... Could those be sprites instead of counting as one of the collision blocks?
If you don't need many of them aligned horizontally, then yes, using sprites would be more convenient. If there are too many destructible blocks though, the sprite limitations will get in the way.
ha! I'm not even sure what the attribute bytes do... :?
Attribute bytes select which palettes are used for the background tiles. Each byte defines the 4 palettes used in a 32x32-pixel area, one palette for each 16x16-pixel area. The good thing about using 32x32-pixel blocks is that you don't have to do any sort of attribute byte manipulation, you can just copy attribute bytes straight to the attribute tables (as long as you don't scroll vertically).
Post Reply