8x16 and whatever else unreg wants to know
Moderator: Moderators
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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
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. It helped me think! Thank you also 3gengames... I think I understand now; it's up to me to make these choices.
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.
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.
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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
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.
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.
http://www.obelisk.demon.co.uk/6502/reference.htmlunregistered wrote:I can't find my list of addressing modes info
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.
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Thank you Kasumi. 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.unregistered wrote:I was looking for a page like this http://www.obelisk.demon.co.uk/6502/addressing.html#ZPX
http://www.obelisk.demon.co.uk/6502/reference.htmltokumaru wrote: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.unregistered wrote:I was looking for a page like this http://www.obelisk.demon.co.uk/6502/addressing.html#ZPX
Click instruction, get learned.
-
- 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
What?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,
That's right, 4x more tiles means 4x more memory. Thanks 3gengames! That's quite alotlotlotlotlotlotlotlotlotlotlotlotlotlot of space... maybe I have a solution.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.
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! Though........., I guess maybe not. But, I can hope.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.
ha! I'm not even sure what the attribute bytes do...tokumaru wrote:On the NES, 32x32-pixel blocks are particularly interesting, because that's the size of the area affected by each attribute byte.
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.unregistered wrote:What?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,
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.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.
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.There are rocks that need to be destroyed... Could those be sprites instead of counting as one of the collision blocks?
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).ha! I'm not even sure what the attribute bytes do...