Sign in to follow this  
esgol

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

Recommended Posts

esgol    105
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

Share this post


Link to post
Share on other sites
clb    2147
You can embed arbitrary data files inside .exe files. You'll use [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs.85).aspx"]GetModuleHandle[/url] and [url="http://msdn.microsoft.com/en-us/library/windows/desktop/ms648046(v=vs.85).aspx"]LoadResource[/url] 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.

Share this post


Link to post
Share on other sites
esgol    105
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)

Share this post


Link to post
Share on other sites
esgol    105
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

Share this post


Link to post
Share on other sites
Bacterius    13165
[quote]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.

Share this post


Link to post
Share on other sites
kubera    1587
[CODE]
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);
}
[/CODE]

Share this post


Link to post
Share on other sites
NightCreature83    5002
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:
[code]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;
};
[/code]

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). Edited by NightCreature83

Share this post


Link to post
Share on other sites
XVincentX    129
[quote name='NightCreature83' timestamp='1339504265' post='4948457']
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:
[code]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;
};
[/code]

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).
[/quote]

I would REALLY avoid this.

Share this post


Link to post
Share on other sites
deftware    1778
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).

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

Share this post


Link to post
Share on other sites
Promit    13246
Instead of all the things people suggested, which strike me as bad ideas:
[url="http://icculus.org/physfs/"]http://icculus.org/physfs/[/url]
You can use it to pack everything into a single ZIP file, and read them transparently at runtime. Edited by Promit

Share this post


Link to post
Share on other sites
kubera    1587
[quote name='Promit' timestamp='1339540838' post='4948651']
Instead of all the things people suggested, which strike me as bad ideas:
[url="http://icculus.org/physfs/"]http://icculus.org/physfs/[/url]
You can use it to pack everything into a single ZIP file, and read them transparently at runtime.
[/quote]
It would have a good compression ratio for bitmaps, but it is the slow method.
It depends on project requirements.

Share this post


Link to post
Share on other sites
XVincentX    129
[quote name='Bacterius' timestamp='1339520182' post='4948548']
[quote]I would REALLY avoid this.[/quote]

[img]http://i49.tinypic.com/rwm5qw.png[/img]
[/quote]

Respect, bro! [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

Share this post


Link to post
Share on other sites
Fredericvo    1765
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.

Share this post


Link to post
Share on other sites
Khatharr    8812
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: [url="http://www.gamedev.net/index.php?app=core&module=attach&section=attach&attach_id=8980"]http://www.gamedev.net/index.php?app=core&module=attach&section=attach&attach_id=8980[/url]

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this