I have two questions here, so I'll address them individually.

1: In the game I am making, you need to press a key to fire a bullet. When I press the key though, it fires multiple bullets at once (which is bad because they need to be fired individually).
if (key[KEY_D]) player1newbullet();
Is the code I use to trigger firing a bullet. What's the best way to fix it?

2: My game runs at 16 bit colour depth (it always has, purely because I feel like it). The graphics for use in game are stored as bitmaps. When I try using 16-bit bitmaps in-game (they are 16-bit because there is no point in them being any more detailed, it won't show any more detail at 16-bit colour, obviously) they just show up as black squares the size of the bitmap. I can fix it by saving the bitmaps at any other colour depth (or indexed colour, which can be handy for the ones that only have a few different colours). As I said, I don't want to go to all the hassle of converting all my bitmaps to a different colour depth and since my game is skinnable by the end user I don't want them to have problems.
This sets the graphics mode:

set_color_depth(16);
set_gfx_mode(GFX_AUTODETECT_WINDOWED,640,480,0,0;

This loads a graphic:

BITMAP *background;
background = load_bitmap("background.bmp", NULL);

And this displays that graphic:
draw_sprite(buffer,background,0,0);
Finally, since I'm using double buffering, this creates the temporary buffer:
buffer = create_bitmap(640,480);

Any and all help with these problems would be greatly appreciated.
Thanks, Konedima.

if you're using c++:

it's easy to use! just

if (just_pressed(KEY_D)) fire_bullet();

int k = (keypressed() ? (readkey() >> 8) : 0);
...
if(k == KEY_D)
    player1newbullet();

Why do you people keep insisting on using key[] in a way it wasn't designed for?

Also, the ordering of how you call set_gfx_mode and load_bitmap is very important. When using Allegro properly, there's really no reason to restrict to a specific color depth, unless you're using palette effects (which you're obviously not). You should try to use desktop_color_depth() whenever possible, otherwise you may get a bad speed hit from color conversions.

You're going to have to show more code, then.

Initialization (where you call set_gfx_mode, create_bitmap, load_bitmap, and stuff), and your input routine.

Unless you're disabling color conversions, I see no reason why your graphics come out black. Though I can't see the code where you actually load the graphics.

As for input, you're mixing your logic and drawing. Something like this would work:

Note that player up-down movement will be continuous while the key is held down. If you don't want that, do this instead:

    if (k == KEY_W) player1y = player1y - 4;
    if (k == KEY_S) player1y = player1y + 4;
...
    if (k == KEY_UP)   player2y = player2y - 4;
    if (k == KEY_DOWN) player2y = player2y + 4;

You're mixing logic and drawing again. And don't use rest() to time the game. The FAQ is your friend.

Change:
int k = readkey() >>8;

to:

int k = readkey() << 8;

Oops, my fault for misreading the manual. That was the test for ALT + key.

What happens if you change it to:
int k = readkey();

and then change the other checks to (for example):
if ((k >> 8) == KEY_ESC) win = 3;

For whatever reason, now it is registering those key presses. And when I mean moving the bats is choppy, I mean that before I did all this they moved smoothly. And faster.

Sorry if I sound like I'm whining.

I'm good at not being clear .

All the input issues are fixed. The problems I have are that the bat (and sometimes the bullet) movement is very choppy (bullets appear to move back and forth occasionally) and that 16-bit bitmaps still don't work.

HardTranceFan, your code doesn't help, thanks anyway.

I've changed the code since I last posted it - I've moved all the drawing operations into one function, and out of their logic functions. Here's the main game loop:

I'm weirdly overprotective of my source code (espcially since I plan on releasing it as open source when it's done). I could post it if I really had to, but I'd rather look for other alternatives. The only thing I can think of is that as mentioned before, the bats are moved up four pixels at a time (actually now it's eight). The program was probably running at a faster framerate before because I only had a rest(10) to slow it down, so that could have been it. I don't know how to fix it because if they move any slower, they won't move nearly fast enough.

Something else I've noticed during testing of the latest code is that if you shoot a bullet while moving the bat (by holding the key down), the movement stops until you let go and press down again. Is there any way to fix that?

Nope, it doesn't.