al_init();
al_init_primitives_addon();
al_init_image_addon();
etc----------
I called all the necessary functions to make a window from the main function. Then I used al_clear_to_color(al_map_rgb(200, 100, 150)); and it works fine - no problem.

I called all the necessary functions to make a window from the main function. Then I used another thread to call al_clear_to_color(al_map_rgb(200, 100, 150)); but it shows error(not working). It's acting like as if the thread that called all the necessary functions like al_init() and etc..... are in control. Can anyone help me fix it?

You can use al_set_target_bitmap to change the target display for drawing commands on the current thread. However note that this can be slow and lead to unexpected errors if you're not careful - best is to do your drawing commands on the same thread which called al_create_display.

Hai Elias, thanks for answering
I never thought this forum is this much active - I admire and respect peoples like you (really) Thanks...

I fixed it in a weird way.
Every thread that goes to the rendering subroutine will go through this ->
// Note:- AClass contains the display variable

However it is working, but sometimes it is throwing an exception. Is it a good way to get this done?
Also, I heard that the thread with the control to the display's back buffer must load the bitmaps or else they will be loaded in RAM rather than into the graphics RAM(resulting in lag). Is it correct?
One more thing- can you explain why 3.44 KB PNG file, when loaded using al_load_bitmap(), takes ~3MB of memory space?

Test :
Normal execution : 27 MB

Load bitmap (an image) 88*2064 pixels
Execution : 35 MB

Create bitmap (blank) 88*2064 pixels
Execution : 33 MB

That's easy! It's not compressed when you put it in memory! That's the whole point. If it was, you'd have to uncompress it every time you wanted to use it and then throw away that result and do it again the next time. Allocating and freeing a block of memory takes a lot time, and, why throw away the uncompressed version anyway if you already have it?

Thanks, Chris Kato
I did some research on the memory issue and found some information like the total m/y space for an image x *y pixel (long and wide) would be x*y*3 for RGB. I calculated a rough of 0.5 MB for a pic which takes up 5 MB of space in reality. Is it normal or I am leaking m/y or stuff? I double checked for memory leak but didn't find any.

You guys are amazing...
I wish I had some friends who are pro programmers.

It's normal. Uncompressed images take a lot of space (and the main reason why modern AAA titles supporting 4K displays are over 60GB pretty regularly).

That said graphics cards do support some image compression formats, but these are specialized formats the card can decode in hardware. You wont see any typical image editor outputting them--you'll usually use a special conversion step to go from image editor output to a compressed texture format (and which one depends on the type of texture). DXT Compression. There are more formats than listed in that link, btw. I think there are either 7 or 8 now, though, you'll need recent hardware to access the latest formats.

That'd probably be because you forgot to multiply that by the number of bits per channel

total pixels = width * height
bits per pixel = 32 = 8 bits * 4 channels (red, green, blue, alpha)

minimum bits needed to store image = total pixels * bits per pixel

Taking this into account, the minimum size for your 88x2064 image as stored in memory would be:

88 * 2064 * 32 = 5812224 bits

This equates to about 750kB, which is a fair bit less than the 3MB you mentioned. However, there will be other things taking up space; we haven't yet accounted for all of the bitmap's metadata, struct padding, or any other memory that Allegro or libpng may have had to allocate to facilitate the loading of images.

Thank you dthompson for your enlightening support
I never knew the computer graphics is this much deep and complicated. Next time I will keep in mind to multiply it by the number of channels
You guys are legends ......... I love this Forum more than Facebook

One more thing; I have a background texture - I guess it doesn't need alpha channel?.
How can I remove alpha channel from bitmaps to reduce its size?

Your paint program should have an option to save as a 24 bit png. Or you can just use .bmp.

Thank you Edgar Reynaldo for the replay
I will use 24 bit bmp - my paint doesn't have the 24 bit png.

A note : The same image, encoded as .bmp or as .png, may be smaller as a png due to its compression. .bmp is not a compressed format.

If you want good compression, export as a .jpg with various levels of quality. Quality level 70 still looks very much the same as the original, but gets really good compression.

You're welcome. I always like giving players another life. xD

Thank you Edgar Reynaldo
I will keep that in my mind when I browse for game assets.

What? WHY?

Also, you can always convert bmp to PNG using any other program afterwards. If you're on Linux, it's super easy, with plenty of terminal one-liners.

Thank you Chris Katko for replying
I did download photoshop to my system. So no problem regarding conversion anymore. Thanks for your kind support.

Would you rather take less disk space, or load faster? The only format you should use for images is a compressed texture, as I said earlier.

Thank you relpatseht- for your kind suggestions and knowledge. I am learning new things every day...8-)