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

unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

8x16 and whatever else unreg wants to know

Post by unregistered »

My sister made good sprites art for an image of 8x16 pixels... but later, after playing pacman on nes, i noiced that the ghost looks like it fills a space of 2 8x16 pixel sprites... and then thought maybe every nes-pixel equals a group of 4 cpu-pixels. Am I kindof right? I searched and found one of yall talking about a 16x16 title.. but normal sprites are 8x8... right? :?
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

ok.. in this thread Bregalad helped me learn that a 16x16 pixel image is a meta-sprite. So are the ghosts, in nes pacman, meta-sprites?
Wave
Posts: 110
Joined: Mon Nov 16, 2009 5:59 am

Post by Wave »

unregistered wrote:ok.. in this thread Bregalad helped me learn that a 16x16 pixel image is a meta-sprite. So are the ghosts, in nes pacman, meta-sprites?
Yes, almost any game sprite-object is a metasprite due to the 8x8 or 8x16 limitation of the hardware sprites on the nes.
Ian A
Posts: 115
Joined: Sat Feb 27, 2010 8:32 am
Location: Maine

Post by Ian A »

They can be either 8x8 or 8x16.

You can change the sprite size setting a certain bit in one of the PPU registers. ($2000)

EDIT: Oops! Beaten to the punch!
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Thank you both for your answers! :) I thought a regular nes sprite would be 16x16 because 1) Mario is 16x16, i think, and 2) In the 1.31 NESst when you try to apply a chosen 00 or 01 or 10 or 11 pallet to the nametable it only allows a space of 16x16 to be colored. And I know yall suggested lots of fixes and things so then: why does the nes not allow a smaller 8x8 tile to be a certian color when 8x8 is the size of a small sprite? Why is applying a pallet limited to a 16x16 space?
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

The reason for the background being in 16x16 squares is probably because the RAM probably cost more and they didn't really need it, since specific 8x8 tiles are probably too small to vary colors anyway with the background.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

Then, are sprites allowed 8x8 pallet access? Thanks for your help. :)
It seems restrictive to limit the background to 16x16. But yes, maybe it's ok. :) Did they improve pallet access for backgrounds on the snes hardware? By "improve" i mean enable 8x8 pallet application access
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames »

Not sure, but I know they added a TON of crap to it. I think they have a 256 color mode for backgrounds? So tile pallets are basically useless with that many color options, if I am correct.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Sprites are different from backgrounds. For the background, palettes are applied to 16x16 pixel areas (except for a special video mode available through the MMC5 mapper, which allows palettes to be applied to individual tiles), but each sprite can use a different palette. If the PPU is configured to use 8x8 sprites, each 8x8 square can use a different palette, if it's configured to use 8x16, each 8x16 rectangle can use a different palette.

Usually, game objects are indeed represented by multiple hardware sprites, because most of them are larger than 8x8 or 8x16 pixels. Most games have some kind of meta-sprite system, with tables indicating how many hardware sprites are necessary to form a game sprite, how they are positioned, the palette each one uses, and so on. Only bullets and other small objects use a single hardware sprite.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

3gengames wrote:Not sure, but I know they added a TON of crap to it. I think they have a 256 color mode for backgrounds? So tile pallets are basically useless with that many color options, if I am correct.
A 256-color background means fewer background layers and fewer tiles that fit in video RAM.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Post by unregistered »

tokumaru wrote:Usually, game objects are indeed represented by multiple hardware sprites, because most of them are larger than 8x8 or 8x16 pixels. Most games have some kind of meta-sprite system, with tables indicating how many hardware sprites are necessary to form a game sprite, how they are positioned, the palette each one uses, and so on. Only bullets and other small objects use a single hardware sprite.
Thank you so much for your extra helpful reply! :D
What are the limits of the meta-sprite system? I remember reading about how Punchout!! required special hardware to draw/animate the humungus enemies. Like what is the largest meta-sprite we could use without improving cart hardware? (Question is from my artist!) Also... about scrolling; what are possible width and height/depth for scrolling... guess she is wondering how much of a level can we do? Mario 3 has the type of scrolling she is wanting. :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

unregistered wrote:What are the limits of the meta-sprite system?
That depends on the game. There is no standard for that, and each game has its own implementation of a meta-sprite system designed according to its specs.

For example, some systems might require that all sprites are arranged in a grid and use the same palette, so that the meta-sprite definitions will use less ROM space (no need to store the coordinates and attributes of each sprite). In my game I have a very versatile system, where each sprite's position is relative to the object's coordinates and has its own attributes. As a result, the definitions are larger.
I remember reading about how Punchout!! required special hardware to draw/animate the humungus enemies.
I'm not aware of that. The mapper used in that game doesn't have any features that would increase the sprite capacity of the system. What you can do sometimes is draw game objects using background tiles, if the background is flat enough. The ring is just a solid color, so it's possible that one of the fighters is actually drawn with background tiles rather than sprites, but I didn't check.
Like what is the largest meta-sprite we could use without improving cart hardware? (Question is from my artist!)
You are the programmer, so you're the one that should have the answer!

Truth is that it's impossible for mappers to increase the amount of displayed sprites (at most they can provide you with a larger amount of tiles to pick from), because all the sprite logic and OAM is internal to the PPU, meaning that external hardware can't mess with it. So no matter the kind of system you code, you'll always be limited by the same hardware rules: 8 sprites per scanline, 64 sprites screen.

So the largest meta-sprite is either 64x64 pixels (in 8x8 mode) or 64x128 pixels (in 8x16 mode). I wouldn't make such a huge sprite though, because there wouldn't be any sprites left for other game objects.
Also... about scrolling; what are possible width and height/depth for scrolling... guess she is wondering how much of a level can we do?
Again, this is up to the programmer. Levels can be as large as you want, it all comes down to the memory necessary to store the level maps. Depending on the type of compression you use, your maps will occupy more or less ROM space. If you implement a system where levels are generated randomly, you could have an endless level.

Each game's engine handles the scrolling differently. Some decompress whole levels to RAM (needs too much RAM, not recommended on the NES unless you have extra memory on the cart), some decompress the levels progressively so that only the visible area is in RAM, and some even read map data directly from the ROM, so they don't have to worry about wasting too much RAM, but the compression schemes used for this don't usually compress as well, so the levels need more ROM space.
Mario 3 has the type of scrolling she is wanting. :)
You have to select the kind of compression that will work best with the kind of levels you want to make, also taking into consideration the decoding process (i.e. how you are going to read the map data, for drawing and for collision with the objects).

SMB3 has some limitations, like the height of the level, which is 2 NES screens tall (minus the status bar), and color glitches at the right of the screen because of the way it uses the name tables (horizontal mirroring). Status bars also affect the way you implement the scrolling if you plan on scrolling vertically (which I assume you do), so I need to know whether you want a status bar in your game and whether your levels can be taller than 2 screens before I suggest the optimal solution for your case.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

tokumaru wrote:Truth is that it's impossible for mappers to increase the amount of displayed sprites (at most they can provide you with a larger amount of tiles to pick from), because all the sprite logic and OAM is internal to the PPU
Unless you put an auxiliary PPU on the cartridge that renders sprites to background tiles. Super Game Boy, for example, does this.
If you implement a system where levels are generated randomly, you could have an endless level.
This has been done even on the lowly Atari 2600: see River Raid.
some even read map data directly from the ROM, so they don't have to worry about wasting too much RAM, but the compression schemes used for this don't usually compress as well, so the levels need more ROM space.
These include multilayer metatile engines like those of Mega Man series, Blaster Master, Sonic 2 for Genesis, and your Sonic clone, right?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

tepples wrote:Unless you put an auxiliary PPU on the cartridge that renders sprites to background tiles. Super Game Boy, for example, does this.
True, but the 4-colors per tile limitation severely reduces the possibilities. If the NES had a 4bpp mode, like the SMS for example, this would be a very interesting mapper feature. The SMS can't have this though, since the cart has no direct access to the video memory.
This has been done even on the lowly Atari 2600: see River Raid.
Exactly. Also Pitfall, I think. Many Atari games had to fit in 4KB of ROM, so since there wasn't much space for level maps the solution was to generate them in real time. If you always start with the same seed, the same levels will be generated every time.
These include multilayer metatile engines like those of Mega Man series, Blaster Master, Sonic 2 for Genesis, and your Sonic clone, right?
Yes, but Sonic on the Genesis actually uses the data in RAM, because it's compressed even further in the ROM.
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Post by Gilbert »

tokumaru wrote: True, but the 4-colors per tile limitation severely reduces the possibilities. If the NES had a 4bpp mode, like the SMS for example, this would be a very interesting mapper feature. The SMS can't have this though, since the cart has no direct access to the video memory.
At least, I think the Wide-boy (link to Chris' page) sort of use this to draw the whole gameboy display with backgrounds (but then of course the gameboy only has 4 different shades in total, even after combining the sprites with the background plane, and so this works), and it even needs to change the tiles mid-screen to display a whole frame (I wonder why this is needed, as 160x144 occupies only 360 8x8 tiles and you can just change the tile page used for background midscreen when it uses up 256 of them, instead of rewriting the memory, and there're still enough space for stuff such as border graphics, etc.). That isn't much useful for FC/NES game making though, as the WB is just the gameboy hardware in whole.
Post Reply