Elysian Shadows

I've been wondering how to (for lack of a better word) convert all of a games resources like the sprites, scripts and audio files to binary.

Thanks in advance.

Well, on windows there are resources, which (IIRC) allows a mini-filesystem inside of your binary. You could sort of mimic this on linux (ie. mkfs'ing a file and using some utility to open/read from that filesystem), but it's really up to you and whether or not you actually want it that way.

Could I also use something like zlib to compress a bunch of resources in one file, then load from that file?

maybe, but again you'd need some sort of filesystem-in a file. You could do a tarball, which would probably work.

If I'm understanding what you want to do, then you might want to read these:

http://www.gamedev.net/reference/articl ... cle825.asp
http://www.gamedev.net/reference/articl ... le1991.asp

Pretty pointless in my opinion since your program contains all the information on how to extract these files again. Not hard to write an unzipper with little assembly knowledge.

K-Bal wrote:Pretty pointless in my opinion since your program contains all the information on how to extract these files again. Not hard to write an unzipper with little assembly knowledge.

If done right it can save a lot of space, that alone seems like a solid point to me.

dandymcgee wrote:

K-Bal wrote:Pretty pointless in my opinion since your program contains all the information on how to extract these files again. Not hard to write an unzipper with little assembly knowledge.

If done right it can save a lot of space, that alone seems like a solid point to me.

Even if "done right" it doesn't save space in the RAM but only on the HDD. Actually you will use more RAM when both the zip file and the extracted files are in memory at the same time. Furthermore, if you develop for standard desktop computers memory shouldn't be an issue for most applications.

I just guessed with my map files

K-Bal wrote:

dandymcgee wrote:

K-Bal wrote:Pretty pointless in my opinion since your program contains all the information on how to extract these files again. Not hard to write an unzipper with little assembly knowledge.

If done right it can save a lot of space, that alone seems like a solid point to me.

Even if "done right" it doesn't save space in the RAM but only on the HDD. Actually you will use more RAM when both the zip file and the extracted files are in memory at the same time. Furthermore, if you develop for standard desktop computers memory shouldn't be an issue for most applications.

By "memory" did you mean RAM or hard drive space? The first would be countering your own point, and while the second may be true for small applications (as this surely is), it is still somewhat ignorant. I don't see any harm in learning conceptually how to save resources, which could be quite a big deal for a large-scale project.

Realtime data encoding and virtualization is among the fastest growing subfields of computer graphics. In many cases it saves both, there are multiple formats for both geometric and image data that do not need to be decompressed to be sampled. There are also multiple image formats that are compressions to save bandwidth. Trust me, when you start chunking around several dozen gigs of data around per second....compression and encoding become a BIG BIG deal.

I hardly see how this is anywhere near useless.

I was (unfoundedly) assuming the OP just wants to hide resources from 3rd party users. This is quite impossible because the application is already the key for decoding the data. This is what I meant with pointless.

And you guys are right, you can save both RAM and HDD when using streaming techniques, so I take back that statement. However, when decompressing a single chunk one will have both the compressed and the uncompressed chunk in memory at one time.

I'm not going to get involved in this argument, but I will say this.

If I understand you correctly, you are talking about something called serialization(donno if someone has already mentioned that), and I for one am in favor for it. Now I'm not going to comment on the things like speed and size, even though there are implications, more so for the prior. I will say that it does make it harder, not impossible, for people to get your resources, and or change em, and secondly, why I am in favor for it, is that it makes it much easier to deal with resources, there is some "pre backing" that takes place, but in the end you cut down the file interaction time significantly.

It's also a lot nicer to have something like (and the extension should say a lot) resources.WAD, then do have level1.bsp dude.png etc. for ever single resource.

Anyways, if nothing else, look into it for the experience.

On a semi germane note, Java has a fantastic serialization implementation.

avansc wrote: Anyways, if nothing else, look into it for the experience.

On a semi germane note, Java has a fantastic serialization implementation.

I'm also quite interested in this (for a couple of the mentioned reasons and, if nothing else, what you just said). Which one in particular are you referring to?

Java actually has a few, but the two main ones that will be of interest would be implements Serializable and implements Externalizable