Page 1 of 109

8x16 and whatever else unreg wants to know

Posted: Wed Feb 02, 2011 12:11 pm
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? :?

Posted: Wed Feb 02, 2011 1:04 pm
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?

Posted: Wed Feb 02, 2011 1:33 pm
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.

Posted: Wed Feb 02, 2011 1:34 pm
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!

Posted: Wed Feb 02, 2011 2:19 pm
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?

Posted: Wed Feb 02, 2011 2:41 pm
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.

Posted: Wed Feb 02, 2011 3:37 pm
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

Posted: Wed Feb 02, 2011 4:51 pm
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.

Posted: Wed Feb 02, 2011 4:53 pm
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.

Posted: Thu Feb 03, 2011 6:13 am
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.

Posted: Tue Feb 08, 2011 5:32 pm
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. :)

Posted: Tue Feb 08, 2011 6:11 pm
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.

Posted: Tue Feb 08, 2011 7:15 pm
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?

Posted: Tue Feb 08, 2011 7:41 pm
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.

Posted: Tue Feb 08, 2011 10:30 pm
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.