So in the game I'm porting, I have a function where I need recolor pixels in a particular area except for black. It looks something like this

Recolor (x1,y1,x2,y2,color);

Where x1,y1 is the upper left corner of the area and x2 and y2 is the lower left. Now, how I'm doing it now, is copying the area from the screen to a temp bitmap, and then using a for/next loop to check the color of every pixel and then set that pixel color if it's not black. After that is done, I copy that bitmap section back to the screen.

It's super slow, and large bitmaps are causing my game to drop to below 5 FPS. That in itself is strange because, I mean, I'm pushing 3.4Ghz here and someting a trivial as changing a pixel color is bogging down my system. I've been told that I should be using a pixel shader, and doing a quick skims about them they seem over complicated for what I'm trying to accomplish. But now it's serously impacting my game and I need to learn them once and for all.

The problem I'm having is that every time I try and research info about what a pixel shader it's either really vague or goes in some crazy OpenGL/Direct3D low level graphics card mathematics junk.

The Allegro API is not helpful. It shows me how to make a shader object, but then say I need to attach the source code to a shader to make it work. What source code? What language? How do you "program" a shader? When I look up a shader language it, it gives me like 30 of them with stuff like "fragmets" and you have to pass vectors and stuff. It seems so complex.

I guess the upshot is, can someone show me the "front door" on all of this. No 3D OpenGL/DaretX stuff, no low level graphics card gunk, I don't need "vectors" or "fragments" or "tessellation", I am just looking for a fast way to recolor an area of the screen to another color (except for black).

What you have to realize is that allegro uses video bitmaps by default. This means they are stored on the GPU. Whenever you modify a video bitmap by using al_lock_bitmap, it has to download the texture region you lock off of the video card. Once you're done modifying it, you have to upload it back to the gpu. This is very slow.

You can use a shader to alter the color for sure. Trouble comes when you need to read that data off of the gpu. This is where the bottleneck comes from.

You'll find the manual answers several of your questions.

https://liballeg.org/a5docs/trunk/shader.html

There is an example program called ex_shader.c that demonstrates simple use of a shader.

https://github.com/liballeg/allegro5/blob/master/examples/ex_shader.cpp

The source code for the shaders used is in the data directory.

https://github.com/liballeg/allegro5/tree/master/examples/data

You should really try to learn this yourself.

However, I will try to make a simple demo sometime later today.

Sounds like you want to do a palette effect. Those were quite easy to achieve in the past with Allegro 4 but on modern graphics using hardware acceleration I guess shaders are the only way to go.

Someone posted this page a while ago, it has a good introduction to shaders and it should be easy to adapt to using the Allegro shader addon.

Also, have you tried locking your bitmaps before manipulating the pixels?.

This helps actually. It looks like shaders are linked to a language called "glsl" and I should be looking at that. The "vectors" are just ways of addressing variables.
Looking for "glsl tutorial" is being much more fruitful then "shader tutorial" which was way much more technical.

Looking at allegro, it appears that you write a glsl program and then attach that to Allegro. Then you turn it on when you want to use it.

I even found a hello world program and a canvas to experiment with on online. (Evidently you can do shaders in a web browser!) neat...

As for locking the surfaces.. Yea, I do that... Here is the function in question

https://learnopengl.com/Getting-started/Shaders has a good intro to shaders.

As for why your program is slow, there are several reasons.

1) You're creating a temporary ALLEGRO_BITMAP* buffer every time you draw something in a different color. The constant allocation and destruction of this buffer slows your code down.

2) The buffer is unnecessary, because you're using a locked region.

3) ALLEGRO_LOCK_READWRITE causes the texture to be downloaded off the gpu on locking, and uploaded back to the gpu when unlocked. This is slow. Reading causes download. Writing causes upload.

4) Just lock bufmap[i] directly, using only the region you need to recolor.

5) A shader could replace the color as it is drawn on the gpu, which would avoid all this nonsense altogether. It's perfect for what you want.