Unpack PAK0 if you can... WOW !

[Gods Gift]

I unzipped the PAK file i.e. twice, from the zip and the gz, and the menu speed difference is amazing.  When I saw it load and the menu speed I LOL !!  I mean WOW I can't stress how much difference it makes.<br><br>Carpedium - Don't leave after all your good work.  I NEED a 'slightly' faster version to run on my E115.  After unpacking the PAK (and I know it shouldn't make a difference) suddenly the whole thing is playable, but a few more frames ...

[Moose or Chuck]

The game itself shouldn't run ingame faster because you unpacked it. But loading speeds would indeed be greatly increased.

[randall]

yeah, the gzip algorithm is pretty slow, but it does a great job at compression.

[999]

Yea, I mean ya gotta hand it to Dan, in following the Quake evolution on Brighthand, NOBODY ever mentioned a solution to storing the PAK files on your device.  This feat has really been sorely overlooked, or overshadowed I guess. <br><br>An FYI, I only keep the the pak0.pak file unGzipped, as it contains the game essentials like menu etc.  I keep the registered pak1.pak file Gzipped still, which cuts it's overall filesize in half (15+ megs).<br>

[Moose or Chuck]

Boy I love my 1 GB MicroDrive ;D

[Dr. Phat]

Ditto to that Moose!  I have all my MP3's, like 13 big programs, and LOTS of room for this!  

[Tommy]

Hi 999<br><br>I guy name Jerome need your help loading the registered Doom see the thread<br><br>http://www.pocketmatrix.com/cgi-bin/forum/welcome.pl?board=Pocketquake&action=display&num=200

[Dan East]

In case anyone cares, here's why the gzipped pak file is so much slower. A "pak" file is merely a conglomeration of many individual files and directories. It is not actually compressed - its sole purpose is to keep a whole directory tree and files in one single neat package. The pak file contains a lookup table (like a directory) that tells where each file is located (how far to seek into the pak to access that file). That is where the problem arises. Any compression algorithm is bad at seeking, because seeking requires 1, that you only seek forward, and 2, that you decompress as you go. The problem is that I doubt the pak file is optimized so that the files are in the order that they are loaded. If a file is requested that is located before the last read file, then gzip has to go back to the beginning of the file and decompress everything up to the start of the target file.<br><br>So, if a person were to modify a pak file so that the order of the entries were as Quake loads them, I would think that the loading would speed up exponentially.<br><br>Dan East

[Gods Gift]

Dan, thanks for the details.<br><br>Has Carpediem left the forum/development for good or is he still around?<br><br>I only ask as I'm salivating at the thought of squeezing a little more out of my frame rate.<br><br>Does any one have any thoughts on the best way of doing this using the config etc. or is there a new release on it's way (Please Carpedium make me happy!)<br><br>Quake still is arguably the best true deathmatch game available, especially online and to have it on my E115 !!!! Heaven.<br><br>Thanks fo all the work guys, you should be charging for this.

[randall]

I've always been irritated with id's PAK files- the fact that they seem to "hide" everything from me. So I was determined to get around it.<br><br>The PAK file is exactly how Dan explained it. But a little known fact is that it can be unpacked, and the game will run from those individual files and folders- without the aid of a PAK file. Which means the PAK file(s) can be deleted.<br><br>I pulled this off on my PocketPC. I can start PocketQuake and the main menu literally pops up 5 seconds later. A SinglePlayer game loads in 1 second flat. I AM NOT KIDDING!<br><br>Now, I have the option to add/remove individual maps, textures, models and sounds. You know, the stuff I don't necessarily need (like ALL 21 maps).<br><br>It doesn't increase FPS whatsoever, but we already knew this. It doesn't affect gameplay, or sacrifice visual quality.<br><br>A few tricks are involved to get this to work properly- which I discovered only by looking at the WinQuake source code.<br><br>Yeah, certain limitations exist. But for absolute control over my file system, it's a pretty good trade-off.<br>

[Moose or Chuck]

And randall, it isn't any larger in size on your device is it?<br>Now I need to find my own unpakker. I used to have one somewhere (hears sounds of shuffling paper). Nope, can't find it.

[randall]

Well, that's one of the limitations. It is around 17 megs unpacked. Pretty hefty in size. It loads like a bat outta hell. I dumped most of the maps and only kept the ones I play most often. <br><br>It's down to 8.5 megs now.<br><br>I can trim it down even further, but 8.5 megs is a good size. I can add/remove maps easily to maintain my free memory.<br><br>I'll unpack the Pak1.pak file and see how far I can trim it down later this afternoon. I used Qped 2- it's pretty easy to use.

[Dan East]

You guys can verify this for me, but you should be able to mix and match between pak, pak.gz, and extracted files. This is the order Pocket Quake searches for individual game files:<br><br>\quake\(individual unpaked files)<br>\quake\pak0.pak<br>\quake\pak1.pak (pak2.pak, etc)<br>\Storage Card(s)\quake\(individual unpaked files)<br>\Storage Card(s)\quake\pak0.pak<br>\Storage Card(s)\quake\pak1.pak (pak2.pak, etc)<br><br>If both a pak0.pak and pak0.pak.gz file exist in the same directory, then only the pak0.pak file will be used for that dir.<br>So, you can unpak select files, and leave the rest of the files in the .pak or .pak.gz files. PQ will find the unpaked files first and not touch the pak / pak.gz file (for that file). Or, a kind person could create a pak0.pak with only the basic menus, fonts, menu sounds, etc, and create a pak1.pak.gz containing the actual levels. Those using the registered pak1.pak could just name the file pak2.pak.<br>Note that PQ will use the source it finds first in the above search order. Thus if you have a decompressed pak0.pak on your storage card (or completely unpak the files), and still have pak0.pak.gz on your device (\quake\), then it will find the gz file first and use it. That obviously would not be the desired effect.<br>Is that crystal clear? <br><br>Dan East

[randall]

Yes it is VERY CLEAR as a matter of fact. The structure and order of preference is very similar to that used in the Quake2 engine. I used to mess around with Sin, Halflife and Quake2.<br><br>Indeed, you can mix and match in the manner you described.<br><br>I am not 100% sure about the order-of-preference. I know the unpacked individual files get preference above all else, like you stated (Dan). Sin's super-charged Quake2 engine preferred files in Pak2 over Pak1. This allowed updates to be included in the newest PAK file, thus ignoring previous versions of the file in the older PAK files.<br><br>Dunno if this is true for all Quake engines and PAK files, but it is easily verified. I'll check on this later.<br><br>Re-packing the files without the maps would be around 7 megs + or -. Gzipping would further reduce it to about 3.5 megs + or -. But then the slow load time would start all over again.<br><br>There is a slight catch to re-packing the file. It requires the something I found in the source code:<br><br>"\quake\id1\gfx\pop.lmp" must exist in order to use a modified PAK file. This seems to be the only way Quake verifies if the user has a registered version or not. For registered users, this file is in pak1.pak. Un-registered users, of course, do not have this file.<br><br>Unpacking that ONE file and putting it in "\quake\id1\gfx\", enabled me to have a registered version without the cumbersome pak1.pak. Dunno, how ethical this is but it works. How does this coincide with the free source agreement with id software?<br><br>All this pak0.pak.gz pak1.pak PAK stuff is kind of confusing unless you really know what the files do.<br><br>Peter packed a pack of pak1.paks; unpacking pak0.pak.gz packed packs of files in Peters iPaq. LOL

[Dan East]

You're exactly right about the pop.lmp file being the method Quake uses to determine if it should be "registered" or not. I noticed that today in the source code while I was verifying the search order. The registered version of that file is required to run a dedicated server, or play modified wads. I don't condone swapping that particular file, I'm just stating the obvious.<br><br>The search order I specified is exactly the way it is, based either on the way I implemented it (the gzip and CF card support), or the way it is originally written in the source (looks for un-paked files before looking in the .pak). Also, it searches the pak files numerically (pak0.pak then pak1.pak, etc). Based on the source, it is also possible to have an unlimited number of pak files as long as the sequence is not broken within that directory. So it would seem that you cannot have pak0.pak on your device, and pak1.pak on the CF card. The pak1.pak will not be found unless there is a pak0.pak on the card. You could have a pak999.pak, as long as pak files 0-998 are in that directory too. I need to modify the source to allow the pak number sequence to span directories.<br>Can someone verify that if you have pak0 on your device, and pak1 on the card, the pak1 file is not recognized?<br><br>Dan East<br>Last modification: Dan East - 03/07/01 at 19:01:24