What is a Line Buffer?

This is a discussion on What is a Line Buffer? within the Tech Board forums, part of the Community Boards category; In computer hardware graphics terms, what is a 'Line Buffer'? I found this online and I think this is what ...

  1. #1
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163

    What is a Line Buffer?

    In computer hardware graphics terms, what is a 'Line Buffer'? I found this online and I think this is what I'm looking for as far as definitions but not sure.

    How Buffer (Analysis) works

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    That seems to be something to do with geodetic measurements and mapping. Not related to computer graphics really.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163
    I found the definition for a 'Frame Buffer'. I'm assuming a 'Line Buffer' is a truncated version of this. i.e. one line of say 8 across instead of 8 across and 8 down frame buffer.

    What is Frame Buffer

    The explanation is pretty good for me until it gets up to the 'lookup table' and how the 3 plane frame buffer (N) indexes into the lookup table. How they are relating is not clear to me.
    Last edited by A34Chris; 03-02-2013 at 12:59 AM.

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    The lookup table thing is not really relevant in modern graphics. The example shown there is a "planar 3-bit indexed color", otherwise known as palette mode. Sometimes images are stored this way in image files -- but never processed this way inside the graphics hardware, unless your hardware is from 1986.

    What the picture shows is that the three planes of bits are combined to give a 3-bit number at every pixel location. That 3-bit number is used as an index into an array of 4-bit RGB color values (how to split 4 bits into 3 values I'm not sure, I suppose 1 bit for red, 2 bits for green, 1 bit for blue, but the picture honestly is not a realistic example). Those values are what ultimately end up on the screen.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #5
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163
    Quote Originally Posted by brewbuck View Post
    The lookup table thing is not really relevant in modern graphics. The example shown there is a "planar 3-bit indexed color", otherwise known as palette mode. Sometimes images are stored this way in image files -- but never processed this way inside the graphics hardware, unless your hardware is from 1986.

    What the picture shows is that the three planes of bits are combined to give a 3-bit number at every pixel location. That 3-bit number is used as an index into an array of 4-bit RGB color values (how to split 4 bits into 3 values I'm not sure, I suppose 1 bit for red, 2 bits for green, 1 bit for blue, but the picture honestly is not a realistic example). Those values are what ultimately end up on the screen.
    Actually it is kind of relevant to what I am doing because I am tinkering with something from that era. Thats why I'm looking it up.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Ah, well in that case, was my answer helpful? I can answer more questions.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    Registered User
    Join Date
    May 2010
    Posts
    2,739
    Maybe if you would tell us what you're trying to accomplish we may be able to give you an informed answer instead of all the guessing. A line buffer could be referring to the terminal line buffer for all we know at this point.

    Jim

  8. #8
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163
    Quote Originally Posted by jimblumberg View Post
    Maybe if you would tell us what you're trying to accomplish we may be able to give you an informed answer instead of all the guessing. A line buffer could be referring to the terminal line buffer for all we know at this point.

    Jim
    Thanks for the input guys! I'm trying to wrap my head around how graphics work on a legacy console system called the Atari Jaguar. I asked one of the experienced coders in the community and he explained things for me and told me that the line buffer concept is almost exclusive to Atari machines. His words for those curious:

    That page is a little bit confusing, yes. It's mixing up the concept of the frame buffer and the palette without explaining how they are distinct. Without trying to confuse the issue by talking about DACs and how the monitor works, it might be easier to just talk about how what they are and how you use them.

    A frame buffer, as they describe, is just a block of memory that represents the screen. There are a number of ways to represent the screen, but in this case (and for all practical purposes most cases relating to the Jaguar), it means that the memory represents a 2D array of pixels.

    Now the page talks about bitplanes - and that is a valid way of storing more color depth information, the Amiga and the Atari ST worked this way. But the Jaguar doesn't use bitplanes in its hardware, instead it uses what's often called a 'chunky' mode, where all the bits run together. Let me explain in more detail.

    Imagine a system where you have 4 possible colors -- each pixel thus needs 2 bits to describe it. (Don't worry at this time what the colors are - that will come later. Just that there are 4). For sake of example, let's say your screen is 320x200 pixels.

    In a planar system, you would have two arrays of memory, each 320x200x1 bit in depth, so, basically, 320x200x(1/8) (because there are 8 bits in a byte) = (320*200)/8 = 64000/8 = 8000 bytes. So you would have two 8000 byte buffers, each representing 1 bit of every pixel.

    In a chunky system, you just run the bits together. So you would have a single array of memory which is 320x200x2 bits, or 320x200x(2/8)=320x200x(1/4)=64000/4=16000. Note that it takes the same amount of memory, it's just arranged differently

    A chunky system is a lot easier to work with -- you only have to look at one spot in memory to get the color of a pixel. In a planar system, you have to get one bit out of each plane, and put all those bits together, to know what color it is. So why use a planar system at all?

    It's actually more efficient when you deal with sizes that don't work nicely into a byte. For instance, the Amiga has a mode that is 5 bit planes deep (for 32 colors). Making this work in a chunky mode would get very complicated, because you would have one pixel overlapping two bytes if you just streamed the bits together. Alternately, you could waste a lot of memory, by storing one 5-bit pixel in a byte, and throwing away the other three. This is easy to deal with in hardware but wasteful. A planar mode, however, just creates 5 bitplanes and doesn't waste a thing, and it's easy for the hardware to work with. But since it's not easy for the programmer, they fell out of fashion as soon as graphics became powerful enough to be worth it (such as 256-color modes).

    All right, so the second program that graphics hardware had to overcome was how to get colors on the screen. Most early systems had only from 2-4 bits available for color, so that's 4 to 16 possibilities. It's pretty hard to map these bits directly to the Red/Green/Blue values that a display uses to make a picture -- in the 2-bit case you can't even do 1 bit per gun! So instead, the concept of a "palette" was created. Much like an artist's palette, this is a set of pre-defined colors, and they are simply numbered. So when the graphics system see "3" as a pixel number, for instance, it goes to the palette, and extracts the /actual/ color information for Palette Color #3. In older systems, these colors were hard-wired, but in later systems, including the Jaguar, you the programmer can define this color table and so you can make color 3 anything that the hardware supports.

    The Jaguar supports mixing of 16 bit graphics, 8 bit graphics, 4 bit graphics, 2 and I think 1 bit graphics, and the Object Processor can automatically handle the lookups into the color table. (The caveat being that the Jaguar only supports one 256-color (8-bit) table, that all the various bitdepths share). 16 bit graphics are "high color" and instead of going through a color palette, they are directly decoded by the hardware. (16-bit RGB maps bits directly to the red/green/blue values, and 16-bit CRY actually uses a different hard-wired color selection system to provide 65536 colors).

    The concept of a line buffer is almost unique to Atari platforms. Most systems define enough video accessible memory to provide a full frame buffer, and the CPU draws into the frame buffer, while the video hardware pulls from it. But the Jaguar (and the 2600 and I don't know about the 5200 or 7800) only provide a line buffer. The object processor normally fills the line buffer for you, and as a programmer you usually don't care about it, except that you have to provide the data that will ultimately go there. Basically, the video hardware only has enough memory to buffer a single line of video at a time (it's actually 2, but you can't do anything about the second one so no point worrying about it). The system has to erase and fill that line buffer in time to provide the data to the television set in real time - the TV will /not/ wait. If the line buffer isn't updated, whatever was in it was just be displayed again on the next line.

    What this means to the Jaguar is you can actually run a game without a frame buffer at all -- the idea probably being that you save memory for your own purposes. The Object processor (and the blitter) can write into the line buffer fast enough to generate a scanline in real time, meaning as long as you can /calculate/ the line, you can display it without needing a big reserved block of data. In practice, though, most games use at least a little memory for building the display. For instance, the Jaguar hardware can not rotate a 2D sprite, so it has to be drawn rotated into a temporary buffer by the programmer (with the blitter) then copied out line by line (by the object processor). The hardware also usually renders polygons to a traditional frame buffer, because this is much easier (you don't have to keep up with the TV). In /theory/ it's possible to render polygons on the Jaguar without a frame buffer, but your code needs to be very fast and very smart, to draw the correct line segments and keep up with the TV.

    Hope that helps.

  9. #9
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    He defined it for you in that very post:

    The concept of a line buffer is almost unique to Atari platforms. Most systems define enough video accessible memory to provide a full frame buffer, and the CPU draws into the frame buffer, while the video hardware pulls from it.
    ...
    Basically, the video hardware only has enough memory to buffer a single line of video at a time (it's actually 2, but you can't do anything about the second one so no point worrying about it).
    Essentially, instead of buffering a full frame of data, it buffers just the next horizontal line to be drawn.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  10. #10
    Registered User
    Join Date
    Sep 2006
    Location
    Beaverton, Oregon, United States
    Posts
    163
    Thanks for the input!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Scroll up and down line by line (from buffer) in c
    By zradu in forum C Programming
    Replies: 1
    Last Post: 02-20-2012, 06:31 AM
  2. Class for both dynamic allocated buffer and static buffer
    By TotalTurd in forum C++ Programming
    Replies: 3
    Last Post: 01-07-2012, 08:09 PM
  3. Reading a buffer line by line, while using system read
    By Hammad Saleem in forum C Programming
    Replies: 9
    Last Post: 05-27-2008, 05:41 AM
  4. fgets(buffer,sizeof(buffer),stdin);
    By linuxdude in forum C Programming
    Replies: 2
    Last Post: 10-28-2003, 09:41 AM
  5. reading command line arguments into buffer
    By jpp1cd in forum C Programming
    Replies: 2
    Last Post: 12-12-2002, 07:08 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21