It is currently Tue Nov 21, 2017 2:33 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: How NES render graphics?
PostPosted: Sat Sep 02, 2017 2:37 pm 
Offline

Joined: Thu Mar 23, 2017 11:23 am
Posts: 24
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.


Top
 Profile  
 
PostPosted: Sat Sep 02, 2017 2:56 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
These should get you started:
https://en.wikipedia.org/wiki/Text_mode
https://wiki.nesdev.com/w/index.php/PPU


Top
 Profile  
 
PostPosted: Sat Sep 02, 2017 3:48 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10117
Location: Rio de Janeiro - Brazil
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).


Top
 Profile  
 
PostPosted: Sat Sep 02, 2017 10:38 pm 
Offline

Joined: Thu Mar 23, 2017 11:23 am
Posts: 24
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


Top
 Profile  
 
PostPosted: Sat Sep 02, 2017 11:04 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6447
Location: UK (temporarily)
... The NES's background layer is identical to text mode. If you think otherwise, you are misleading yourself.


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 1:11 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5824
Location: Canada
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?


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 8:28 am 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
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


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 10:29 am 
Offline

Joined: Thu Mar 23, 2017 11:23 am
Posts: 24
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.


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 10:30 am 
Offline

Joined: Thu Mar 23, 2017 11:23 am
Posts: 24
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!


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 11:05 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6447
Location: UK (temporarily)
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.


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 12:18 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5824
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sun Sep 03, 2017 6:35 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 919
Location: Japan
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.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group