Just like any PE * application in Windows32, the KOL application allows you to store the graphics resources necessary for its operation along with the executable file. These resources can be loaded by various methods, including implicit loading of resources by object methods, but ultimately they all boil down to calls to the appropriate API functions that create the required graphical object and return its descriptor.
From an application size perspective, the number and size of these resources can be important. Sometimes you can significantly reduce the size of resources if you use careful selection of the most suitable formats for storing graphics. First of all, notice the number of different colors required to represent a bitmap or icon graphic. Even if the picture uses non-standard colors that are not present in the standard system palette, but the number of these colors does not exceed 256, then it makes sense to use the 8 bits per pixel format. And if there are no more than 16 colors, then 4 bits per pixel is perfect. Even in the case of the transition from the full-color format 24 bits per pixel to the 8-bit format, for one image with a size of 100x100 pixels, a saving of 20,000 bytes will be obtained - 256x4 = 18976 bytes. Here I have subtracted the cost of storing the 256-color palette itself at 4 bytes per color. I will also note that there is a presentation format (considered obsolete, but quite workable), in which not 4, but 3 bytes are spent per color in the palette. When using this format, you can save at least another 256 bytes (the image header in this format is also a few bytes shorter, so the savings will be slightly higher).
For large image sizes, where the total number of different colors used is already large enough to be limited to 256, consider using 16 bits per pixel images. An unpleasant feature of this format is that the R and B color channels (red and blue) discard the least significant 3 bits, and the G channel (green) discards the least significant 2 bits. In some cases, such "rounding" can slightly degrade the quality of the picture, especially if it contains elements of smooth gradient fill. But in general, in many cases, the deterioration in image quality is hardly noticeable to the eye.
Some novice programmers have the misconception that storing images in a compressed format, as opposed to storing them in a bitmap, can save application size. Yes, it can, but only if the total effect of compressing all such resources overrides the negative effect of adding appropriate decompression algorithms to the code. Usually, the presence of an unpacker for any of the most common formats GIF, JPG, PNG requires more than 30KB of additional code for each.
If the total effect of compressing images in resources by using one of these formats exceeds the size of the unpacker added to the program code, then the game is worth a certain number of candles. However, in this case, you should also take into account that if you plan to package the application using some external packer, then the effect of such packaging will be significantly reduced if some of the resources inside the application are already packed. Very often it makes sense in this case not to use any graphics packers at all, and store resources in the form of "flat" uncompressed "bitmaps", and use an external packer or a simple archive of the application file at the time of its distribution to end users.
There is another compression format that is sometimes quite useful (for example, in the case of images containing large areas of one color) that is often forgotten: it is RLE encoding. The TBitmap.LoadFromStreamEx method allows loading such images without any problems (thanks to V. Gavrik, who added this method to KOL). Most likely, you will have to load such a resource with your own code, referring to the above method, but this is no more difficult than using loaders of other formats with compression. You will, of course, have to find software that will RLE compress images before packaging them into resources.
