3 ms·

So this may be a dumb question.. Why is a lot of ram needed for running a display? Is it just to be able to save all the pixel data? If you'd be generating your

So this may be a dumb question.. Why is a lot of ram needed for running a display? Is it just to be able to save all the pixel data? If you'd be generating your image on the fly then I'm assuming ram wouldn't matter because you wouldn't be storing anything?

numpad0 2y ago
Is it just to be able to save all the pixel data. Intermeshing game logic processing with scanline generation is likely a bit too archaic for most projects.
AnotherGoodName 2y ago
800 * 480 * 16bit * 30fps = 23million bytes written out to the screen per second. Don't even look at higher resolutions, it's literally exponential in bandwidth. Video takes a lot of data. The highest resolutions and framerates put the fastest network speeds to shame. A CPU just plain can't do this. Even if you want to pretend it's one cycle per pixel the realtime constraints at higher resolutions are way out of the realm of feasible. We struggle to do CPU driven audio in realtime as-is (Audio is measured in Khz of bandwidth rather than Mhz). You can do this at very low resolutions easily enough (again it's exponential with resolution increase) but then you have a low resolution screen.
- makapuf 2y ago
  As a hobby I created in 2014 a console on a single microcontroller that does exactly that, with VGA resolution https://bitboxconsole.blogspot.com/ https://bitboxconsole.blogspot.com/
xena 2y ago
I mean you can race the beam yeah, probably easier because you have two cores, but a framebuffer is easier for developers to work with.
HankB99 2y ago
Not dumb at all. I worked with an ST Micro processor and small TFT display. The routine to write to the screen was to save the contents to RAM and then point a graphics renderer to that RAM. Double and triple buffering were required to avoid screen tearing (screen update with partial previous and next screen mixed.)

numpad0 2y ago

Is it just to be able to save all the pixel data. Intermeshing game logic processing with scanline generation is likely a bit too archaic for most projects.

AnotherGoodName 2y ago

800 * 480 * 16bit * 30fps = 23million bytes written out to the screen per second. Don't even look at higher resolutions, it's literally exponential in bandwidth. Video takes a lot of data. The highest resolutions and framerates put the fastest network speeds to shame. A CPU just plain can't do this. Even if you want to pretend it's one cycle per pixel the realtime constraints at higher resolutions are way out of the realm of feasible. We struggle to do CPU driven audio in realtime as-is (Audio is measured in Khz of bandwidth rather than Mhz). You can do this at very low resolutions easily enough (again it's exponential with resolution increase) but then you have a low resolution screen.

makapuf 2y ago
As a hobby I created in 2014 a console on a single microcontroller that does exactly that, with VGA resolution https://bitboxconsole.blogspot.com/ https://bitboxconsole.blogspot.com/

xena 2y ago

I mean you can race the beam yeah, probably easier because you have two cores, but a framebuffer is easier for developers to work with.

HankB99 2y ago

Not dumb at all. I worked with an ST Micro processor and small TFT display. The routine to write to the screen was to save the contents to RAM and then point a graphics renderer to that RAM. Double and triple buffering were required to avoid screen tearing (screen update with partial previous and next screen mixed.)