1
\$\begingroup\$

I am trying to plan a graphics processor project that will only render lines. It will use the bresenhmam's line algorithm. After reading on the algorithm, it makes sense how it works to calculate locations of pixel that make up a line. What is not clear is how will this be output to a screen. Perhaps, the data will likely be stored into an external memory, but the obvious way to do so appears highly inefficient.

Assume I have 10 lines. I calculate the pixel values that make each of these lines, do I store these pixels into some internal FIFO for "dispatch"? Then another part of the design reads the pixel values to be "dispatched", calculates what location to store them in memory and writes them to memory. This has to do be done for each line meaning that a memory location may be read and written multiple times for a single frame if multiple lines pass through nearby each other. Is this correct? If so, then as the number of lines to draw increases, it will be harder to write full frame to memory by rendering all lines before the next frame has to read out since frame rate for video display is fixed.

This means there is no way to go from top left screen pixel to bottom right and find out if a given pixel is part of a line. I can't find a simple explaination for how to implement frame buffer for this type of system.

\$\endgroup\$
  • \$\begingroup\$ Unless there are a very limited number if lines, I am not sure this approach is the easiest. Traditionnally, a display controller has a frame buffer representing all pixel's colors independently, and you then draw lines within this buffer. But having the controller taking care of the lines rendering while the refresh is done is tricky, I think. \$\endgroup\$ – dim Nov 6 '16 at 16:12
  • \$\begingroup\$ @quantum231: you will need double-buffering. That is, one screen buffer is rendered on while the other one is read out. As soon rendering is done, switch the two at next vsync. Rendering according to current raster line is possible (see old home computers) but imposes a lot of limitations. \$\endgroup\$ – Janka Nov 6 '16 at 16:15
  • \$\begingroup\$ you don't 'go from top left ... and find out if a pixel is part of a line', you for each line poke the pixels that make up that line, as you are iterating along the line you are automatically generating the pixel addresses, you don't have to calculate anything, not if you have got your row and column addressing ordered correctly. The work scales linearly with the total length of line you have to render. \$\endgroup\$ – Neil_UK Nov 6 '16 at 16:45
  • \$\begingroup\$ Have you ever wondered why games with complicated graphics run with lower framerates on worse computers? Now you know exactly why. \$\endgroup\$ – immibis Dec 7 '16 at 0:29
1
\$\begingroup\$

As you work out the pixels in each line you would calculate the bits in the frame buffer to set for that pixel. This would depend on the frame buffer organisation and number of bits per pixel. As you suggest drawing 10 overlapping lines means the same address is accessed multiple times, and again as the number of lines increases then you may not be able to draw all the lines before the frame scan.

This does not affect the drawing process though and you don't need to complete the rendering process before the frame is sent to the screen but it will result in flickering. In fact you will get flickering and this is where a second buffer would be used.

Image you have draw a complicated shape on the screen which needs to be rotated by 5 degrees. The display is sent the information from buffer 1. You calculate the new lines and write to buffer 2 while continuing to show bufer 1. Once complete you then wait for the last line to be displayed from the current buffer1 and switch the display logic so on the next scan it displays buffer2. All further writes are then to Buffer 1 until ready to switch back.

This is why on typical games benchmarks you may see frame rates drop to 12fps in complicated scenes. Not becauses the display drops from 60fps but because the same frame is displayed 5 times before the new frame is ready to be drawn.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.