Sign in to follow this  

DLL resoruces or DLLs as resources

This topic is 4611 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I had this great idea to use a DLL as a resource archive for a small game. Small as in Tetris, Asteroids, Space Invaders type of games. I think it should also work well for larger games too. What you do is you make some simple resource handling functions that you export for the game's engine to work with. You pass identifiers to the functions as you would normally do with resources, and the functions should lock, load and finally return the resource to the engine. Simple, right!? You would make these function as more or less utilities because most of your resources may be different then the standard ones that the Win32 API already has built in functions for. Like bitmaps, menus and what not. Any ways, you could just change the extension to the DLL and the library functions should still work. I was thinking about changing the DLL extension to RES. The bad thing about this is that you have to recompile both application and DLL if you add a resource. But the good thing is that you will only have to recompile the DLL if you change a resource such as a bitmap. The whole purpose of this was to keep resources excluded from the actual executable and to try and bypass more of the file IO. I think file IO is expensive because of all the on-call anti virus systems and what not. So if you could keep this limited to just the DLL, you could probably bypass all of that. And if you write you're export functions good enough, you could even pass have them load the resource into DirectX or OpenGL memory space. You would just have to keep track of the interfaces you are using. But maybe the export functions could also keep track of that so that the game's engine would just call for resources as needed and the DLL you process the request and return, cleaning up if needed. Lastly, there should be a termination function that would release all resources the DLL had if allocated. It's just an idea though, so it still needs some thought. But what do you think? Cool eh!?

Share this post


Link to post
Share on other sites
No thats not really cool at all. Have you ever compiled a big project?! If I had to recompile everytime I added a resource I'd never finish anything! Its bad enough when I have to rebuild entire projects once a week let alone many times a day I could playing with resources. Nothin on ya, maybe it will work for you. Personnally I say roll your own format to pack things or use one of the popular availible libraries. And all that aside, That must be the least portable way you could possibly store resources!

Share this post


Link to post
Share on other sites
No offense, but this is not new at all, it has been done since... Window 3.11.
The cards for Windows' solitair are 'stored' in the cards.dll for instance.

Share this post


Link to post
Share on other sites
I think you've probably overestimated the cost of file I/O. Loading a DLL to memory requires file I/O, as well as OS-level management and bookkeeping, so it isn't exactly a "free" operation. For a large number of resources, it may "win" over individual files, but chances are it will not win by much - and it almost certainly will not win enough to justify the annoyance during development. If you load your resources wisely, file I/O is a one-time operation in most cases and certainly won't be performed often enough to be a speed issue at all. It also allows you to selectively load only the resources you need at any one time, which can be a pain if you're trying to use DLLs, as they tend to be rather all-or-nothing affairs.

As mentioned this approach becomes unmanageable very quickly. I'm currently working on a project with literally several gigabytes of assets (pre-compression and archival) and tens of thousands of resource files. (File I/O is not a performance problem at all, by the way.) Individual resources have to be tweaked and updated almost constantly - especially artwork resources. If the artists had to compile this into a DLL every time they made a tweak, it would slow down the development process to an excruciating crawl. Having multiple separate files allows for easy updating of the assets on the fly during development, and generally makes the entire operation a lot more convenient and flexible. Even for a small game like the examples you mentioned, this flexibility can be invaluable.

Share this post


Link to post
Share on other sites
It's kinda dangerous to hold resources in a DLL file. There is, or at least should be different handling of DLL files by OS, so it could in fact increase your memory requirements, and cause some other problems.
Resources stored in separate file are more easy to use.

Share this post


Link to post
Share on other sites

This topic is 4611 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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