Prev/Next Blog
by date

Fun with zips

Name:	Tom Bampton
Date Posted:	Oct 28, 2006
Rating:	3.0 out of 5
Public:	YES
Comments:	YES
RSS Feed:	or Subscribe with .
Profile Page:	View profile page for Tom Bampton

Blog post

As some may know, I maintain a "useless todo list." This list includes all the mostly useless things I intend to do someday, maybe. The problem with the useless todo list is that whenever I end up actually doing something on the list, it turns out to be useful.

One such item is the Torque zip code. I've been meaning to rewrite it for years. Since I am taking a break for a few days to recover from transatlantic travel, I figured I may as well mess around with the zip code.

So to cut a long story short, and get right to the interesting bits, the new zip code supports multiple compression methods (Deflate and BZip2 for now), the old Zip2.0 encryption and WinZip's form of AES encryption. It's also now a seperate library (well, kinda) so it can be used from outside the resource manager easily.

After completing the new zip code, I met with a problem. What to use it for? Clearly, the only sensible course of action was to zip up everything the game needs (including all mods and the top level main.cs) and run it straight from one big zip as a virtual file system. But wait! If I'm going to run it from one big zip, I may as well put the zip in the .exe. Then all I need to play the game is one file.

Since it's a bit hard to post screenshots that show this off, I'll just upload a build instead.

Stock tutorial.base, Win32 only, ~3.5MB

Recent Blog Posts

List:	08/20/07 - GID23 and NPC Editor 07/25/07 - Fun with Lua 06/11/07 - How NOT to make a game 11/18/06 - Thinking Outside the Box 11/03/06 - Alive and Ticking: Now with exploding ants 10/28/06 - Fun with zips 10/02/06 - Alive and Ticking gets to Beta .... err, almost. (Warning: Screenshot Heavy) 09/08/06 - Internal Name Operator

Submit your own resources!

Phil Carlisle (Oct 28, 2006 at 10:19 GMT)

Hmm... so does the override-file-by-sticking-it-in-a-directory functionality still work? or would the files need to be stuck into the zip?

Sounds fun anyway.

Tom Bampton (Oct 28, 2006 at 10:24 GMT)

Nope, it bypasses mod paths altogether. Everything in the zip is available and setModPaths() is ignored. Also all writing is disabled so you can't produce DSOs.

These are all simple things to hack, though.

Jeff Loveless (Oct 28, 2006 at 16:35 GMT)

Would it be too much work, from this codes current state, to have seperate archives, one for images, one for sounds, one for music, one for models, one for etc... ? and leave them outside of the exe?

That is cool though, I've been wondering about maybe slipping some bitmaps or something into the executable for things that you would maybe want to make off limits for modding.

edit:typos
Edited on Oct 28, 2006 16:37 GMT

Anton Bursch (Oct 28, 2006 at 20:59 GMT)

Cool. But I crash when I try to save changes to the game? Just kidding. :P Very awesome.

Tom Bampton (Oct 28, 2006 at 22:07 GMT)

@Jeff,

Yep, that would work. Might be a bit of a pain to manage but it is entirely doable.

T.

Unsung Zero (Oct 28, 2006 at 22:13 GMT)

Just out of my own curiosity, how would saving games and settings be done in a system like this?

Tom Bampton (Oct 28, 2006 at 22:48 GMT)

@Unsung Zero,

It kinda depends on the use it's being put to, so here's a general overview.

Most of the things that stop it writing are actually done in script. There is an isUsingVFS() console function to check whether you're running from a VFS. The top level main.cs uses that to disable .dso creation and the console.log. I also hacked the resource manager to not let you write to files if it's running under a VFS, but that could easily be moved out to the top level main.cs also.

So, in essence, this works (or can work) exactly like normal Torque, it's just everything is in one executable.

One thing I had been pondering is storing the prefs etc within the executable itself. The code to do that is pretty simple in theory, but is likely complicated by Windows locking the executable that's currently running. I am not sure if there's a simple solution there or not.

Other then that, I'm not really sure there is any way to cleanly deal with saving prefs/games without writing files to the file system. If this is used for small demo purposes, I dont think that's a bad thing (and that's why I just temp-hacked the resource manager to refuse to write files). If it's used for a full game, then writing files to the file system is probably OK and thus a non-issue.

T.

Alienforce (Oct 29, 2006 at 23:22 GMT)

Is this going to be a resource ??? PLEASE! :)

Brian Ramage (Oct 30, 2006 at 19:40 GMT)

Very interesting Tom, I'll have to take a closer look when I get the time. So all writes are disabled? No prefs then?

You must be a member and be logged in to either append comments or rate this resource.