Packing game resources
Author
hi friends
I'm working on a strategy type game, I use D3D9, of course I'm still working on art and technical aspects of the game, but I suppos I should consider some logical ways for packing my game resources, currently I have many 3d models, textures and sounds. What are my options? D3DX has some functions to read resources, what are these resources? how can I create these kind of resources? are these things dependable? what else can I do? any way for encryption and packing game content? please give me some clues, any samples or white papers would be appreciated.
thanks in advance
The resources that D3DX refers to are application resources, where the icon for your app and menu data is stored. It's not usually a good idea to store a huge amount of data there, since Windows has to deal with it when your app is loaded.
I have my own class for reading data from a pack file, which is my own format. All resources in the pack file are packed with either zlib or bzip2 and can have optional encryption.
When I want to load a resource, I extract it from the pack file and use E.g. D3DXCreateTextureFromFileInMemory() to create the resource using the unpacked data.
I have my own class for reading data from a pack file, which is my own format. All resources in the pack file are packed with either zlib or bzip2 and can have optional encryption.
When I want to load a resource, I extract it from the pack file and use E.g. D3DXCreateTextureFromFileInMemory() to create the resource using the unpacked data.
There is a cool little article on writing your own pak formats here. Like Steve, I also don't think it's a good idea to embed content within the executable, as it makes you rebuild the project after changing anything.
Quote:Original post by Evil SteveI have a similar system that I've used and I highly recommend it. I really need to get around to re-writing it and tidying it up, but the principle is sound.
I have my own class for reading data from a pack file, which is my own format. All resources in the pack file are packed with either zlib or bzip2 and can have optional encryption.
When I want to load a resource, I extract it from the pack file and use E.g. D3DXCreateTextureFromFileInMemory() to create the resource using the unpacked data.
It'd generally be regarded as a "virtual file system" - with relatively little effort you can abstract the source of your data (Memory, File, HDD, CD, DVD, Internet) support "install on demand", encryption and compression. It's also pretty easy to fit threading in as well (mine lacks this right now, but I want to implement it!)...
Have your code use some sort of static method like IVirtualFile* LoadFileFromVFS( const std::wstring& wsFilename ) or similar. This function can then instantiate the IVirtualFile from a more concrete type (e.g. specialization from each source - archive, DVD, Network..) and the code then deals with the file via an abstract interface. If your interface allows access to a raw pointer then you can pass it to the D3DX*FromMemory() type functions...
hth
Jack
From where it sounds like you're at in the development cycle, I'd recommend a simple directory structure, with just a wee bit of an interface over file loading to support the kind of virtual file system some of the other posters mentioned.
That way, when you need to, you can focus on things like packed files, etc., but you won't get bogged down in that now, when you more likely need to flesh out the game itself. But, you also won't be shooting your future self in the foot by having hard-coded everything to directly use files.
That way, when you need to, you can focus on things like packed files, etc., but you won't get bogged down in that now, when you more likely need to flesh out the game itself. But, you also won't be shooting your future self in the foot by having hard-coded everything to directly use files.
You could pack all your files into a RAR file. They do give away an unrar.dll with extraction capabilities (but no adding, which wouldn't be nessisary)
Considering RAR has a very good compression ratio mixed in with the ability to secure the file from editing (obviously it could only be so-so secure if someone REALLY wanted in), it is quite a nice format to use. I don't actually believe there are any particular license limitations for it's use, but I could be very wrong.
Edit: Upon looking into it, it is completely free and of no consequence to use the unrar library to extract rar files. Obviously you'd want to extract files as little as possible using this method (obviously) - but if that isn't much of an issue, it is worthy of looking into since RAR files are directory oriented so it'd be easy to toss into your code from the start.
Considering RAR has a very good compression ratio mixed in with the ability to secure the file from editing (obviously it could only be so-so secure if someone REALLY wanted in), it is quite a nice format to use. I don't actually believe there are any particular license limitations for it's use, but I could be very wrong.
Edit: Upon looking into it, it is completely free and of no consequence to use the unrar library to extract rar files. Obviously you'd want to extract files as little as possible using this method (obviously) - but if that isn't much of an issue, it is worthy of looking into since RAR files are directory oriented so it'd be easy to toss into your code from the start.
Quote:Original post by Flimflam
Edit: Upon looking into it, it is completely free and of no consequence to use the unrar library to extract rar files. Obviously you'd want to extract files as little as possible using this method (obviously) - but if that isn't much of an issue, it is worthy of looking into since RAR files are directory oriented so it'd be easy to toss into your code from the start.
As nice as using RAR might be, it's not as straightforward as just using the directory structure...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement