Hello all,
My first post to the list, so I apologise if I get any local etiquette
wrong 
I would like to use SDL on an embedded device which has an LCD which
only supports 12 bit/pixel (12bpp) color.
I have got everything running, (testsprite produces somewhat expected
results) however (I assume) because the chosen video mode uses 2
bytes/pixel, I’m missing some vertical lines and the aspect ratio and
colors are wrong.
Has anyone successfully got SDL to run at 12bpp? If not, and I was to
add this support, can anyone offer any pointers as to where to start and
how it should be done to best fit in with the current codebase so we can
contribute it back?
Thanks,
Neil.
Hello all,
My first post to the list, so I apologise if I get any local etiquette
wrong
I would like to use SDL on an embedded device which has an LCD which
only supports 12 bit/pixel (12bpp) color.
I have got everything running, (testsprite produces somewhat expected
results) however (I assume) because the chosen video mode uses 2
bytes/pixel, I’m missing some vertical lines and the aspect ratio and
colors are wrong.
Has anyone successfully got SDL to run at 12bpp? If not, and I was to
add this support, can anyone offer any pointers as to where to start and
how it should be done to best fit in with the current codebase so we can
contribute it back?
Write a video driver. The SDL framework is set up well to accept new
ones. One approach – which I used for the iPod to get 2-bpp working
– is to tell SDL that your display is, indeed, 16-bit. Then, in
FOO_UpdateRects, copy the screen to a private 12-bit buffer, and
update the screen with that.
You could also, in a method like that, set
screen->format->BitsPerPixel 16 but have e.g.
Rmask = 0xF00
Gmask = 0x0F0
Bmask = 0x00F
and just copy the low 12 bits of each 2 bytes – that would be faster.
SDL doesn’t support packed (non-whole number of bytes per pixel)
surfaces because (a) the implementation of them is very
endian-dependent (see 24bpp) and (b) nobody has put in the
(significant) amount of work to make it work. It’s easier to just do
something like the above.
HTH
– JoshOn 6/20/05, Neil Bryden <Neil.Bryden at greyinnovation.com> wrote:
Thanks,
Neil.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hi Josh,
Thanks for your help on this, we’ve now got this working on our embedded
device. We made an off screen surface at 2 bytes per pixel and then we
pack it prior to display.
Thanks to everyone for a great library!
Cheers,
Neil.On Tue, 2005-06-21 at 22:31 -0700, Joshua Oreman wrote:
On 6/20/05, Neil Bryden <Neil.Bryden at greyinnovation.com> wrote:
Hello all,
My first post to the list, so I apologise if I get any local etiquette
wrong
I would like to use SDL on an embedded device which has an LCD which
only supports 12 bit/pixel (12bpp) color.
I have got everything running, (testsprite produces somewhat expected
results) however (I assume) because the chosen video mode uses 2
bytes/pixel, I’m missing some vertical lines and the aspect ratio and
colors are wrong.
Has anyone successfully got SDL to run at 12bpp? If not, and I was to
add this support, can anyone offer any pointers as to where to start and
how it should be done to best fit in with the current codebase so we can
contribute it back?
Write a video driver. The SDL framework is set up well to accept new
ones. One approach – which I used for the iPod to get 2-bpp working
– is to tell SDL that your display is, indeed, 16-bit. Then, in
FOO_UpdateRects, copy the screen to a private 12-bit buffer, and
update the screen with that.
You could also, in a method like that, set
screen->format->BitsPerPixel 16 but have e.g.
Rmask = 0xF00
Gmask = 0x0F0
Bmask = 0x00F
and just copy the low 12 bits of each 2 bytes – that would be faster.
SDL doesn’t support packed (non-whole number of bytes per pixel)
surfaces because (a) the implementation of them is very
endian-dependent (see 24bpp) and (b) nobody has put in the
(significant) amount of work to make it work. It’s easier to just do
something like the above.
HTH
– Josh