Well, I figured this one out on my own, but I was tempted to post to the
list, so I thought I’d share my findings with other people who may run
into this in the future.
I set my app to running in 16bpp at all times. I then used
SDL_LoadBMP() to get 24 bit images from the storage drive. Now, this
blits fine without the user knowing that the BMP is stored in 24bpp.
However, if you use SDL_AllocSurface and make a 16bpp surface as I
mistakenly did, you cannot blit the BMP (which was 24bbp) onto the
surface and retain colour information.
So now I’ve decided to use 24bpp internally in my project and render at
16bpp. I’ve always thought it to be interesting to save the data in
ways that the release product may not be able to fully interpret, but
with an upgrade later (such as a new renderer), it would use the new
data. This kind of stuff is hardly done in a capitalist market, as
games usually don’t even warrant small bugfixes unless it’s selling
well, but it happened with GlQuake. It would have been neat to have had
16bpp textures sources in Quake all of a sudden, though I can think of
many reasons why it wasn’t done that way. Anyways, .–
Michael Labbe (not the pedophile)
So now I’ve decided to use 24bpp internally in my project and render at
16bpp.
I recommend that you not use 24bpp internally. It is by far the slowest
of the pixel formats available. What I recommend instead, if you need
the full RGB color information is to use 32bpp internally. It has the same
information as 24bpp, but is faster to manipulate by about a factor of 4.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
I recommend that you not use 24bpp internally. It is by far the slowest
of the pixel formats available. What I recommend instead, if you need
the full RGB color information is to use 32bpp internally. It has the same
information as 24bpp, but is faster to manipulate by about a factor of 4.
Wow, thanks for the heads up. Since I’m reading this mailing list as the
messages become available in realtime and coding, 32bpp has been implemented
now.–
Michael Labbe (not the pedophile)
I recommend that you not use 24bpp internally. It is by far the slowest
of the pixel formats available. What I recommend instead, if you need
the full RGB color information is to use 32bpp internally. It has the same
information as 24bpp, but is faster to manipulate by about a factor of 4.
Wow, thanks for the heads up. Since I’m reading this mailing list as the
messages become available in realtime and coding, 32bpp has been implemented
now.
Can you point to any documents on the bitwise operations needed to store the
data of a pixel in 15, 16, 24 and 32bpp? I really could use some clarification
on these issues. They’ve been dogging me off and on for about a year now.–
Michael Labbe (not the pedophile)
Can you point to any documents on the bitwise operations needed to store the
data of a pixel in 15, 16, 24 and 32bpp? I really could use some clarification
on these issues. They’ve been dogging me off and on for about a year now.
Try looking at the SDL_blit.h file in the SDL source directory.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Are there any speed benchmarks for the different BPP modes around?
-Lea.
Sam Lantinga wrote:> > Can you point to any documents on the bitwise operations needed to store the
data of a pixel in 15, 16, 24 and 32bpp? I really could use some clarification
on these issues. They’ve been dogging me off and on for about a year now.
Try looking at the SDL_blit.h file in the SDL source directory.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec