nesdev.com
https://forums.nesdev.com/

8x16 and whatever else unreg wants to know
https://forums.nesdev.com/viewtopic.php?f=10&t=7451
Page 22 of 93

Author:  tepples [ Mon Sep 12, 2011 12:52 pm ]
Post subject: 

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.

Author:  3gengames [ Mon Sep 12, 2011 12:52 pm ]
Post subject: 

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. :)

Author:  unregistered [ Mon Sep 12, 2011 9:04 pm ]
Post subject: 

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. :)

Author:  3gengames [ Tue Sep 13, 2011 3:50 am ]
Post subject: 

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.

Author:  tokumaru [ Tue Sep 13, 2011 5:59 am ]
Post subject: 

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.

Author:  unregistered [ Wed Sep 14, 2011 7:44 pm ]
Post subject: 

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.

Author:  Kasumi [ Wed Sep 14, 2011 7:49 pm ]
Post subject: 

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.

Author:  unregistered [ Thu Sep 15, 2011 7:36 am ]
Post subject: 

Thank you Kasumi. :) I was looking for a page like this http://www.obelisk.demon.co.uk/6502/addressing.html#ZPX

Author:  tokumaru [ Thu Sep 15, 2011 8:04 am ]
Post subject: 

unregistered 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.

Author:  3gengames [ Thu Sep 15, 2011 9:31 am ]
Post subject: 

tokumaru wrote:
unregistered 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.


http://www.obelisk.demon.co.uk/6502/reference.html

Click instruction, get learned.

Author:  tokumaru [ Thu Sep 15, 2011 11:06 am ]
Post subject: 

Uh... that's the link I just said Kasumi posted... Why are you posting it again?

Author:  unregistered [ Thu Sep 15, 2011 3:35 pm ]
Post subject: 

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?

Author:  unregistered [ Fri Sep 16, 2011 12:51 pm ]
Post subject: 

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... :?

Author:  3gengames [ Fri Sep 16, 2011 1:06 pm ]
Post subject: 

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.

Author:  tokumaru [ Fri Sep 16, 2011 1:25 pm ]
Post subject: 

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.

Quote:
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.

Quote:
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.

Quote:
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).

Page 22 of 93 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/