Once you have more than 8 KiB, you're either going to be using RAM for CHR, and so there's no need to have any specific size limitation; or else the smallest cheapest available ROM now is 128 KiB. So once you add any mapper at all, don't feel like you need to hold back.
What kind of memory limitations does the NES have for graphics? Because it has the CHR rom like the Neo Geo, could you actually have better animation on the NES than on the SNES with a special mapper?
With a suitable mapper, you could probably feed a nearly VHS quality video signal into the NES PPU.
Yes. Well, sorta. It's still only a 2bpp plane, and that's a bigger thing in terms of visual richness than changing total content.
The late-stage advanced mappers often provided eight independent 1KiB banks to control this, allowing for (e.g.) a quarter of tiles to be animated while half were used for fixed background things and another quarter could change as the level progressed, as well as grouped animations on random subsets of sprites.
But between the 6502 being an 8-bit microcomputer, and memory and bandwidth on the NES being limited, there was very little pressure to go past 256 KiB of data.
Espozo wrote:
lidnariq wrote:
Once you have more than 8 KiB, you're either going to be using RAM for CHR, and so there's no need to have any specific size limitation; or else the smallest cheapest available ROM now is 128 KiB. So once you add any mapper at all, don't feel like you need to hold back.
What kind of memory limitations does the NES have for graphics? Because it has the CHR rom like the Neo Geo, could you actually have better animation on the NES than on the SNES with a special mapper?
That's how After Burner can change the entire background so quickly (albeit that's swapping the nametable rather than the tiles).
For a more straight example,
the beginning of stage 7-1 in Return of the Joker at 17:38. Admittedly that's just changing a few tiles that happen to be spread everywhere, but that part definitely looks a lot more animated than the vast majority of 2D games from later generations.
EDIT: also, this can be useful for making parallax =P
You know, I was bored so I converted these graphics to work on the NES. I think you can guess what game it is from.
Attachment:
chr rom graphics.png [ 11.17 KiB | Viewed 4201 times ]
Working with the NES's limited color palette is extremely annoying. If there are 64 different slots for colors, why are there several ones left black? You know, I find it a little humorous that the Atari 2600's color palette is over twice as large as the NES.
Espozo wrote:
Working with the NES's limited color palette is extremely annoying. If there are 64 different slots for colors, why are there several ones left black?
Because there are only 12 possible hues, plus one column of grays. This leaves a bunch of unused (black) entries.
Two columns of gray and ten color hues. But yeah I really wonder why didn't they try to extend it so that all 16 columns were covered instead of just 14 (also the lack of yellow is annoying).
Sik wrote:
But yeah I really wonder why didn't they try to extend it so that all 16 columns were covered instead of just 14
Cost. In 1983, each gate on an integrated circuit cost a lot more than it does in 2015.
Quote:
(also the lack of yellow is annoying).
That's an NTSC problem if anything. Pure yellow is out of NTSC's gamut.
Sik wrote:
ten color hues.
<pedantic>Twelve.</pedantic>
Quote:
why didn't they try to extend it so that all 16 columns were covered instead of just 14
Perhaps because the 2600's analog delay line was deemed insufficiently precise.
Or maybe because the NES is very clearly inspired by the Colecovision, and that used a 2×NTSC crystal, divided in two to make the Z80 system clock, and then multiplied by 3 to make the TMS9928A clock. The TMS9928A generates component natively, but has a very fixed palette (15 colors including white and black), and requires an external IC to convert to modulated video. An obvious simplification (and cost reduction) is to avoid the awkward analog frequency doubler and just use some multiple of 3×NTSC to get both the desired horizontal pixel count and colorburst frequency.
At that point, they could have used the 2600's analog delay line, but doing the same thing digitally is simpler and doesn't require any tuning or on-die capacitors.
On the other hand, I think that it should have been easy to extend the palette in the other direction (the two missing MSBs), though, with more options for saturation and/or brightness.
tepples wrote:
Cost. In 1983, each gate on an integrated circuit cost a lot more than it does in 2015.
Isn't the value just fed to a 16 step counter though, which is then used to generate part of the analog signal? I'd imagine that the analog part would have been feasibly enough to tweak that the range would fall within something that covered all 16 columns.
Then again discussing a hardware decision that was decided over 30 years ago is stupid...
tepples wrote:
That's an NTSC problem if anything. Pure yellow is out of NTSC's gamut.
There isn't even a color similar to yellow though, the closest to it is a light orange that doesn't pass for yellow no matter what (pure red isn't there either but at least there's a color close enough to pass for it).
lidnariq wrote:
<pedantic>Twelve.</pedantic>
Wait... *headdesk* I can't do math (apparently I substracted two twice)
Sik wrote:
tepples wrote:
Cost. In 1983, each gate on an integrated circuit cost a lot more than it does in 2015.
Isn't the value just fed to a 16 step counter though, which is then used to generate part of the analog signal?
It can be thought of as a 12-step counter, as the master clock rate is six times the color burst rate. The counter ticks on both rises and falls.
Quote:
tepples wrote:
That's an NTSC problem if anything. Pure yellow is out of NTSC's gamut.
There isn't even a color similar to yellow though, the closest to it is a light orange that doesn't pass for yellow no matter what
Which yellow is in Dr. Mario?
Screenshot by mobygames
Mednafen debugger: PPU memory wrote:
Code:
3F00: 0F 31 2C 0A 0F 32 28 0A 0F 28 15 21 0F 00 22 0A
3F10: 0F 37 30 18 0F 28 15 0F 0F 28 15 21 0F 28 21 0F
Looks like 28. The use of blue as the "highlight" on it seems to help.
For "fun", edit sprite and BG palette entry 2 to 0F 28 28 28.
Espozo wrote:
You know, I was bored so I converted these graphics to work on the NES. I think you can guess what game it is from.
Legend of Mana ?
By the way this picture is extremely good looking.
Quote:
If there are 64 different slots for colors, why are there several ones left black?
None are "left black", there is just this transparent colour that repeats every first colour of every palette.
Bregalad wrote:
Quote:
If there are 64 different slots for colors, why are there several ones left black?
None are "left black", there is just this transparent colour that repeats every first colour of every palette.
He's not talking about the palette RAM entries, but rather the table of possible colours in the PPU.
Well, there is a great explanation (document?) by Kevin Horton about how the PPU generates its colour signals in the NTSC domain. Colour $X0 is the high voltage for each brightness level, and the corresponding $XD the low voltage, and the PPU makes the colours in between by oscillating between the two voltages with different phases. Quite smart and interesting. Maybe Nintendo (Ricoh) could have added a couple more hues in there, but then the hues wouldn't rotate cleanly at 30 degrees(?) for each hue setting.
Bleh, looking at the palette 28 looks ochre instead =/ Dammit context.
Bregalad wrote:
Espozo wrote:
You know, I was bored so I converted these graphics to work on the NES. I think you can guess what game it is from.
Legend of Mana ?
I always thought that the worst thing about the NES's color palette is how vibrant it is. For example, the light brown is extremely yellow and it makes making beach sand impossible. It's also near impossible to make a "dollar bill" green, because there is no middle ground between extremely green and grey. The commodore 64 color palette is only 16 entries long, and although it is duller than the NES's, I've seen pictures where they were able to smoothly transition colors and use a color around different colors to give the impression that there are more colors total than there really are. Watch this video:
https://www.youtube.com/watch?v=EAUprwhQTZY
Espozo wrote:
Attachment:
chr rom graphics.png
Looks decent, considering all the limitations. Nice use of gray as an intermediary color. I wonder if dithering could improve this a bit.
I didn't bother checking: are you respecting the 16x16-pixel attribute grid here? Or is this an MMC5 ExRAM mock-up, with 8x8-pixel attribute areas? What about tile count, are you respecting any sort of limitation?
tokumaru wrote:
I didn't bother checking: are you respecting the 16x16-pixel attribute grid here? Or is this an MMC5 ExRAM mock-up, with 8x8-pixel attribute areas? What about tile count, are you respecting any sort of limitation?
I'm using 8x8-pixel attribute areas. and about tile count, I was not respecting any sort of limitation. I thought it had been said that you had pretty much infinite tiles to use on the NES if you had a mapper that could supply it. In fact, I thought I remember someone saying you could have a different palette for every 8x1 pixel area, even though I didn't bother because that seems pretty hard to work with.
Espozo wrote:
someone saying you could have a different palette for every 8x1 pixel area,
Me (among many others). Requires new hardware, though, although the InviteNES is apparently supporting it for the main menu. I do have a demo with a separate palette for every
16x1 pixel area, using mapper 19.
Espozo wrote:
I'm using 8x8-pixel attribute areas. and about tile count, I was not respecting any sort of limitation. I thought it had been said that you had pretty much infinite tiles to use on the NES if you had a mapper that could supply it.
Yes, what you have there can be accomplished with an MMC5. In addition to 8x8-pixel attribute areas, it allows access to 16384 (i.e. 256KB) tiles at once.
Quote:
In fact, I thought I remember someone saying you could have a different palette for every 8x1 pixel area, even though I didn't bother because that seems pretty hard to work with.
It's technically possible, but AFAIK nobody ever implemented this feature in an actual mapper. It has been proven to work on real hardware, but those were just tests.
tokumaru wrote:
it allows access to 16384 (i.e. 256KB) tiles at once.
I can't help but find it funny that the NES, with chip or not, can have access to 4x the graphics memory of the SNES. (So much for "Super".
) The way I thought of Metal Slug was because both the Neo Geo and the NES both use chr rom instead of vram. Didn't someone say using vram is less expensive than using chr rom, because I don't see how. If it is, why did Nintendo decide to go the cheaper route when they made the SNES, seeing that they didn't with the NES? I just thought that if memory was so expensive back then, than they would have actually saved money if they didn't have any vram and just had a bus that went from the cartridge to the PPUs or something.
RAM built in to the console is cheaper in aggregate, because it only has to be paid for once, rather than a new chunk of memory in every cartridge.
Consider three points against reliance on CHR ROM on the Super NES:
- As lidnariq ninja'd me, if there's CHR memory on all carts, the cost has to be paid for each cart. On the other hand, the original plan was for every Super NES to to include a DSP-1, but that was cut. And when Sega tried a console upgrade that "only has to be paid for once", the 32X went over like 99 lead balloons.
- Wider edge connectors need tighter (more expensive) tolerances.
- Even with CHR ROM, it would still need ~16K of RAM for the mode 7 nametable. And by the time you have that much RAM in the bill of materials, you might as well make it a RAM-based system.
Good points. I still find it strange Nintendo went all the way with the NES and not the SNES, but I guess it has to do partially with, like you said, the Mode 7 nametable. I always thought that vram was the thing that brought the SNES back the most, especially compared to something like the Neo Geo. As previously discussed, I don't think the Neo Geo laps the SNES on anything really, except for maybe the animation. Donkey Kong Country has very smooth animation, but it doesn't animate objects that are half as large as the screen...
Memory prices change very quickly, so I bet Nintendo was counting on that when they designed the NES the way they did. Including more RAM on the system would have significantly increased its price back when it was designed, but a couple of years later they'd release games with not only large PRG and CHR ROMs, but also 8KB of RAM, which was way more than there was inside the console itself. For some reason, this reasoning didn't work with the SNES.
The NES can still be wired from the cartridge to use its internal VRAM for tiles (making it possible for carts to only contain a PRG-ROM and a CIC, no CHR), but since there are only 2KB of VRAM, and 1KB has to be used for name and attribute tables, you end up with only 64 tiles for everything. If you reduce the screen size a bit you might be able to steal some of the NT/AT RAM for extra tiles. I still think this would make a good theme for a coding compo.
tokumaru wrote:
The NES can still be wired from the cartridge to use its internal VRAM for tiles (making it possible for carts to only contain a PRG-ROM and a CIC, no CHR), but since there are only 2KB of VRAM, and 1KB has to be used for name and attribute tables, you end up with only 64 tiles for everything. If you reduce the screen size a bit you might be able to steal some of the NT/AT RAM for extra tiles. I still think this would make a good theme for a coding compo.
That's called mapper 218. If all four palettes are the same, you can reuse the memory normally used for the attribute table to make up extra tiles instead. Sprites can still use different colors though.
I'm surprised that nobody mentioned the obvious point that no NES game ever made use of that much CHR-ROM simultaneously. Also I'm not aware of any mapper that lets you map each tile individually (is there any in a licensed game?), so that imposes limits on how you can use the memory.
Also on the SNES: it has enough memory that you can fill the entire screen with unique tiles (at least in 4bpp mode).
Sik wrote:
Also I'm not aware of any mapper that lets you map each tile individually (is there any in a licensed game?)
MMC5 in ExGrafix mode comes very close, with 14-bit tile indices for up to 16384 different possibilities for each tile in a scene. This allows use of a quarter megabyte of background tiles at once, which should be enough if you have separate 256K banks of tiles for sprites, the status bar, Chinese characters for dialogue, the menu system, other levels, etc.
Quote:
Also on the SNES: it has enough memory that you can fill the entire screen with unique tiles (at least in 4bpp mode).
So does the NES, so long as you use 1bpp mode with palettes breaking up the image into individual bitplanes (0F200F20 0F0F2020), and you use some sort of scanline interrupt to switch the pattern table partway down.
Yeah, but Espozo complained on the SNES video memory as being too low =P
The thing about graphics on these 2D systems is, you either need a ton of space for graphics to store all the animations, (Neo Geo) or you need a moderate amount of space but have the ability to update about the entire thing in a couple of frames (GBA). Frankly, the SNES (and many other consoles from the time period) have neither. 64KB is okay for just displaying a picture, but if you want to animate that picture, you are going to run into trouble... I'm pretty sure I haven't seen anything like this on the SNES, not because the video hardware couldn't display it, (BG 3 is still a pain) it's because it couldn't really be animated. Off course, complaining about 20+ year old hardware doesn't do any good...
On GBA, you might fake the "breathing" of a walking mech's legs by messing with the affine registers.
To be fair the ability to load a lot of graphics in no time is useless if you need to store them compressed anyway because otherwise they won't fit in the ROM (so you end up losing even more time now thanks to having to keep the CPU busy doing decompression). There's a reason why Neo Geo games were so expensive, they had gigantic ROMs in comparison to other games.
Incidentally this is also why the NGP(C) is stuck at 2bpp graphics, because they had prioritized smooth animations over colorful graphics. Use 2bpp graphics → less space needed for a sprite → less bandwidth needed to load them and less ROM space needed to store them → leaves room for more animations.
That animation would take up almost half the DMA, and half the VRAM with double buffering.
@Sik, I agree. Compression is not a good enough reason to use VRAM over CHR-ROM, because you're only going to be able to compress some of the data, some of the time.