after all sprites have been loaded and considerring all images i use are 256 colors, would my program run any faster if i set_color_depth(8) instead of set_color_depth(16) as far as blitting is concerned? if so, is it at all significant?

Considering you're only changing one line of code, why not try it? 8-bit should be 2x faster ...

well any game would run faster at a lower screen depth.. however I think that 16 or 32 bit looks much nicer and the speed difference on some machines is neglegable.

23yrold3yrold, i have tried it. its alot faster from what i saw. but i don't want that. i wanted to be convinced otherwise. you know why, all the colors go to poopoo in 8-bit mode. i don't know too much about palettes but it seems that alot of my test bitmaps (from .bmp files acquired from different sources) have different ones. when in 256 color mode, its cwazy cwazy, even after i set_palette (i guess because some of them have different ones). but in truecolor (even using the original 256 color .bmp files) its all good in the neighborhood. i've scoured the forums here. does anyone have a good link to help me deal with this? and why truecolor tastes so good?

Truecolor doesn't use palletes, which is what makes it so easy to use. In 8-bit, they all need to use the same pallete, which requires some planning ahead of time on your part. Actually, I just tried switching from 16 to 8 bit and there was no difference in frame rate at all O_o Go figure ....

EDIT: My mistake I was still online. Going from 16 to 8 bit jumps my fps from 50 to 60. Not enough for me to care, really ....

well, i made a little demo thing a while back that just drops balls down the screen. when i switched it to 8-bit, it took longer before it started getting choppy.

so about this whole palette thing. i've messed with them before, but only little things and that was when i made all the bitmaps using the same prog, so they all had the same palette. is there an easy way to look at the palettes of these bitmaps and make a few changes to them? of course you can do that with allegro, but i'm looking for a more GUIable approach.

thanks.

unless you are running a 486DX then 8bit and 16bit don't make much of a difference.. for instance in my GUI some of the skins are 256 color bitmaps as default.. but I load them in 16bit into the datafiles, then you can always "scale" down to 8bit if the user decides to.. though I've seen some bugs where the palette doesn't get set correctly and the colors are trashed... I like the simplicity of truecolor modes.. you have options like transparency, blending, lit surfaces... and 32 bit makes it really simple and fast to do transparency.. the alpha channel is built into each pixel.

um if all the sprites exist in a datafile, then when you call set_color_depth(8) before load_datafile() the datafile will be forced to 8 bits and a palette consisting of all common colors will be set accordingly... I think:P

If you try 16 bit, also make sure to try 32 bit.

16 bit modes are faster for blitting. 32bit modes are faster to draw to. So in some cases where you are doing lots of drawing or transparency, 32 bit can and very likely will be faster (I've seen it). If you have mostly completely static sprites, and you are just using blit to copy from system RAM to the video card w/o hardware blitting, 16 bit will be faster.

If you are using video accelration via video bitmaps, anything you are going to program won't use the video card enough, so it doesn't really matter 16 or 32 bit .

But then again if your original graphics are only 8 bit there's not much point. 8 bit is always the fastest mode for every case I can think of, except when doing things like transparent or blended drawing modes.

thanks. although i would still like to find a way to solve my palette problem and use 8-bit color, i'll work in the truecolor modes and save that 'till the end.

I would still be using 8-bit, but I've gotten used to alpha/blended graphics -- plus, it seems that a lot of the newer video cards have dodgy 8-bit mode support. Especially the low-res modes like 13h. In particular, a few people have problems getting HalfLight:AE (which is still 256) to work. And, in my own testing, I've seen problems with switching video modes. The palette gets corrupt and remains that way until the game is restarted.

My first game Tetrisised(http://www.geocities.com/mschout2001) uses 256 color mode. As said before, the important thing is to get a common palette for your images. There's a nice utility that modifies your images so they all have the same palette(http://www.step.sk/marian/fixpal.htm). Then take the palette from one of the images and you're set It's not hard to do, but it's quite easy to get to > 256 colors when writing some games.