Project Deluge is an ongoing project to archive and assess all of the items featured in a lot of video game development material that has been gathered over the course of many years. This has been made possible through the dedication of only one extremely kind individual, who has taken on the herculean task of dumping every single thing in the lot by themselves.
Each item in the lot was assessed by a team of dedicated individuals for playability and integrity on both software (via emulation) and hardware when necessary. Each item was then lightly documented and given a general overview of some of the main interesting facts about the item in question.
|Iniche||Researcher / Lead / Catalogue|
|Jason Scott||Archive.org / Hosting|
|drx||Researcher / Script Writing|
|ehw||Researcher / Lead|
|Sazpaimon||Researcher / Script Writing / Streamer|
Last Updated: March 20, 2021
This part of the lot contains various miscellaneous assets, such as source code, press releases, screenshots, video clips, and backups. Assets can be for strictly media/publication use or can be developer backups. This section might be broken down if more is discovered.
(Last Updated: March 20, 2021)
Sony PlayStation 2 Prototypes
The majority of the items featured in this lot are mastered on recordable media such as CD-Rs and DVD-Rs that are prone to deterioration with time. The bulk of the items from this lot were dumped using either PowerISO and CloneCD using a Memorex MRX-650LE v6 AM61 CD/DVD drive and a PLEXTOR DVDR PX-716UF drive as well.
Discs that match finals, other released prototypes, and prototypes from the same lot.
(Last Updated: March 20, 2021)
1.) How can I help with Project Deluge?
Create an account on Hidden Palace and/or The Cutting Room Floor (TCRF) and help research the differences that can be found between each build and the equivalent final.
2.) Where do the items featured in Project Deluge come from?
Various defunct media outlets, developers, and odds and ends from various collectors over a period of time. Every single item in the lot is currently being archived from the efforts of one single person and evaluated by a group of dedicated individuals.
3.) What’s covered in Project Deluge?
Items that span across many console generations, from prototypes to various assets.
4.) I believe I found an error that can cause issues running a game, how do I report it?
See answer to #5.
5.) I found an error on one of the wiki page entries for an item in the lot, how should I correct it? Feel free to create an account on the wiki and make the necessary corrections. If you feel that a page needs to be renamed, please set up a redirect when moving the page so that the original page name can still be used to find the appropriate article.
6.) Is there a release schedule?
As this is an actively on going project, there is no tentative release schedule. As soon as the parts of the lot that can be sorted into a set are archived, processed, and documented, a release will be soon to follow.
7.) Where do final build dates come from? Where does release date information come from?
Final build dates are determined using the latest logical timestamp that can be found on the equivalent final. The timestamp is often found on the last modified file on the disc (as other parts of the metadata on the disc are often incorrect and post date the actual time the game was actually compiled/built). If timestamps are noticeably inaccurate, the next logical source for the date is used instead (such as the metadata). The final release data information was often sourced from GameFAQs which often lists more specific dates for various regions of the same game.
8.) What is a composite checksum?
A composite checksum is the sum of the checksums for all the readable files on a disc image. Checksums for individual files on a disc image are calculated using a checksum algorithm that isn’t susceptible to collisions. The individual file checksums are then added together to create a unique checksum value that reflects the files themselves, rather than the entire disc image file itself. This way, changes in the files on the disc can be indicated by changes in the composite checksum value when comparing similar builds based on the same title in the pursuit of finding matches. A composite checksum is useful in the event that changes on the disc image occur that do not affect the physical data on the disc, like metadata and mastering differences. It’s also useful for determining small changes in files if other parts of the disc are comparable to other builds (useful for determining watermarks).
9.) How are the items featured in the lot evaluated?
A custom tool was used to generate metadata from each disc from various data sets, such as composite checksums, main executable checksums, volume modification dates, disc metadata etc. The collected data is then gathered into a single spreadsheet where the same information that can be taken from the items in the lot can be compared to. If the composite checksum of an item in the lot matches against a data generated from a non pre-production part of the Redump set, then the files on that particular disc is the same as a final build. If the main executable checksum matches the main executable checksum from one of the data sets but the composite checksum doesn’t match, the item would then be manually checked against the partially matched builds to determine what differs between the builds. This is where builds that were watermarked, builds that have small inconsequential changes (like a small change in SYSTEM.CNF for PlayStation builds), and builds that contain obvious errors can be identified. These changes have been documented in the subsequent matched build pages for each system in the lot. The changes mentioned on these pages are enough to replicate the alterations that make up the build perfectly. If none of the data assessed from the item matches any part of the collected data sets, then that particular item is classified as non-final.
10.) I want to research a particular item from the lot, how should I go about sharing the information I’ve discovered?
See answer to question #1 and #5.
11.) Are the items in the lot free from errors or defects caused during the archival process? There are no guarantees that each dump is free from errors. All the prerelease items were often authored on recordable media that was not meant to last indefinitely. For older items, especially ones authored on recordable optical media, the items were often mastered using duplicators that introduced further errors that could have been baked into each copy of the duplicated disc. Normally we would archive discs using the best methods available, but given the circumstances surrounding the lot itself, this wasn’t readily available in time for some of the items in the lot. We attempted to rigorously test and analyze each disc and note errors wherever possible. As such, we would rather have some dump than no dump at all.
12.) How were disc errors determined?’’
After determining that an item in the lot is producing a unique checksum value that doesn’t match anything on Redump or on our wiki, if copies of an item exist in the same lot - errors can be determined by comparing where the changes lie between the two copies. If one copy is filled with filler bytes due to the drive not being able to read sectors, then that copy contains errors. If the item in the lot is an optical disc using ISO 9660 (such as CD-Rs), errors can be determined by checking the EDC/ECC data written with the data on the same disc. For these, we used an open source tool called edccchk, an EDC/ECC checker for RAW (2352 bytes/sector) CD images, to locate and interpret errors. If the errors are correctable using the included data or that the errors in question do not directly affect the files on the disc, then the item is good enough for release.
13.) How are items with protection handled?
If an item is determined to be utilizing protection (such as ‘dongle’ protection), we made attempts to create an .xdelta patch so you can patch the protection out of the original dump. To apply an .xdelta patch, you can use a tool like Delta Patcher on the original image.
14.) Why are there multiple copies of a particular item in the same lot?
Most review and preview builds aren’t mastered with unique builds and were usually produced in mass and sent to various media outlets. The only thing that can be unique between each copy is certain metadata and/or changes to help identify a build. These changes have been documented in the subsequent matched build pages for each system in the lot.
15.) What hardware and software was used to archive the items in the lot?
For disc images, a combination of PowerISO and CloneCD was used to dump every CD/DVD in the lot initially. A Memorex MRX-650LE v6 AM61 was primarily used to dump everything with a PLEXTOR DVDR PX-716UF 1.11 used as a backup. More drives have since been acquired.
16.) Why do some builds post date the final release?
This is not exactly known and the reasons can vary depending on the game. If the item in the lot is a build that predates a certain release but post dates others, then that build can be determined as a ‘localization’ or in progress revisional build. Some final builds were possibly altered to include protection so that they could only function on certain console models (like developer consoles). In some scenarios, the build could also be an unreleased second revision.
17.) Why do some of the filenames in the lot have the wrong identifier/system (i.e “PSX” when the item is meant for “PS2”)? Some of the items in the lot were initially misidentified by the archiver for a certain system (usually because the game in question was a multiplatform release). Due to the process of evaluating the items in the lot, we had to leave the original identifiers in.
18.) Were there some items that couldn’t be archived? What’s going on with them? At this point there are a few things in the lot that could be only partially archived due to the state of the media itself. We’re in the process of redumping those items and will try to get them out in the future. If a successful dump cannot be made, we will release the best possible dump and make note of it.