Hi everybody !
(anybody?)

Someone said that putpixel and getpixel are really slow. Is this true?
And more importantly (for me) does this also go for the explicit _getpixel and _putpixel ?
I wanted to replace a (single) whole blit with this. Or should I then resort to something more complicated?

[EDIT] Uhhmm... first I thought about posting something else, but I forgot to to rename the post. Sorry!

Yes

Yes, but it is a bit less slow than regular putpixel

Replacing a whole blit with putpixel calls is bad idea. You better describe what you want to achieve, I bet there are better alternative solutions to the problem.

If it's just blitting you want, resort to blit().
If you need more sophisticated selective replacement, or blending, a lot can be done with allegro's blender functions, but for better performance, you should look into libraries that allow you to use hardware acceleration; AllegroGL and / or OpenLayer are good starting points.
In many situations, direct access to the bitmap data through line pointers can be the answer.

Thanks for the answers. I will answer your question:
it is a fighting-game (ie two guys slapping eachother) and at first I thought it was a good idea to only use one (set of) bitmap(s) if the characters were the same. (side note: because initially I started out making another type of game actually.)
But if I want an alternative colour for the other guy, I will have to figure something out. Before looking into it I thought I could do something like "draw_sprite(bmp, palette+1)". But ofcourse I can't. And before you say so: I also want it to be able to run 8bpp, so alternating palettes is not an option (I think).
I could make a copy of the bitmap to be different, but I don't consider it clean...
and it would require me to rethink the loading procedure.
It's only a 8bpp blit (to a temporary 8-bits bitmap), but it is every frame...
(How would I use the line pointers for this?)

I'd say go with a quick and easy solution. Before the game starts, predraw all the frames with the new colors (using (_)putpixel) and use the new frames in the game. As long as there aren't zillions of frames and you don't do in in real time there shouldn't be a problem.

I consider it to be much cleaner than the kind of hacking you propose, especially since copying images would be considerably faster

One way of achieving it relatively simple would be this:
First, create your base sprites with colourcoded areas that can be colored differently. For example this magnificent stickman has three different areas whose colour you can choose. They are red, blue and yellow. The black is unchangeable:

Using this image you can create several copy's, each one will have its colourcoded areas filled with different colour. As those copies are generated once at loading time I don't see any problems by creating them using plain old get/putpixel.

Of course there are other more interesting ways of doing it but that one is the simplest one I came up with

Yeah, you're right... The method I came up with now is kind of hackish... and assumes a char to be 8 bits (or defines a 8 bit struct ).
The reason why I wanted this, is because I don't consider each player to have an appearance (bitmap), but each kind of game-object. This works like a charm if you have let's say a shooter .
How do 3D games tackle this? I've seen totally different alternate models, but I do not consider it clean to allocate memory for something that's almost exactly the same.
But for the rest, you guys are right.

Usually they do just that: have alternative skins for the models. When they are really smart they divide the skin to smaller parkts so they can have five identical bodies all with different heads.

After all, a single skin doesn't take that much memory. A few megs is not all that much when you consider how much computations you save with it.