I'm writing a hybrid 2D/3D game engine, and now that everything's working, I've suddenly decided that I want to have all of my files be in PAK files or something similar so that people can't just steal all of my music and bitmaps. Unfortunately, I've got no idea how to do this. Espescially since I'm loading my music with DirectShow, and the RenderFile() function only seems to take in actuall files. So what do I do? Do I decrypt and decompress everything at load time, then when loading is done, delete those files and keep the PAK file?

Quite frankly, I'm at a loss, I've got no idea what to do, and this doesn't usually happen to me. I'd also like to be able to not have to write a bunch of MP3 loading and BMP loading and PNG loading functions for my engine. Preferably just something that I can use as a fake file would be great.

Help anyone?

Your fear is mostly unfounded. Even if someone would steal your files, the derived works won't be too impressive.

Let's see. Check out the game engines for which source code has been released. How many new games have been designed based on those engines? I mean engines like quake, descent, etc.

Anyway, whatever 'pak' engine you choose (such as my CFL - http://iki.fi/sol ), it will be crackable since you're opening the files yourself anyway.

For a drop-in (commercial) solution, you could try molebox at http://www.molebox.com/

My main problem isn't with the file system, I can probably hack one together myself in a short amount of time. My main problem is once I have the data loaded in memory, how would I pass the data to say.... DirectShow for mp3 playback, or D3D for texture loading?

I don't know for DirectShow, but in Direct3D, if you have the content of a texture file loaded in memory, you can use the D3DXCreateTextureFromFileInMemory[Ex]() function.

Or you could use music system like FMOD (www.fmod.org) which includes file handling callbacks and setup them to your own VFS calls.

for dshow you can either write yourself a custom input node that reads out of your file, or you could try to use named pipes.

open one pipe that reads out of the pak-file and pass the pipe filename to the dshow functions. It could work, I see no reason why it should not work.

Any chance I can get a better explanation of this? This sounds fairly intriguing.

Input Nodes:

Start graph-edit and render a file. Graphedit will show you all components that need to be connected to render the file. That's exactly what happends when you call RenderFile, but you can see which filters are nessesary to render your videostream.

At the very left of the graph you'll find a module that just takes care about file reading and providing the data at it's output pin. You could remove that filter and use your own filter to do the file i/o. It's not an easy task to write such a filter, but it's also not impossible either. As far as I remember there are various directshow filter examples in the SDK. Maybe you can just take one of the example sources and modify it to your needs.

Named Pipes are the other alternative. They are fifo structures and not that different to files from a programmers point of view. You can create such a pipe and write to it. If you open the pipe from a different thread or program you can read from it just like you read from an ordinary file (they have a special filename, and you can't seek and set the fileposition, but that's it with the differences).

Pipes block. If you write to a pipe and noone is reading from it the WriteFile call might block till someone cares about your pipe. Some multithreading is nessesary if you want to work with them within one program. Otherwise you'll run into a nasty deadlock situation.

Since DShow is prepared to work with streams from net-sources I doubt that it would worry about the fact that it can't seek. Chances are good that it just works. You'll find all the nessesary stuff in the win32 SDK.

Why are you writing a game engine? Do you know how many are out there for FREE? Yours is probably gonna suck ass. Don't worry man no one will want to steal your stuff. You can leave it on the street and it'll be there a week from now.

Ouch, harsh words there. I do realize that there are loads of free engines out there. However, not many of them do exactly what I need them to do. Most of them would require me to pretty much entirely re-code their algorithms. Besides, how many graphics engines do you know are 2D only, but can still perform 3D lighting operations given only a z-map. Seriously, try and tell me that you haven't tried at one point or another to write an engine. It's good experience, and you could gain some valuable experience. Your argument is the equivalent of people complaining that they shouldn't have to learn math because a calculator can do it all for you. What happens when you don't have a calculator? See my analogy? Either way, the engine is mostly written now, and I wrote the dshow filter. Took forever, but good experience.