bitmaps: 32bpp vs 24bpp

bitmaps: 32bpp vs 24bpp

boulifb

Member #7,909

October 2006

Hello gurus,

I have noticed an interesting fact.
When using 32bpp for encoding colors in bitmaps, Allegro displays significantly faster the images than if I use 24bpp encoding.

My question is simple...

WHY?

Best regards.

Fred.

Karadoc ~~

Member #2,749

September 2002

32 bit processors are better at passing around integer multiples of 32 bits. I think that's about all there is to it.

-----------

Kitty Cat

Member #2,815

October 2002

The depth you save the image as doesn't matter. Allegro will convert them when you load them in the game.

... You are loading them after setting the graphics mode so Allegro knows what to convert them to, yes?
... You are loading them once on initialization and not all the time during the game, right?

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

boulifb

Member #7,909

October 2006

I initialize the color depth to 32bpp only one time in the code after allegro initialization and I build the map after the level loading.

Michael Jensen

Member #2,870

October 2002

If you're doing a lot of software manipulation to the map then Karadoc hit the nail on the head. If on the other hand, it's a static bitmap, and you have hardware accelerated blitting, then I would think that your graphics card likes 32 bpp surfaces better than 24 bpp...

What is it exactly that you're doing with the bitmaps that 32 bpp is faster than 24 bpp, or 16 bpp? -- I noticed on my older machine (much older) while changing a game I was working on from 32 bpp to 16 bpp (no other changes) that it was much faster -- however all of my bitmaps were memory bitmaps and I was doing a lot of memory -> memory blits, so this explains it.

boulifb

Member #7,909

October 2006

Hi,

Currently, as I said, once I have loaded the level, I build the map in memory with 32 bits for depth color.

I have the following strucutre:
- a bitmap that contains the final frame
- a bitmap that contains the background map with non animated tiles
- a bitmap that contains the foreground map with non animated tiles
- a single linked list that contains values for the animated tiles wich come in front of the player.

The image is generated like this:
- Draw the background (1st plane)
- Draw the foreground which contains transparency to see the background (2nd plane)
- Draw additionnal objects that interact with the player and ennemies
- Draw the player
- Draw the ennemies
- Draw the animated tiles (the 3rd plane actually)
- Draw the status objects

All is drawn on the final bitmap "frame".

The bitmaps that contains the foreground, background and frame are created in memeory after loading the level files.

The bitmap that contains the final frame (the fully calculated image) is stretched and displayed on the "screen" bitmap once generated using stretch_blit.

When I use 32bpp as depth color, it is displayed faster than if I use 24bpp. I can see this with the animations.

Maybe it is due to my video card that prefers 32bpp coding. I don't know. That's why I asked the question.

Best regards.

Fred.

gnolam

Member #2,030

March 2002

Karadoc~~ already answered why it is so. Michael Jensen is just trying to... actually, I have no idea what he's trying to say.

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Arthur Kalliokoski

Second in Command

February 2005

Reading | writing a 24 bit pixel requires either a short int AND a char, or 3 chars. 32 bit just requires reading | writing a single long int. 15/16 bit requires one short int, which should be a tad slower on a 32 bit machine (size override). If the blitting is the bottleneck, and the bitmaps are all the same size (and no SVGA banking) then you could just memcpy, so the 16 bit would be fastest there, then 24, then 32.

They all watch too much MSNBC... they get ideas.