How to pack BMP files in the .exe or into a single external file?

You can embed arbitrary data files inside .exe files. You'll use GetModuleHandle and LoadResource functions to access them. However, as you also pointed out, that's a windows-only solution.

An alternative is to do custom data files, which you can structure in any way you want.

Cant I find somewhere example code on how does that work? Its so confusing. What exactly do i have to do it does not explain.
Right in the bitmap filename in the parameter? Or do i nott both.

(Since we re talking of DirectX API windows its the only way)

Custom Data Files i guess you are reffering to binary data files not?

Seems to me more simple than finding out how these WIN API functions work with no piece of codes examples at all

In the past I have been proposed the resource system of windows.
But i think its olny for icons cursors and UI tools in general.[/quote]
Incorrect assumption. Under Windows you can store anything you want in resources as binary data, via the RCDATA/RT_RCDATA type (and you retrieve them in much the same way as you would other resources, as a bitstream).

But doing that usually isn't the best way to go, because it makes updating your executable difficult. A good compromise is to store your stuff in a single big file (or multiple, medium-sized files, sensibly) and read them like that. But unless you really need that, it's often best to just stick with one file per asset, scan for their existence when you start your program and come up with an error if one is missing.


LPCVOID LoadRes(CONST INT pResID, DWORD & pLen)
{
HINSTANCE hInst = GetModuleHandle(NULL);
HRSRC hRsrc = FindResource(
hInst,
MAKEINTRESOURCE(pResID),
RT_RCDATA);
if(NULL == hRsrc)
return NULL;
DWORD len = SizeofResource(hInst, hRsrc);
if(len == 0)
return NULL;
LPVOID lpLoad = LoadResource(hInst, hRsrc);
if(NULL == lpLoad)
return NULL;
pLen = len;
return LockResource(lpLoad);
}


As another option you could compile them into the binary as well.

You need to make a HEX dump of the BMP file and thin in code you define this:
class image_error
{
public:
static const unsigned char m_imageData[] = {
0x42, 0x4D, 0x38, 0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x36, 0x0, 0x0, 0x0, 0x28, 0x0, 0x0, 0x0, 0x40,
0x0, 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x1, 0x0, 0x18, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x30, 0x0, 0x0, 0xE6,
0x1C, 0x0, 0x0, 0xE6, 0x1C, 0x0, ... ,0x0
};
static const unsigned int m_dataSize = 12344;
};


This is not ideal however as it will make the executable very big and you have to have facilities in place to be able to load image data from memory (which usually shouldn't be a problem).

As another option you could compile them into the binary as well.

You need to make a HEX dump of the BMP file and thin in code you define this:
class image_error
{
public:
static const unsigned char m_imageData[] = {
0x42, 0x4D, 0x38, 0x30, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x36, 0x0, 0x0, 0x0, 0x28, 0x0, 0x0, 0x0, 0x40,
0x0, 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x1, 0x0, 0x18, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0x30, 0x0, 0x0, 0xE6,
0x1C, 0x0, 0x0, 0xE6, 0x1C, 0x0, ... ,0x0
};
static const unsigned int m_dataSize = 12344;
};


This is not ideal however as it will make the executable very big and you have to have facilities in place to be able to load image data from memory (which usually shouldn't be a problem).

I would REALLY avoid this.

I would REALLY avoid this.[/quote]

I made a program a while back to store font textures using the above method into my programs so that they would be standalone without any external files. But the program would output a byte array (into a header file that I would simply include in the source file which produces the actual texture for rendering) that was packed so that each value was only 4-bits.. For a single channel font texture this is fine, 16 shades of grey, but perhaps you could modify it to have 16 shades per RGB component, and thus reduce total header file size.

As for having a large EXE, well the whole package is going to be large whether the EXE is big, or the EXE+ external files is big. It really does not matter if the EXE is big. I don't personally plan on storing any textures in my projects in my EXEs other than the font texture (adds < 10kb for my purposes) just because I have other approaches that work fine (procedural).

http://www.van-noland.com/downloads.php look for 'fontpack.zip' for source to the project I'm talking about.

Instead of all the things people suggested, which strike me as bad ideas:
http://icculus.org/physfs/
You can use it to pack everything into a single ZIP file, and read them transparently at runtime.

Instead of all the things people suggested, which strike me as bad ideas:
http://icculus.org/physfs/
You can use it to pack everything into a single ZIP file, and read them transparently at runtime.

It would have a good compression ratio for bitmaps, but it is the slow method.
It depends on project requirements.

I would REALLY avoid this.

[/quote]

Respect, bro!

I use resources but since it's windows only I would use an assembler's incbin feature to create a data OBJ file, dd all the symbols in a table and link the file with the exe. Inside the exe I'd dereference the array of pointers to the actual data.

In my project I made a small GDI based file collector/compressor which indexes, serializes and then deflates (using zlib) my project's resources. The project then has a namespace which reads the file, inflates it and then allows ready-to-use objects (textures, sounds, etc) to be generated on demand from the loaded data. Interestingly enough, the implementation of this system was a lot more simple than I had thought it would be. I ended up spending most of my time on the GDI utility, placing all the controls and making it look shiny.

You can see a slighty old version of my code here: http://www.gamedev.net/index.php?app=core&module=attach&section=attach&attach_id=8980

The resource packager has been changed slightly since then, but only in order to accommodate more resource types.

The relevant code is the 'RPAK' project within the solution and the 'RscStore' namespace in the main solution ('Bricks').

It's probably not something that you could just use for your own project, but if you look over it you should get the main thrust of it. The RPAK code is a little messy. Sorry.