Suggestion! - Achive compatibility!
Moderator: ScummVM Team
Suggestion! - Achive compatibility!
Hi All
Ive had an idea.
I was zipping up my data files to save space and thought to myself:
"Wouldnt it be great if ScummVM would be able to open these archives so I dont have to extract them each time!"
Some emulators do it, so it is possible (at least on the pc version).
I think it could also be beneficial for some mobile devices that have little space.
Ive had an idea.
I was zipping up my data files to save space and thought to myself:
"Wouldnt it be great if ScummVM would be able to open these archives so I dont have to extract them each time!"
Some emulators do it, so it is possible (at least on the pc version).
I think it could also be beneficial for some mobile devices that have little space.
You're incredible. You're hanging around ScummVM for quite long time, and still you haven't bothered to read FAQ. It is there, specifically mentioned to avoid such requests from newbies.PsYcO wrote:i think its a good idea
Eugene
PS. I think I should spend some time and write a CAPTCHA for new message posts which will ask questions based on FAQ and README, as well as Forum Rules. <sigh>
well in honesty ive never needed to look at the faq, cause ScummVM runs so well i rarely have any problems with itsev wrote:You're incredible. You're hanging around ScummVM for quite long time, and still you haven't bothered to read FAQ. It is there, specifically mentioned to avoid such requests from newbies.PsYcO wrote:i think its a good idea
though here's a thought, why not create a post with knocked down suggestions and stickying it? that way you don't have to deal with so much ignorance
you can look at rejected feature request items on the trackerPsYcO wrote:well in honesty ive never needed to look at the faq, cause ScummVM runs so well i rarely have any problems with itsev wrote:You're incredible. You're hanging around ScummVM for quite long time, and still you haven't bothered to read FAQ. It is there, specifically mentioned to avoid such requests from newbies.PsYcO wrote:i think its a good idea
though here's a thought, why not create a post with knocked down suggestions and stickying it? that way you don't have to deal with so much ignorance
you also can use the search function of the forum (where the archive thing has already been discussed ad nauseum)
... or we could create one more page we need to update which nobody will read anyway (c'mon, if people don't even read the FAQ, they'll read something like "list of things you should not request"? For a lot of users even the forum rules are too much a hassle to read)
-
- Posts: 28
- Joined: Mon Nov 28, 2005 12:10 pm
I read the faq before, and I still think it's a good idea to implement support for archives.sev wrote:You're incredible. You're hanging around ScummVM for quite long time, and still you haven't bothered to read FAQ. It is there, specifically mentioned to avoid such requests from newbies.PsYcO wrote:i think its a good idea
There is no reason to think this would cause more warez. If you download a game in .zip format you just unzip it and you can play it in scummVM. Do you really think the not-supporting-archives politic stops warez in scummvm? I don't!
this is open source, nobody prevents you from forking and implementing that yourselfMetalSnake wrote: I read the faq before, and I still think it's a good idea to implement support for archives.
There is no reason to think this would cause more warez. If you download a game in .zip format you just unzip it and you can play it in scummVM. Do you really think the not-supporting-archives politic stops warez in scummvm? I don't!
deja vu:
http://forums.scummvm.org/viewtopic.php ... ip+support
http://sourceforge.net/tracker/index.ph ... tid=418823
http://sourceforge.net/tracker/index.ph ... tid=418823
http://sourceforge.net/tracker/index.ph ... tid=418823
http://sourceforge.net/tracker/index.ph ... tid=418823
*sigh*
The other day i had an idea similar to this but without using the normal archive process, I think the main want in this issue is reduced file size and a unified file to ease copying to a memory card or such storage device. While allowing zips/rars/etc. to be supported natively would make it easier for pirates perhaps there is another option...
So here is my idea...
The other day i was using extract_scumm_mac on my copy of Day of the Tentacle for macintosh and the idea occured to me... Could this process be reversed?
For those that are unaware of what extract_scumm_mac does: It is used to extract the base datafiles (*.lfl, *.000, monster.sou, etc) from the singular Datafile used by the mac versions. These days the app. is less neccisary as those unifiyed datafiles are now supported natively within ScummVM but in at least one case (extracting MM from DOTT)it is neccisary to get all the game offers. Anyways back to the idea ...
So what i was hoping is perhaps adding a tool based on "extract_scumm_mac" but reversed to be something like "build_scummvm_data". This would take the games idividual datafiles and unify them into a single readable datafile for the entire game. This approach may answer the want for an easyier to copy single datafile and could potentially allow for the unification of pre-compressed files if the profiles for Ogg/MP3 compressed datafiles are included into the app's parameters. There would of course (at least initially until some sort of detector is built in) need to be command line arguments to specify what game to build and what type of datafiles to look for ("build_scummvm_data -COMI -Ogg" = "COMI_data_scummvm_C" whereas the "C" means compresseed)The additional benifit of this is it wouldnt be restricted to just the scumm titles but potentially the other supported ones like BS1/2, gobliiins, etc.
This is just an idea but it does seem to address the supject of compressed datafiles without making it too easy, people will need to take the time to do the compression and then build thier datafile. That being said... i am unfamiliar with the logistics of how ScummVM approaches using the Mac datafiles, doing such a thing with a game with a large amount of data like COMI might cause a huge memory drain making it more trouble than its worth.
Once again, who knows, its just an idea. What do you guys think?
I was originally going to write this to -devel or to the feature request tracker (which i am still willing to do if requested) but i though since this discussion is happening yet again i might as well post it here
So here is my idea...
The other day i was using extract_scumm_mac on my copy of Day of the Tentacle for macintosh and the idea occured to me... Could this process be reversed?
For those that are unaware of what extract_scumm_mac does: It is used to extract the base datafiles (*.lfl, *.000, monster.sou, etc) from the singular Datafile used by the mac versions. These days the app. is less neccisary as those unifiyed datafiles are now supported natively within ScummVM but in at least one case (extracting MM from DOTT)it is neccisary to get all the game offers. Anyways back to the idea ...
So what i was hoping is perhaps adding a tool based on "extract_scumm_mac" but reversed to be something like "build_scummvm_data". This would take the games idividual datafiles and unify them into a single readable datafile for the entire game. This approach may answer the want for an easyier to copy single datafile and could potentially allow for the unification of pre-compressed files if the profiles for Ogg/MP3 compressed datafiles are included into the app's parameters. There would of course (at least initially until some sort of detector is built in) need to be command line arguments to specify what game to build and what type of datafiles to look for ("build_scummvm_data -COMI -Ogg" = "COMI_data_scummvm_C" whereas the "C" means compresseed)The additional benifit of this is it wouldnt be restricted to just the scumm titles but potentially the other supported ones like BS1/2, gobliiins, etc.
This is just an idea but it does seem to address the supject of compressed datafiles without making it too easy, people will need to take the time to do the compression and then build thier datafile. That being said... i am unfamiliar with the logistics of how ScummVM approaches using the Mac datafiles, doing such a thing with a game with a large amount of data like COMI might cause a huge memory drain making it more trouble than its worth.
Once again, who knows, its just an idea. What do you guys think?
I was originally going to write this to -devel or to the feature request tracker (which i am still willing to do if requested) but i though since this discussion is happening yet again i might as well post it here
Fortunately the archive would work on more than just a mac, the extract_scumm_mac app is just a framework for my idea. Nonetheless scummvm allows you to play the mac games on other systems so that point is a bit moot.
The point is to attempt to address the possibility of Datafile compression and unification without using a standardized container like iso/zip/rar therfore not making it easier for piracy
And to awnswer your last question: No scummvm is not a huge help, you really need to read the FAQ and the forum rules. Piracy is neither supported or endorsed by scummvm, some irresposible users have misused the app the same way a bad person misuses a gun. ScummVM is a tool, a fantastic one, it is up to the users how to use that tool.
These comments about how helpful scummvm is to piracy do *no* good for the project. I personally would like to see scummvm exist for the rest of my days and always be able to play Monkey Island 1. I wish people would please stop jeopardizing that.
The point is to attempt to address the possibility of Datafile compression and unification without using a standardized container like iso/zip/rar therfore not making it easier for piracy
And to awnswer your last question: No scummvm is not a huge help, you really need to read the FAQ and the forum rules. Piracy is neither supported or endorsed by scummvm, some irresposible users have misused the app the same way a bad person misuses a gun. ScummVM is a tool, a fantastic one, it is up to the users how to use that tool.
These comments about how helpful scummvm is to piracy do *no* good for the project. I personally would like to see scummvm exist for the rest of my days and always be able to play Monkey Island 1. I wish people would please stop jeopardizing that.
im not discussing warez, im discussing the notion that the only reason archives arn't supported is cause it aids piracy, it doesn't no more than scummvm does it self. every corner of the market has piracy issues, and currently there is no actual stopping tool. ignorance is not bliss, simply hoping it doesn't exist is silly.glokidd wrote:And to awnswer your last question: No scummvm is not a huge help, you really need to read the FAQ and the forum rules. Piracy is neither supported or endorsed by scummvm, some irresposible users have misused the app the same way a bad person misuses a gun. ScummVM is a tool, a fantastic one, it is up to the users how to use that tool.
These comments about how helpful scummvm is to piracy do *no* good for the project. I personally would like to see scummvm exist for the rest of my days and always be able to play Monkey Island 1. I wish people would please stop jeopardizing that.
and regular users should not be effected by those who choose to steal copyrighted material. nero doesn't cap how many cd's you can burn a month does it? nor does toast it
There is actually an argument which kind of defeats the "helping piracy" one - ScummVM comes with a compression tool to compress the MONSTER.SOU files to OGG or MP3 format.
How is compressing that down from 200+MB to 90MB (game and compressed audio quality depending) any different from supporting archives?
You're still archiving the data, making it smaller and easier to move around, which makes it easier to copy, using the logic of archiving the games.
If you're going to provide the tools for compressing the single largest elements in the game (sound & music, especially speech), you might as well allow compression of the remainder of the game since it won't make much of a difference to a pirate (you know, whether they have to wait 4 or 5 minutes to download a game)
How is compressing that down from 200+MB to 90MB (game and compressed audio quality depending) any different from supporting archives?
You're still archiving the data, making it smaller and easier to move around, which makes it easier to copy, using the logic of archiving the games.
If you're going to provide the tools for compressing the single largest elements in the game (sound & music, especially speech), you might as well allow compression of the remainder of the game since it won't make much of a difference to a pirate (you know, whether they have to wait 4 or 5 minutes to download a game)
counter question - why does it make such a great difference to you if your game comes in one or in ~three files? (I see your point with games that come in 1,000 files, but that's the minority of games)Arantor wrote: If you're going to provide the tools for compressing the single largest elements in the game (sound & music, especially speech), you might as well allow compression of the remainder of the game since it won't make much of a difference to a pirate (you know, whether they have to wait 4 or 5 minutes to download a game)
in your initial post you talk about devices with little space - most current devices come with some kind of solid state media slot with gigabytes of storage - and no, compression won't reduce the amount of RAM needed (the real bottleneck) to play the games
oh, and why not stop there - there have been 2 posts about how to load ISO files into ScummVM within the past 24 hours - would save us much hassle if ScummVM supported that, too (yeah, I'm sure there are legit users out there who save their CDs as ISO files on their HD, and for the pirates it doesn't make much difference if they download and play, or download, burn, copy and play (or mount))