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[] = {
0,65535,63519,2047
};
const uint8_t R[] = {
12,12,
0,0,0,0,0,0,0,0,0,128,0,0,
0,0,0,0,0,0,0,0,0,0,128,128,
0,0,0,0,0,0,0,0,0,128,0,128,
};
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.
Working on it. The tile mode already requires this approach.
Hi @jonne, can you try with this image? https://www.dropbox.com/s/f2x4n4wwpk92t7v/chars.bmp?dl=0
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
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
bmp:
https://drive.google.com/open?id=0BweEjvtKj1KLR0FNN0lJRUNZa0E
.c:
https://drive.google.com/file/d/0BweEjvtKj1KLZmRmN2VWNTU2c3M/view?usp=sharing
edit: what was the source program for image? Photoshop / GIMP ?
@HomineLudens @adekto @trelemar
IMPORTANT : BUGS FIXED, WORKS A LOT BETTER NOW
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:
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.
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!
IMPORTANT
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[] = {
0,32768,1024,33792,16,32784,1040,50712,50936,42590,16640,24832,33024,41216,49408,57600
};
const uint8_t chars[] = {
352,472,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,255,240,0,0,
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:
then
convert to 4 color
export
still can’t process image
Is there a way to export in the correct BMP 8bpp mode with GIMP?
please send me / share on dropbox and i will see whats up. I am sure it can be done from GIMP also
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 https://sourceforge.net/projects/image2code/
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.
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
Success
Bitmaps from GIMP and Photoshop now generating same output. GIMP 4-bit sourcefile is now supported.
New release tomorrow & native Linux version too.