Fun with zips
by Tom Bampton · 10/28/2006 (2:36 am) · 9 comments
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
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
About the author
Recent Blogs
• A Game in 2750 Days• GID23 and NPC Editor
• Fun with Lua
• How NOT to make a game
• Thinking Outside the Box
#2
These are all simple things to hack, though.
10/28/2006 (3:24 am)
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.
#3
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
10/28/2006 (9:35 am)
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
#4
10/28/2006 (1:59 pm)
Cool. But I crash when I try to save changes to the game? Just kidding. :P Very awesome.
#5
Yep, that would work. Might be a bit of a pain to manage but it is entirely doable.
T.
10/28/2006 (3:07 pm)
@Jeff,Yep, that would work. Might be a bit of a pain to manage but it is entirely doable.
T.
#6
10/28/2006 (3:13 pm)
Just out of my own curiosity, how would saving games and settings be done in a system like this?
#7
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.
10/28/2006 (3:48 pm)
@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.
#8
10/29/2006 (3:22 pm)
Is this going to be a resource ??? PLEASE! :)
#9
10/30/2006 (11:40 am)
Very interesting Tom, I'll have to take a closer look when I get the time. So all writes are disabled? No prefs then?
Torque 3D Owner Phil Carlisle
Sounds fun anyway.