VOGONS

Common searches


PhysFS patch

Topic actions

First post, by Guest

User metadata

Regarding the zip patch that moe made.

Its great!

However three slight ajustments i'd like:

1: If there is a directory mounted as a drive you can't mount a zip inside the "drive" as another drive. This could be default behavior of dosbox for files or also for directories (haven't tested it)

2: you can't drag and drop a zipfile into the dosbox.exe since dosbox refuses to mount a file.

3: A big one. I'd like that a special file is established in the dosbox directory for the case o f the mounting of zips that has (for example) the crc's of the zip file followed by the open files modifications only (in a format maybe like the diff program), that is persistant. A lot of work, and it merits some warnings about diskspace, but it would enable games that write to files, that can't possibly work with the way its implemented now.

Reply 1 of 100, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie
Anonymous wrote:

1: If there is a directory mounted as a drive you can't mount a zip inside the "drive" as another drive. This could be default behavior of dosbox for files or also for directories (haven't tested it)

Sounds reasonable. Will look at that, but QBix mentioned he'd rewrite the drives stuff, so I'll probably wait.

Anonymous wrote:

2: you can't drag and drop a zipfile into the dosbox.exe since dosbox refuses to mount a file.

Indeed, you can't just drag&drop it. You need to use the usual mount-syntax. (simple drag'n'drop simply makes no sense, as you'd be lacking a write directory - most games are useless witrhout one (saving...).

Anonymous wrote:

3: A big one. I'd like that a special file is established in the dosbox directory for the case o f the mounting of zips that has (for example) the crc's of the zip file followed by the open files modifications only (in a format maybe like the diff program), that is persistant. A lot of work, and it merits some warnings about diskspace, but it would enable games that write to files, that can't possibly work with the way its implemented now.

Not neccessary. If you like your collection organized that way, put all files into a subdirectory in the ZIP file and use one common write directory. Example: CIV.ZIP contains CIV\CIV.EXE (and all other data files in CIV\) with path. Then write accesses will go to directory CIV below your write location. Since each game has a different directory, all files are separated cleanly. I won't discuss about how exactly files are stored, it doesn't matter.

(note to some kind moderator: could you perhaps split this off into a thread in the patches section?)

Reply 4 of 100, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

It's an experimental feature that Moe is working on. It's probably not in CVS yet so you'll probably need one of his custom builds in order to test it out. I'm guessing you have to use some kind of mount command, similar to mounting an ISO or floppy image.

Reply 5 of 100, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

The "ZIP File Support" patch on sourceforge has detailed instructions, but it boils down to:

mount c c:\oldgames\write:c:\oldgames\civ.zip:/

i.e., simply mount <write directory>:<zip file>:<root in zip> - and if you need it, all other mount options work as well.

It may not be in CVS, but it isn't exactly experimental. It works great on my collection, no problems at all. Consider it decent beta quality.

Reply 6 of 100, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Some news: The patch works great with anything I throw at it, but it was a "little" slow with one game using a data file of some hundred MB. (Actually, I didn't have the patience to finish waiting for the game to load after half an hour of no visible progress.)

To fix that problem, I just submitted a patch to the physfs developers which makes random seeking in big compressed files really fast. Until it is accepted, you can patch your physfs yourself (should work with stable and developer release).

Using the patch, ZIP support in DosBox is again nearly as fast as uncompressed access (i.e., loading speed difference is noticeable, but barely)

Attachments

  • Filename
    index.diff
    File size
    4.29 KiB
    Downloads
    155 downloads
    File comment
    ZIP indexing support for physfs
    File license
    Fair use/fair dealing exception

Reply 7 of 100, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Hey Moe,

Let's say I have all of my DOS gams on CDR and decided to save a game. Would the Saved Games be stored in a location specified in DosBox.conf?

How To Ask Questions The Smart Way
Make your games work offline

Reply 8 of 100, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Read the documentation (on the sourceforge patch page). Basically, the mount command was extended to specify where written files are stored. So, in a way, the answer is 'yes'.

Reply 10 of 100, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Here's a question\suggestion that isn't in the documentation....

Okay, it's possible to specify another .zip as a CDROM drive, but AFAIKS it only parses data. Would it be possible to append .WAV files to the .ZIP (or possibly a seperate .zip with .WAV files) and then when the game wishes to use the Audio it could use that?

.MP3\.OGG support would be nice too.

Possible reasons for doing this:

Removing reliance on the original CD (CD's don't last forever and eventually the CD format will be unsupported in some long lost future)

Reduction in storage space required (Don't have to keep the original CD handy)

Drag n' Drop

Doesn't DnD only work on Win32? If so couldn't DosBox simply write the saves to the same place the dosbox executable resides?

For instance:

"dosbox ./:monkey.zip:" would store the save games in the same location as the dosbox executable.....or perhaps setting it to current drive root like old DOS CD games used to do with their saved games (they'd save them on C:\ root)....or perhaps a variable "dosbox %SAVE%:monkey.zip:".....or

just use a friggin' frontend. 😀 Still the ability to drag 'n drop DOS games which don't require extra drive mounts would be nice.

Last edited by DosFreak on 2005-09-16, 21:45. Edited 1 time in total.

How To Ask Questions The Smart Way
Make your games work offline

Reply 11 of 100, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Playing around with compression methods on this K63:

Deflate64 is extremly slow. 4D Boxing takes foreeeevver to load. Using just Deflate it loaded up just fine.

I was also able to get better compression than KZip using Deflate64 too, so either Physfs isn't compatible with that compression method or it's too slow for DosBox on this comp....which is odd since it compressed fast.

How To Ask Questions The Smart Way
Make your games work offline

Reply 12 of 100, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Played around with UPX today to reduce file sizes.....doubt I'm going to use it tho since I want to make a database of file hashes....I guess I could put both uncompressed and compressed hashes in there.....nah. Too much trouble for too little gain.

How To Ask Questions The Smart Way
Make your games work offline

Reply 14 of 100, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Drag'n'drop:

It's actually a side-effect of dosbox's command line syntax. There's nothing at all in dosbox to support "drag'n'drop", it's just that if you name an EXE file on the command line, dosbox mounts the dir the EXE is in and then runs it. Supporting Drag'n'drop with ZIP files would therefore mean adding yet another command line variant - or writing a custom shortcut: Create a shortcut for dosbox on your desktop, open it, and add "c:\your\saves\dir:%s:/" as command line args. (not 100% sure about the "%s", ask google if it's wrong) In a similar way you could add an entry "Run with DosBox" to the context menu of ZIP files.

Deflate64:

I actually wonder that it works at all, since AFAICT, there's no code to specifically support it. I guess that's more or less the reason that it is slow. I think zlib works with 32-bit offsets, so the indexing scheme is likely to fail (it's pure coincidence that it didn't break completely, really).

CD Images:

I am already thinking about how it would work best. Current CD-image code already supports OGG, so it's just a matter of getting those OGGs out of the zip file. I didn't tackle it yet, but sooner or later, I will.

Reply 15 of 100, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Drag 'n Drop-This brings up something I was thinking about in the DosBox Wish list. Mabye mountable .zips for DosBox should have a custom extension? Say .dcz (DosBox Compressed Zip) or somesuch?

I'm quite please with DosBox performance using .zip's on this 400mhz proc. Almost no diff from loading without using zips and the slight diff between different compression methods for .zip's to save space isn't really worth it to worry about, now implementation of say .7z would be much better but it's not really that big of a deal.

How To Ask Questions The Smart Way
Make your games work offline

Reply 16 of 100, by Targaff

User metadata
Rank Member
Rank
Member

Clearly .dbz is the one to go for, just for the silliness factor. Who cares that it clashes with a gzipped database extension - it's DBZ!

On a slightly more serious note, if a custom extension is going to be considered, I don't really see the point in having "compressed" in there if you have "zip" in as well - it's pretty much redundant, and even where it's not it's irrelevant.

Intel CC820 | PIII 667 | 2x128MB SDRAM | 3Dfx Voodoo 5 5500 @ Dell P790 | Creative SB PCI128 | Fujitsu MPC3064AT 6GB + QUANTUM FIREBALLlct10 10 GB | SAMSUNG DVD-ROM SD-608 | IOMEGA ZIP 100 | Realtek RTL8139C | Agere Win Modem

Reply 17 of 100, by prompt

User metadata
Rank Newbie
Rank
Newbie

@moe
I modified the cd image code to read the image files directly from the various dosbox drives some time ago. I guess that it will work with your zip drive too. There are still some bugs left, but as soon as I have fixed them, I will post the patch here.

@all
why not a simple 'DOS' as extension? 😀 (or is that already used?)

Reply 18 of 100, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

Well, don't count on me if you want to provide a custom extension. I just want to provide neutral ZIP support - free of any "warez distribution" nonsense allegations. I didn't add anything to make zips drag'n'dropable, to have configuration read out of a zip, to autostart something inside a zip, or to have a zip doubleclickable. It's intended to be plain ZIP support, and that's it.

So much for the official side. I really disagree with those people who equal "can run ZIP files" and "fosters illegal copying", but I also think that features should be left generic.

Now, if you really would like a one-file-one-click solution, rest assured that there is nothing more you need - plain dosbox plus my ZIP patch is enough! (Well, if you throw in my ADDKEY patch, things get a little more comfortable, and of course OpenGL-HQ is recommended as well 😀 )

When I feel like it, I might publish the multi-emulator menuing system (that I wrote for myself) as proof that all you need is already present.

Prompt, I'd really like to see your patch, as it's probaly the only thing which is left to be improved before I am fully satisfied.

Reply 19 of 100, by prompt

User metadata
Rank Newbie
Rank
Newbie

Ok, here is the patch I mentioned above. I didn't have time to test it with the zip drive. If you want to use cd audio other than binary together with the zip drive, you may want to install the development version of sdl_sound, since it can detect the length of a sound file much faster (I havn't tested this). This patch is not yet final, if you find bugs, please tell me or correct them yourself. Btw the iso drive has been modified to cache all accessed directory sectors, so lookups will be faster. It would be nice if someone could tell me if that is actually necessary.

Attachments