Hello I have 2D D3D9 aplication in VC++ 6.0 using bitmaps for the sprites.
Instead of having them into the same folder i would like them embeded into the exe or into a single files (eg .dat)
Seens they are 20+ flooding the folder accessible by anyone and eligible to lose therefore
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.
Can it be used for large files destined for any manipulation?
If you could have some example code would be greate. WOX book on VC 6.0 does not has something
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.
An alternative is to do custom data files, which you can structure in any way you want.
Author
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)
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)
Author
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
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:
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).
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 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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
