BMP2POK graphics conversion tool

Hey @adekto

I tried your source image.

It worked 100% correct.

 * BMP image as 2bpp (4 color) data

#include <stdint.h>

const uint16_t R_pal[] = {

const uint8_t R[] = {



great, small request on output, an 0b (binary) representation might be easer for people to read or edit
and using 0x (hex) for the 16 color mode

Good point. I will add that.

But otherwise we really should work towards a more user-friendly tool.

I’ve managed to get a BMP2POK linux version running, but ran into a seriout problem: ubuntu has different endianness

i recomomend swapping over to stb_image
for the file loader since your only suporting windows bmp in a specific bit depth
this is a little bit more stable, i have had BMP2POK crash before XD

but will look into cross platform gui, maybe add some simple paint tools aswell or pallet swap previewer

It would be super useful if we could provide the command with a sprite width and height parameter for converting a sprite sheet into an array of sprites. That way we didn’t have to run this tool for every sprite we create, just call the sprite by index when drawing.

1 Like

Working on it. The tile mode already requires this approach.

1 Like

Hi @jonne, can you try with this image?
I’m getting strange result with latest bmp2pok from github

Pokitto BMP to Pokitto bitmap conversion utility
file: chars.bmp strlen file: 9 justfile: chars Number of colours used: 0
Outputting c file: chars.c
1 Like

Downloading & checking

edit: it didnt like the palette in the bmp. changing to RGB and back to indexed with “exact” palette (2 colors remained) in Photoshop fixed the problem. Your .bmp had a 256 color palette. It should have been able to handle it but didn’t. I will look into this



edit: what was the source program for image? Photoshop / GIMP ?

found the bug / weird bmp “feature” will fix tomorrow. thanks @HomineLudens

@HomineLudens @adekto @trelemar


Hello all

Please get the latest version from github.

I found several things why there have been problems with this tool, and those issues have been solved.

Please read to understand what were the issues:

  1. BMP2POK reports 0 colors

In the depths of Microsoft BMP specification I found that if BMP file lists “0” as number of colors, it means automatically 2^n colors. I didn’t know this, this has been implemented now.

  1. Output filename gets corrupted

in wingdi.h (part of MinGW) bmi.bmiColors is declared as an array of 1. Yes. Go check if you don’t believe. This means that when colors are read with fread(&bmi.bmiColors[0]…) subsequent data is overwritten when the color table overruns the table in the memory. This is why the output filename sometimes got corrupted. Fixed!


However, you still have to understand what you are doing when you are saving your BMP files and converting them with BMP2POK

This is because if you do not reduce the number of colors to the amount that you are using before you save the BMP you will end up with something that looks like this:

const uint16_t chars_pal[] = {

const uint8_t chars[] = {

This is the conversion of the graphics file from @HomineLudens. BMP2POK will now kindly convert the graphics even though it has a 256 color palette inside.

The problem is that in the file, Filippo actually had only 2 colors. Black and white. Yet we see there are color numbers like “255” and “240”. This .c file would be broken if you would use it in your game.

The problem is not because of BMP2POK. Drawing programs allow you to for example draw in “white” color, yet use “white” that is found in different indexes of the palette. You think you are drawing in 2 colors, where in actuality the program (Photoshop / GIMP) may be drawing your pixels in 6 or something different indexed colors.

This is why you should reduce your colors to the exact number you are using when you convert your graphics from RGB (16 million colors) to an indexed BMP image.

BMP2POK is much better now, thank you all for the feedback. Try it again if you had problems and report back. But please read and understand my advice on reducing colors before converting the BMP file.

Thanks for the fixes @jonne!
That file was edited with GIMP and saved as bmp. Then open again in MSPaint and saved as 2 color bmp. Finally I’v open it again with MSPaint and saved again as 256 color BMP as this the only file format accepted. This is what I remember.

Now using GIMP:


convert to 4 color


still can’t process image

Is there a way to export in the correct BMP 8bpp mode with GIMP?

1 Like

please send me / share on dropbox and i will see whats up. I am sure it can be done from GIMP also

Here the result from GIMP:

The problem was that you image is a 1-bit (monochrome) file.

BMP2POK was written because there are no converters that output 2-bit and 4-bit images.

There are many converters that convert 1-bit images to C header.

I use

As for how to do this in GIMP properly, I will test it today and write instructions here.

EDIT: even so, I will probably add a -1 switch to BMP2POK to avoid this confusion later

Still I can’t get it. I’ve just test using a 4 color palette in GIMP and also a 256 color. Index mode and then export as BMP. This should be the way as I found on some tutorial to export a bmp in 8bpp. But still BMP2POK fail. I’ll wait for your istruction, thanks.

1 Like

In a few moments I will be able to fire up my Ubuntu box and will try it out

I really recommend using GraphicsGale. It’s free, for pixel art and you can set it to 8bpp off the bat.

Native Linux version of BMP2POK is almost ready. Releasing tomorrow.

Found the problem. If # of colors < 17, GIMP directly creates 4-bit BMPs. Same file on Photoshop gets written as 8-bit

Edit: there is no option to change this behavior

You can increase colors to >16 by adding dummy color to the colormap, but then GIMP writes them in whatever order:

C:\Pokittodev\bmp2pok\bin\Debug>bmp2pok.exe roguegimp.bmp -4
Pokitto BMP to Pokitto bitmap conversion utility
file: roguegimp.bmp strlen file: 13 justfile: roguegimp Number of colours used: 27
Colour: 0  r:82  g:71  b:66
Colour: 1  r:0   g:0   b:0
Colour: 2  r:0   g:0   b:0
Colour: 3  r:0   g:0   b:0
Colour: 4  r:0   g:0   b:0
Colour: 5  r:0   g:0   b:0
Colour: 6  r:0   g:0   b:0
Colour: 7  r:0   g:0   b:0
Colour: 8  r:0   g:0   b:0
Colour: 9  r:0   g:0   b:0
Colour: 10 r:0   g:0   b:0
Colour: 11 r:0   g:0   b:0
Colour: 12 r:0   g:0   b:0
Colour: 13 r:0   g:0   b:2
Colour: 14 r:0   g:0   b:0
Colour: 15 r:0   g:0   b:0
Colour: 16 r:0   g:0   b:0
Colour: 17 r:0   g:0   b:0
Colour: 18 r:255 g:85  b:255
Colour: 19 r:85  g:255 b:255
Colour: 20 r:255 g:255 b:255
Colour: 21 r:0   g:0   b:0
Colour: 22 r:0   g:0   b:0

What a piece of crap.

I need to write support for 4-bit images to support GIMP-exported files.

Edit: GIMP behaavior of changing automatically to 4-bit packing is logical but annoying as hell

And the fact that colormap gets written in a random order is really annoying

Edit: nope the real reason is that GIMP writes the complete header with all the gamma bitmask stuff so color table is not at same position as with photoshop


Bitmaps from GIMP and Photoshop now generating same output. GIMP 4-bit sourcefile is now supported.

New release tomorrow & native Linux version too.