Utility to convert BMP to BAS

[Xalthorn]

When I need to play around with BMP images, I jump straight to Jim's BMP function.  However, when I want to build the code as a single EXE with no external files, I need to fiddle about to do some converting.

I wrote this little program which uses Jim's function to load the BMP file into an array and then writes it straight out to a BAS file ready for including into your own program as a UINTEGER array.

All you need to do is change the following three lines and run it (as long as your source image is in the same directory)

    INFILENAME="your_source_file.bmp"
    OUTFILENAME="your_output_file.bas"
    ARRAYNAME="what_you_want_to_call_the_array"

So for example, if you had an image file called monkey.bmp and you wanted it to be saved in a file called monkey.bas and when included in your main code it should be filling an array called BIGPICTURE, you would set the lines to be:

    INFILENAME="monkey.bmp"
    OUTFILENAME="monkey.bas"
    ARRAYNAME="BIGPICTURE"

And then compile and run it.

It's not very clever, but it does what it sets out to do.

[Shockwave]

Thanks Xal, could have saved you some work there though as Rbz made a utility called bin2bas to do exactly the same thing

[Xalthorn]

Not quite, bin2bas is great but it creates arrays of ubytes.  Mine dumps them out as UINTEGERS which avoids compile warnings of type mismatches.  Also, a BMP has a header which Jim's routine strips out and then I dump the final array of raw data straight out.

Using Jim's routine in conjunction with mine assures that you have data that is ready for direct inclusion without worrying about upside down images etc.

[Jim]

It's horses for courses though.  eg, this code will take an RLE compressed 8bit bmp and unpack it to a whopper of a 32bit texture.  Rbraz's will just encode the 8bit file.  Depends what you want and need, and it's always good to have the full set of tools in the toolbox   I think it's certainly possible to get the 4bmp files from your cylinder demo smaller without much (or perhaps any) loss of quality - it's an interesting challenge!

Jim

[WidowMaker [retired]]

All tools are obviously very welcome..

As the author of countless cracktros I would say that you are using moving images here and 24 bit images are simply an overkill.. Use a png load library or downgrade your images to 8bp...

As the author of the game scene charts, which has static images, I can see the benefit of having static 24 bit images, I used them previously for interface gfx and title screen where things were displayed for long term viewing by members.. But here the images are moving...

You should be applauded for releasing your program to everyone and making the choice available, definately so for that I give you good karma.

It's possible to one file it and get it to <300 kb but I suppose you know that anyway.

The circle wrapping effect is cool though

[Jim]

If you add this code after the images are loaded, you can easily see the results of a reduction to 8bit

Code: [Select]

dim x,mask as uinteger
mask = &HffE0E0C0
for x= 0 to 180 * 480
firstpic(x)=firstpic(x) AND mask
secondpic(x)=secondpic(x) AND mask
thirdpic(x)=thirdpic(x) AND mask
fourthpic(x)=fourthpic(x) AND mask
next
This is about as naive as it gets, just dropping the bottom 5 bits of red and green and the bottom 6 bits of blue.
The only really bad image ends up being the manga girl.  Either that image could be replaced or you could use something like Photoshop which would have made a far better job of picking the palette!  That would make the 8bit RLE bmp files come in at under 100Kb.

Jim

[Xalthorn]

Another reason I like releasing source and keeping my routines open is purely selfish as I can learn all sorts of tricks and tips as people comment

I was being naive and figuring that as the destination for the images was going to be in a UINTEGER array, they were going to be bloaty in the end so I figured leaving them as fully detailed at source wouldn't hurt.  This is okay on my own machine but it causes huge problems when I try to share them so it makes sense to understand how to compress them, thanks folks.

I think I'm missing a trick with the converter though.  I assumed that as I needed the BMP as a UINTEGER array for inclusion in the program, I'd have to convert whatever the BMP was into the UINTEGER array, even 8 bit ones.  If an 8 bit BMP was converted to a UBYTE array, would that cause confusion and complications when the program was compiled as the data couldn't be copied from buffer to buffer unless you wanted just a blue shaded image.  Also, would an 8 bit BMP need a palette?

(probably jumping at the wrong conclusion with a complete misunderstanding of the BMP file format)

[Jim]

Well, my routine will load an 8bit bmp and load it into a 32bit texture.  I'm pretty sure rbz has a routine that will load 8bit bmps from ram, wheras mine will only work from disk or a resource file.

Jim

[Shockwave]

Rbzs' tool is called bmp2raw, it can be found here;

http://dbfinteractive.com/index.php?topic=370.0

It only works with 8 bit images and it will turn your bitmap into two files, they can be included easily with #include after putting them through bin2bas!

One file is a ubyte array of colour values where each colour is seperated into it's component parts so that they fit into ubytes, the image information then just indexes this colour palette, it's pretty straight forward to use but there's erxample code provided to show you how to do it.