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.
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).
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
... The NES's background layer is identical to text mode. If you think otherwise, you are misleading yourself.
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?
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).
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.
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!
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.
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.
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.