I switched my raycaster over from 16-bit to 8-bit, using the DOOM 2 palette. Since I ripped most of my sprites/textures from doom's wads anyway, there was little to no quality loss.
I want to do depth shading, sortof the same way it's done in doom. I know I have to use some sort of palette magic, right? Or should I just make 5 texture maps, each a little darker untill black?
When it was running in 16-bit, I made a really slow version, where it got the r,g,b values from the pixel, and modified them, then drew it. It was too slow...

I saw in the permadi (premadi? I dunno) tutorial, a really nice depth shading effect done with a palette. He used some sort of conversion tables or whatnot I think.

Any Ideas?:P

Making different texture maps that were lighter and darker would suck (too much work for what it is).

I wonder what the conventional method is...?

I would go into higher color depths, but I'm developing this in DJGPP, on a 586 with a crap-tastic gfx card. It can only go up to 24-bit (slowly). I'm trying my darndest to keep the framerate above 22...(easily goes to it's max on faster computers, though).

So you're saying that I need different palettes? 1 for each "section" of deepness?
Okay, so say I have 4 palettes, 1 is normal, 1 is black, and the other 2 transition between. Every time it renders a slice, what would I do? Use set_palette? I'm not very knowlegable on palettes and such in allegro.

Doom uses a colormap table that has several remaps. Basically, it's this:
unsigned char colormaps[num_cmaps][256];You pass it the color map you want (each map has a different brightness and/or effect) and the original palette entry, and it gives you the new palette entry to reference. Allegro's COLOR_MAP routines are pretty much exactly this, except each COLOR_MAP has 256 different maps, whereas Doom only has about 13 light levels (there's not much use to go higher since the limited palette doesn't have that kind of accuracy).

check out this tutorial on gamedev: http://www.gamedev.net/reference/articles/article861.asp

This is a VGA limitation. The fix, however, is simple: just set palette index 0 in your palette to 0,0,0 somewhere at the start of your program. You get the best of both worlds: you can keep a distinctive (and hi-/truecolor friendly ) mask color in your sprites and still get a nice black border when running your program.

No. The mask color is always palette index 0 in 8 bit, regardless of its color. Keep index 0 as magic pink in your sprites but set it to 0,0,0 at startup. This way you can still convert your sprites to a higher color depth (and/or edit them easily), but your program won't have the annoying border.

Your code will only work if the palette your working with is at the brightest range, otherwise it will be 5 shades to medium with no darkening.

light_map[4]<i>=i;

Is that what you want? It won't be colors related to pal....

Okay, I got it working for 5 light levels, but it wasn't really that nice looking. So, I changed it to 10 levels, but now there are problems.
On the darkest 5 or so levels, it looks fine, and it's the effect I want. But, on the lighter 5 or so, it looks bad. It has seemingly random colors on th walls! [Screenshot Attached].
Here is the code for the initializing of the light tables:

I did put some code in to have it spit out the values of lite_map[9] to a file:

/* LM9[#] is which index, RGB is the _current_pallete<i>.r .g .b*4, 'C' is the index that makecol8 returns. */
LM9[0] R 0 G 0 B 0 C 0
LM9[1] R 858993459 G 1077490483 B 0 C 1077018624
LM9[2] R 0 G 1077018624 B -1717986918 C 1076205977
LM9[3] R 858993459 G 1078997811 B 858993459 C 1078997811
LM9[4] R -1717986918 G 1080842649 B -1717986918 C 1080842649
LM9[5] R -1717986918 G 1077254553 B -1717986918 C 1077254553
LM9[6] R -858993459 G 1076677836 B -858993459 C 1076677836
LM9[7] R -858993459 G 1075629260 B -858993459 C 1075629260
LM9[8] R -858993459 G 1074580684 B -858993459 C 1074580684
... You get the idea ...

Here's the implementation of the lite_maps in the slice drawing code:

/* buffer is the bitmap being drawn to
   column[srcy] is the pixel being placed on that buffer */
if(distance>=0&&distance<100) (buffer->line<i>)[x]=lite_map[9][column[srcy]];    
if(distance>=100&&distance<200) (buffer->line<i>)[x]=lite_map[8][column[srcy]];    
if(distance>=200&&distance<300) (buffer->line<i>)[x]=lite_map[7][column[srcy]];    
if(distance>=300&&distance<400) (buffer->line<i>)[x]=lite_map[6][column[srcy]];    
if(distance>=400&&distance<500) (buffer->line<i>)[x]=lite_map[5][column[srcy]];    
if(distance>=500&&distance<600) (buffer->line<i>)[x]=lite_map[4][column[srcy]];    
if(distance>=600&&distance<700) (buffer->line<i>)[x]=lite_map[3][column[srcy]];    
if(distance>=700&&distance<800) (buffer->line<i>)[x]=lite_map[2][column[srcy]];    
if(distance>=800&&distance<900) (buffer->line<i>)[x]=lite_map[1][column[srcy]];    
if(distance>=900) (buffer->line<i>)[x]=0;                            //lite_map[0][column[srcy]];    

On the screenshot, I marked levels 9 through 4, which are the problem levels. The FPS is low only when the bad levels take up a majority of the view. Otherwise, it's at about 25 fps.

Thanks for any help...

So umm, no makecol()?

I certainly wouldn't! It's not going to work in 8-bit mode. No offence but you appear to be confused.

[edit]

Let me explain in a bit more detail:

In 8-bit mode you can have only 256 colours on the screen at any one time. To make a particular colour darker, you have to chose another one of the 256 colours that best fits a darker version of the original colour, you do not modify the palette unless you want all the onscreen pixels of the modified index to change. This is the whole purpose of the light_map look up table, it stores which of the 256 colours best fits the colour produced by modifying the original colour.

Storing RGB values in the LUT is completely pointless unless you want to use makecol8 every time you wish to draw a pixel. considering that makecol8 has to search the whole palette this would be slooooow.

but:

He switched to 8-bit so that he could youse the DOOM 2 palette. The whole point is to avoid having to change the palette. If you change the palette you'll have to change all the textures.

You can use Doom's pre-calculated COLORMAP resource. Use a program like Wintex to extract the binary chunk from the game file.
The format is described in [8-2] of the unofficial doom specs
cheers