How NES render graphics?
Moderator: Moderators
-
- Posts: 24
- Joined: Thu Mar 23, 2017 11:23 am
How NES render graphics?
Hello.
How NES render graphics?
I don't think it have framebuffer, due to 2kb of RAM.
For example PAL 16 indexed colors we should allocate about 400 bytes of RAM.
So, may be i should take sprite from chr and directly copy in to NES graphics processor?
Links pls.
How NES render graphics?
I don't think it have framebuffer, due to 2kb of RAM.
For example PAL 16 indexed colors we should allocate about 400 bytes of RAM.
So, may be i should take sprite from chr and directly copy in to NES graphics processor?
Links pls.
Re: How NES render graphics?
These should get you started:
https://en.wikipedia.org/wiki/Text_mode
https://wiki.nesdev.com/w/index.php/PPU
https://en.wikipedia.org/wiki/Text_mode
https://wiki.nesdev.com/w/index.php/PPU
Re: How NES render graphics?
The NES assembles a whole picture, pixel by pixel, every frame, based on the contents of the pattern, name and attribute tables, as well as palette RAM, OAM and various PPU settings, like the scroll and other things configured through PPU registers (color emphasis, grayscale, sprite/bg masking, etc.).
The name tables are 2D grids of tile indices, indicating the order in which to draw the tiles. The pattern tables contain the tile graphics themselves. The attribute tables indicate which palettes to use for each 16x16-pixel region of the name tables. Palette RAM contains all the background and sprite palettes. OAM contains a list of 64 sprite attributes, each with X and Y coordinates, a tile index (whose graphics will be pulled from the PT too), and other details (palette to use, flip X, flip Y, priority).
The whole picture is assembled from scratch every frame, nothing is copied anywhere, so any changes that are made anywhere in VRAM/palette/OAM will impact the whole image "instantaneously" (the next rendered frame). For example, if you modify a tile in the pattern tables, all instances of that tile on the screen will reflect those changes. In fact, this is how most games animate background blocks (e.g. SMB3).
The name tables are 2D grids of tile indices, indicating the order in which to draw the tiles. The pattern tables contain the tile graphics themselves. The attribute tables indicate which palettes to use for each 16x16-pixel region of the name tables. Palette RAM contains all the background and sprite palettes. OAM contains a list of 64 sprite attributes, each with X and Y coordinates, a tile index (whose graphics will be pulled from the PT too), and other details (palette to use, flip X, flip Y, priority).
The whole picture is assembled from scratch every frame, nothing is copied anywhere, so any changes that are made anywhere in VRAM/palette/OAM will impact the whole image "instantaneously" (the next rendered frame). For example, if you modify a tile in the pattern tables, all instances of that tile on the screen will reflect those changes. In fact, this is how most games animate background blocks (e.g. SMB3).
-
- Posts: 24
- Joined: Thu Mar 23, 2017 11:23 am
Re: How NES render graphics?
Text modes on IBM PC or any other comupter can't be compared with NES.tepples wrote:These should get you started:
https://en.wikipedia.org/wiki/Text_mode
https://wiki.nesdev.com/w/index.php/PPU
It's using blitting and double buffering(in most cases) to present image.
But looks like PPU can store framebuffer, have enough VRAM
Re: How NES render graphics?
... The NES's background layer is identical to text mode. If you think otherwise, you are misleading yourself.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: How NES render graphics?
Why do you believe this? There is no buffer. Try reading that text mode article that was linked?monobogdan wrote:It's using blitting and double buffering(in most cases) to present image.
Re: How NES render graphics?
Early systems like the NES drew the screen repeatedly one scanline at a time. This is why you have stuff like only 8 sprites per scanline - each row of pixels is processed individually and there's only so much processing time that can be spent on any given row. Framebuffer-based graphics processors weren't really a thing until the early 3D era (Saturn/PS1/N64) where you could draw arbitrary amounts of stuff, though there were early exceptions (notably Star Fox).
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
-
- Posts: 24
- Joined: Thu Mar 23, 2017 11:23 am
Re: How NES render graphics?
Because i know, on big vide modes(640x480 for example) double buffering is must have to reduce flickering due to time needed to draw frame.rainwarrior wrote:Why do you believe this? There is no buffer. Try reading that text mode article that was linked?monobogdan wrote:It's using blitting and double buffering(in most cases) to present image.
-
- Posts: 24
- Joined: Thu Mar 23, 2017 11:23 am
Re: How NES render graphics?
Thank you!HihiDanni wrote:Early systems like the NES drew the screen repeatedly one scanline at a time. This is why you have stuff like only 8 sprites per scanline - each row of pixels is processed individually and there's only so much processing time that can be spent on any given row. Framebuffer-based graphics processors weren't really a thing until the early 3D era (Saturn/PS1/N64) where you could draw arbitrary amounts of stuff, though there were early exceptions (notably Star Fox).
Re: How NES render graphics?
Uh.monobogdan wrote:Because i know, on big vide modes(640x480 for example) double buffering is must have to reduce flickering due to time needed to draw frame.
The MDA card renders a 720x350@50Hz image in text mode. There's only 4 KiB of RAM, not enough for a framebuffer. It's not a resolution thing.
When SVGATextMode was relevant, graphics cards were often capable of rendering in text mode effective resolutions of 1280x1024, using just 20 KiB for the tilemap and another 4 KiB for the font.
The definition of "text mode" is "look up a tilemap (nametable, in NES parlance) entry, use that to look up a tile (character cell in PC parlance, pattern in NES parlance), render just-in-time". You are completely mistaken if you think that text mode means anything else.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: How NES render graphics?
I think you need to make a qualification here that you mean for video game consoles. Many PCs had framebufferes since the early 80s. CGA had 16 kilobytes of RAM available to it, and its non-text modes used it as a framebuffer. EGA had enough RAM for double buffering in some modes.HihiDanni wrote:Framebuffer-based graphics processors weren't really a thing until the early 3D era (Saturn/PS1/N64) where you could draw arbitrary amounts of stuff, though there were early exceptions (notably Star Fox).
Text mode, though, used the RAM for a tile map, not a framebuffer.
Re: How NES render graphics?
Anyhow, monobogdan, you noted in another thread that you know x86 assembly. That will help with NES ASM programming, but:
The NES is not a PC!
Words such as framebuffer, blit, double-buffer, draw frame, etc. have no place in NES parlance.
You'll be talking things like tilemap, tiles, and hardware sprites. A somewhat different concept. People have been trying to explain it to you, in 3 different ways, but only one way seemed to click. Please reread the posts above and understand that they are equivalent in explaining the NES' PPU concept.
The NES is not a PC!
Words such as framebuffer, blit, double-buffer, draw frame, etc. have no place in NES parlance.
You'll be talking things like tilemap, tiles, and hardware sprites. A somewhat different concept. People have been trying to explain it to you, in 3 different ways, but only one way seemed to click. Please reread the posts above and understand that they are equivalent in explaining the NES' PPU concept.