Images into a single file. Packed.

[czar]

At the moment we have hundreds of images stored as png and jpg with our product. We do not want these images used for anything other than what we intend.

Is there a way to store 5-8 images in a single file and then to read out a specific image from that file? And if so how?

I don't want to have to load the entire file into memory (e.g. like DXG, OIL etc).


Any ideas on how to achieve this would be welcome.

[Traveler]

Currently I'm working on a similar tool. The idea is that I load all images in a single file. I have the whole thing nicely organized in a directory like structure, so I can have a toplevel, sublevels and the items (sound/images) within.

In my game I'm able to load portions of this file using myFileStream.seek(Offset, Origin) and myFileStream.ReadBuffer(buffer, count); So there's really no need to load the entire file.

There have been a couple threads about this particular topic in the past though.

[czar]

Thats sounds like the ticket. I think we should be able to knock up something similar.

[Nitrogen]

Otherwise find a ZIP library and store your files as such!
Simpler, better, faster..

[czar]

Problem with zip is that you would need to unzip them when required. And that would be too slow.

[LP]

Is there a way to store 5-8 images in a single file and then to read out a specific image from that file? And if so how?

I don't want to have to load the entire file into memory (e.g. like DXG, OIL etc).

You can always borrow TASDb component out of Asphyre and use it for your needs.

[size=9px]Curious though, I always seen people (on Afterwarp) trying to avoid using one compressed/encrypted file and having thousand images in folders instead. The idea of having just two files in the game (EXE and ASDb file) for some mystical reason doesn't seem appealing to these people.[/size]

[Clootie]

Loading from ZIP files often is faster (if proper compression method is used in first compression step). This happens because of 2 reasons:
* large archive file is more probably placed in continuous area on disk - so less searches needed to be performed by HDD; HDD head take smaller 'trips' from file to file (each could take around 10ms on average)
* Compressed data takes less space on HDD, so effective transfer rate from HDD to system memory increases up to 2x.

[czar]

@Lifepower normally I wouldn't be too worried about access to gfx but we have paid around US$20k to have them drawn so we want to protect them from casual poachers. Our product is not for sale for the general public which means these protection measures are probably sufficient.

@Clootie. Sounds interesting, I will have a talk to other guys in our team and see what they think.

Cheers people, I have something to think about.

[LP]

@Lifepower normally I wouldn't be too worried about access to gfx but we have paid around US$20k to have them drawn so we want to protect them from casual poachers. Our product is not for sale for the general public which means these protection measures are probably sufficient.

Again, I suggest you take a look at ASDb component source code (remember, it's on MPL basis ) - you can get some ideas out of it. It uses Blowfish cipher [optionally] to protect the contents of the data file and no, it doesn't load the entire archive, only the record you are trying to retreive.

[technomage]

I use a custom compressed archive based on zlib. I can't remember the component name but I'll try and post a link. It's implements a zip link archive structure (including directories) and can be read from a TFileStream

I have to agree with Clootie, I haven't noticed any slowdown in speed between loading from a normal file and a compress file. Although you probably won't be able to compress you png images very much.