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

How NES render graphics?
https://forums.nesdev.com/viewtopic.php?f=2&t=16441
Page 1 of 1

Author:  monobogdan [ Sat Sep 02, 2017 2:37 pm ]
Post subject:  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.

Author:  tepples [ Sat Sep 02, 2017 2:56 pm ]
Post subject:  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

Author:  tokumaru [ Sat Sep 02, 2017 3:48 pm ]
Post subject:  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).

Author:  monobogdan [ Sat Sep 02, 2017 10:38 pm ]
Post subject:  Re: How NES render graphics?

tepples wrote:

Text modes on IBM PC or any other comupter can't be compared with NES.
It's using blitting and double buffering(in most cases) to present image.
But looks like PPU can store framebuffer, have enough VRAM

Author:  lidnariq [ Sat Sep 02, 2017 11:04 pm ]
Post subject:  Re: How NES render graphics?

... The NES's background layer is identical to text mode. If you think otherwise, you are misleading yourself.

Author:  rainwarrior [ Sun Sep 03, 2017 1:11 am ]
Post subject:  Re: How NES render graphics?

monobogdan wrote:
It's using blitting and double buffering(in most cases) to present image.

Why do you believe this? There is no buffer. Try reading that text mode article that was linked?

Author:  HihiDanni [ Sun Sep 03, 2017 8:28 am ]
Post subject:  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).

Author:  monobogdan [ Sun Sep 03, 2017 10:29 am ]
Post subject:  Re: How NES render graphics?

rainwarrior wrote:
monobogdan wrote:
It's using blitting and double buffering(in most cases) to present image.

Why do you believe this? There is no buffer. Try reading that text mode article that was linked?

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.

Author:  monobogdan [ Sun Sep 03, 2017 10:30 am ]
Post subject:  Re: How NES render graphics?

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

Thank you!

Author:  lidnariq [ Sun Sep 03, 2017 11:05 am ]
Post subject:  Re: How NES render graphics?

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

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.

Author:  rainwarrior [ Sun Sep 03, 2017 12:18 pm ]
Post subject:  Re: How NES render graphics?

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

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.

Text mode, though, used the RAM for a tile map, not a framebuffer.

Author:  ccovell [ Sun Sep 03, 2017 6:35 pm ]
Post subject:  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.

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