Starting with graphics

[eriksan]

Hi, I'm looking to start with graphics programming and want to buy a suitable Digilent product. How much RAM do I need if I want to try out double buffering a QVGA pmod with 16 bits per pixel? Would it be ( (320 * 240 * 16) / 8 / 1024 ) * 2 = 300 kB? 

I have seen that it is possible to extend the memory with a pmod such as SF3 (32Mb). Is such a module suitable to expand the RAM in order to store the frame buffers? 

Also where is the  graphical RAM locate, by the way?

Can I just connect a QVGA screen pmod to a pmod shield on top of a uC32 for example? What are some other connection options?

 I am also considering starting with a 32*128 or similar OLED or a 96×64 pixel RGB OLED, is it possible to double buffer with those? 

 

[JColvin]

Hi @eriksan,

Could you let me know what you are hoping to accomplish with the double buffering? Additionally, when you are referring to a QVGA Pmod, are you referring to the Pmod MTDS? If you wanting to know if you can use it with Digilent boards, you can see the list of support Digilent boards (of which the uC32 is listed) in the library download.

You would not want to use the SF3 to expand RAM; the SF3 (and other serial flash modules) are designed to store data in the long term and cannot be used as RAM in the way you are intending. You could store premade images on them, but realistically I would recommending having them on a microSD card and then insert that SD card into the slot that is present on the Pmod MTDS (or the MTDS Shield). Regardless, the both variants of the MTDS have their own embedded PIC32MZ processor that controls the display process, so you are only able to send commands and are not able to configure if double buffering is used by the display or not.

As for the individual connections, you can individually wire the Pmod MTDS to the correct pins on a uC32, attach it to a Pmod Shield as you suggested, or just use the MTDS Shield directly on the uC32 (or a different supported board with Arduino headers).

I don't believe any of the Digilent boards have graphical RAM that you are able to specifically utilize. They tend to instead have SRAM.

With regards to the Pmod OLED or the Pmod OLEDrgb, I'm not certain what the purpose of double buffering would be since OLEDs do not refresh their displays like an LCD screen; you can simply manipulate the individual pixels to be on or off through the provided libraries. However, you certainly can have other images prepared and loaded into memory on the Pmod OLED before updating the display.

Let me know if you have any questions about this.

Thanks,
JColvin

 

[xc6lx45]

Hi,

one opinion / alternative (for "looking to start with graphics programming", not "have to design a working product by day x"):

Any FPGA can generate analog RGB VGA signals, either with a $10 resistive-divider add-on board or going with jumper wires straight to the VGA cable (it's ugly and slightly out of spec but works just fine). This means you are designing your own "graphics chip". Take it as a proposed lab exercise that requires minimal hardware investment. Get the cheapest board, consider it disposable and save the option of buying something better for long-term motivation or when you've reached the limits of what the small board can do ( )

Example for a minimum monochrome text-based VGA adapter: link  comes with a default image, requires only input clock, HSYNC, VSYNC and R (or G or B ) outputs to get an image to the screen.

[eriksan]

On 5/31/2019 at 10:51 PM, JColvin said:

Hi @eriksan,

Could you let me know what you are hoping to accomplish with the double buffering? Additionally, when you are referring to a QVGA Pmod, are you referring to the Pmod MTDS? If you wanting to know if you can use it with Digilent boards, you can see the list of support Digilent boards (of which the uC32 is listed) in the library download.

You would not want to use the SF3 to expand RAM; the SF3 (and other serial flash modules) are designed to store data in the long term and cannot be used as RAM in the way you are intending. You could store premade images on them, but realistically I would recommending having them on a microSD card and then insert that SD card into the slot that is present on the Pmod MTDS (or the MTDS Shield). Regardless, the both variants of the MTDS have their own embedded PIC32MZ processor that controls the display process, so you are only able to send commands and are not able to configure if double buffering is used by the display or not.

As for the individual connections, you can individually wire the Pmod MTDS to the correct pins on a uC32, attach it to a Pmod Shield as you suggested, or just use the MTDS Shield directly on the uC32 (or a different supported board with Arduino headers).

I don't believe any of the Digilent boards have graphical RAM that you are able to specifically utilize. They tend to instead have SRAM.

With regards to the Pmod OLED or the Pmod OLEDrgb, I'm not certain what the purpose of double buffering would be since OLEDs do not refresh their displays like an LCD screen; you can simply manipulate the individual pixels to be on or off through the provided libraries. However, you certainly can have other images prepared and loaded into memory on the Pmod OLED before updating the display.

Let me know if you have any questions about this.

Thanks,
JColvin

 

Thank you, I'm fairly new to graphics and electronics. I would like to learn to render 2D and 3D graphics and have read about the double buffering technique elsewhere but didn't realise it didn't apply to the Pmod MTDS nor the OLED Pmods. My goals for this is to implement some algorithms from the Graphics Gems (mainly 1 and 2) books, learn to draw lines, shapes, detect intersections and make a small game-like program to showcase. I also want to learn about using matrices for 2D and 3D transformations. When I get advanced enough for 3D I would like to learn how to make ray-traced, real-time scenes.

If I start out with a Pmod OLEDrgb, will the uC32 have enough RAM or is it recommended to take something with more RAM? The uC32 has 32kB of RAM but the Pmod OLEDrgb is (320*240*16)/8/1024 kB = 150kB so one frame would not even fit in the RAM of the uC32, is this correct counting? Is it possible to use less than 16 bits/pixel?

 

12 hours ago, xc6lx45 said:

Hi,

one opinion / alternative (for "looking to start with graphics programming", not "have to design a working product by day x"):

Any FPGA can generate analog RGB VGA signals, either with a $10 resistive-divider add-on board or going with jumper wires straight to the VGA cable (it's ugly and slightly out of spec but works just fine). This means you are designing your own "graphics chip". Take it as a proposed lab exercise that requires minimal hardware investment. Get the cheapest board, consider it disposable and save the option of buying something better for long-term motivation or when you've reached the limits of what the small board can do ( )

Example for a minimum monochrome text-based VGA adapter: link  comes with a default image, requires only input clock, HSYNC, VSYNC and R (or G or B ) outputs to get an image to the screen.

Hi, I have seen the Pmod VGA, would it be suitable for someone like me who's not very experienced with wires? It's an interesting proposition to design my own "graphics chip" but... I already have experience using Digilent Basic I/O shield and its monochrome OLED to draw pixels and lines and I would like to leverage my experience. And since I'm into graphics, I'm not sure that a text-based VGA-adapter would be what I need, since I need to draw pixels, lines, etc. But I am wondering... it must be possible to draw individual pixels with the VGA-solution, right? 

[xc6lx45]

Hi,

>>  I would like to learn to render 2D and 3D graphics
>> some algorithms from the Graphics Gems (mainly 1 and 2) books, learn to draw lines, shapes, detect intersections and make a small game-like program to showcase.
>> I also want to learn about using matrices for 2D and 3D transformations. When I get advanced enough for 3D I would like to learn how to make ray-traced, real-time scenes.

My first thought is, "why not use a PC" or even a Raspberry Pi (it's no graphics miracle but good luck challenging one with an FPGA or whatever board)

For example, double-buffering is one line away in a typical high level language.

[JColvin]

Hi @eriksan,

I believe that is correct that you would not be able to dynamically store every pixel for the Pmod OLEDrgb within the uC32 to display it. However, if you have a pre-designed image (or set of images), those can be stored externally and accessed and displayed whenever you need them.

The other thing to consider though is if you are changing every pixel on the display or only a small subset of pixels (or just storing premade images in the on-board flash). In the end though, @xc6lx45's suggestion/consideration of using a board that is more readily designed to accomplish the task of image display and double-buffering than doing a lot of up-front work yourself.

Thanks,
JColvin

[eriksan]

On 6/1/2019 at 11:22 PM, xc6lx45 said:

Hi,

>>  I would like to learn to render 2D and 3D graphics
>> some algorithms from the Graphics Gems (mainly 1 and 2) books, learn to draw lines, shapes, detect intersections and make a small game-like program to showcase.
>> I also want to learn about using matrices for 2D and 3D transformations. When I get advanced enough for 3D I would like to learn how to make ray-traced, real-time scenes.

My first thought is, "why not use a PC" or even a Raspberry Pi (it's no graphics miracle but good luck challenging one with an FPGA or whatever board)

For example, double-buffering is one line away in a typical high level language.

I don't want to use a graphics API, but want to learn to draw graphics myself for learning purposes. Yeah a PC is an option.

On 6/3/2019 at 9:53 PM, JColvin said:

Hi @eriksan,

I believe that is correct that you would not be able to dynamically store every pixel for the Pmod OLEDrgb within the uC32 to display it. However, if you have a pre-designed image (or set of images), those can be stored externally and accessed and displayed whenever you need them.

The other thing to consider though is if you are changing every pixel on the display or only a small subset of pixels (or just storing premade images in the on-board flash). In the end though, @xc6lx45's suggestion/consideration of using a board that is more readily designed to accomplish the task of image display and double-buffering than doing a lot of up-front work yourself.

Thanks,
JColvin

Ok, thanks for the suggestion. I will think some more.