bsnes/purify/purify.cpp

208 lines
5.5 KiB
C++
Raw Normal View History

Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
#include <nall/nall.hpp>
using namespace nall;
#include <phoenix/phoenix.hpp>
using namespace phoenix;
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
#include "resource/resource.cpp"
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
struct Application : Window {
library ananke;
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
VerticalLayout layout;
HorizontalLayout pathLayout;
Label pathLabel;
LineEdit pathEdit;
Button browseButton;
ListView fileList;
ProgressBar progressBar;
HorizontalLayout controlLayout;
Button selectAllButton;
Button unselectAllButton;
Widget spacer;
Button purifyButton;
lstring filenameList;
Application();
void scanPath();
void scanPath(const string &path, const string &basepath);
void purify();
} *application = nullptr;
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
Application::Application() {
application = this;
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
if(ananke.open("ananke") == false) {
MessageWindow::critical(Window::none(),
"Error: ananke was not found, but is required to use purify.\n\n"
"Please install ananke and then run purify again."
);
exit(0);
}
setFrameGeometry({64, 64, 720, 480});
setTitle("purify v03");
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
layout.setMargin(5);
pathLabel.setText("Path:");
browseButton.setText("Browse ...");
fileList.setCheckable(true);
selectAllButton.setText("Select All");
unselectAllButton.setText("Unselect All");
purifyButton.setText("Purify");
append(layout);
layout.append(pathLayout, {~0, 0}, 5);
pathLayout.append(pathLabel, {0, 0}, 5);
pathLayout.append(pathEdit, {~0, 0}, 5);
pathLayout.append(browseButton, {80, 0});
layout.append(fileList, {~0, ~0}, 5);
layout.append(progressBar, {~0, 0}, 5);
layout.append(controlLayout, {~0, 0});
controlLayout.append(selectAllButton, {100, 0}, 5);
controlLayout.append(unselectAllButton, {100, 0}, 5);
controlLayout.append(spacer, {~0, 0});
controlLayout.append(purifyButton, {80, 0});
setVisible();
onClose = &OS::quit;
pathEdit.onActivate = {&Application::scanPath, this};
browseButton.onActivate = [&] {
string path = DialogWindow::folderSelect(*this, userpath());
if(path.empty() == false) {
pathEdit.setText(path);
scanPath();
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
};
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
selectAllButton.onActivate = [&] {
for(unsigned n = 0; n < filenameList.size(); n++) fileList.setChecked(n, true);
};
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
unselectAllButton.onActivate = [&] {
for(unsigned n = 0; n < filenameList.size(); n++) fileList.setChecked(n, false);
};
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
purifyButton.onActivate = {&Application::purify, this};
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
void Application::scanPath() {
string path = pathEdit.text();
fileList.reset();
filenameList.reset();
scanPath(path, path);
selectAllButton.onActivate();
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
void Application::scanPath(const string &path, const string &basepath) {
lstring files = directory::icontents(path);
for(auto &file : files) {
if(
directory::exists({path, file})
&& !file.endswith(".fc/")
&& !file.endswith(".sfc/")
&& !file.endswith(".st/")
&& !file.endswith(".bs/")
&& !file.endswith(".gb/")
&& !file.endswith(".gbc/")
&& !file.endswith(".gba/")
) {
scanPath({path, file}, basepath);
} else if(
directory::exists({path, file})
) {
fileList.append(string{path, file}.ltrim<1>(basepath).rtrim<1>("/"));
filenameList.append({path, file});
fileList.setImage(filenameList.size() - 1, 0, {resource::game, sizeof resource::game});
} else if(
file.endswith(".fc") || file.endswith(".nes")
|| file.endswith(".sfc") || file.endswith(".smc")
|| file.endswith(".st") || file.endswith(".bs")
|| file.endswith(".gb")
|| file.endswith(".gbc")
|| file.endswith(".gba")
|| file.endswith(".bpa") || file.endswith(".zip")
) {
fileList.append(string{path, file}.ltrim<1>(basepath));
filenameList.append({path, file});
if(file.endswith(".bpa") || file.endswith(".zip")) {
fileList.setImage(filenameList.size() - 1, 0, {resource::archive, sizeof resource::archive});
} else {
fileList.setImage(filenameList.size() - 1, 0, {resource::file, sizeof resource::file});
}
}
}
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
struct PurifyContext {
lstring list;
unsigned position;
unsigned size;
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
void run() {
function<string (string)> sync = application->ananke.sym("ananke_sync");
function<string (string)> open = application->ananke.sym("ananke_open");
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
if(!open || !sync) {
position = size;
return;
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
while(position < size) {
string filename = list[position];
if(directory::exists(filename)) sync(filename);
else if(file::exists(filename)) open(filename);
position++;
}
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
PurifyContext(const lstring &list) : list(list) {
position = 0;
size = list.size();
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
};
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
void Application::purify() {
lstring purifyList;
for(unsigned n = 0; n < filenameList.size(); n++) {
if(fileList.checked(n)) purifyList.append(filenameList[n]);
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
if(purifyList.size() == 0) {
MessageWindow::information(*this, "Please select at least one file to purify.");
return;
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
layout.setEnabled(false);
OS::processEvents();
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
PurifyContext purifyContext(purifyList);
nall::thread purifyThread([&] { purifyContext.run(); });
while(purifyThread.active()) {
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
OS::processEvents();
unsigned position = ((unsigned)(double)purifyContext.position / (double)purifyContext.size * 100.0 + 0.5);
progressBar.setPosition(position);
}
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
purifyThread.join();
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
fileList.reset();
filenameList.reset();
progressBar.setPosition(0);
layout.setEnabled(true);
}
int main(int argc, char **argv) {
#if defined(PLATFORM_WINDOWS)
utf8_args(argc, argv);
#endif
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
new Application;
OS::main();
Update to purify v02 release. byuu says: purify has been rewritten. It now resembles the older snespurify, and lets you import multiple game files+archives and regenerate manifests for multiple game folders. It is also recursive. So you can now import all of your games for all systems at once, or you can update all of your bsnes v091 game folders to the new higan v092 format at once. Caveats: First, I am now using std::thread, so that the GUI doesn't freeze. Instead, you get a nice progress bar. Unfortunately, I was mislead and TDM/GCC 4.7 still does not have std::thread support. So ... sorry, but I can't compile purify for Windows. I am sick and tired of not being able to write multi-threaded code, so fuck it. If anyone can get it to build on Windows, whether that be by using Windows threads, hacking in std::thread support, skipping threading all together, whatever ... that'll be great. Otherwise, sorry, purify is Linux only until MinGW can get its god damned shit together and offers threading support. Second, there's no way to regenerate Famicom (NES) manifests, because we discard the iNES header. We are going to need a database for that. So, all I can suggest is that if you use bsnes/higan, keep all your iNES images around to re-import as new releases come out. Third, when you purify game folders, it will back up the ROM and RAM files only. Your save states, cheat codes, debug logs, etc will be wiped out. There's a whole lot of reasons for this, the most pertinent is that it's meant to clean up the folder to a pristine state. It also fixes the game folder name, etc. So ... sorry, but this is how it works. New releases rarely if ever allow old save states to work anyway. Lastly, I am not going to have purify contain infinite backward compatibility for updating manifests. You will want to keep up with purifying the collection, otherwise you'll have to grab older purify copies and convert your way along. Although hopefully the format won't be so volatile and this won't be necessary very often.
2013-01-17 11:19:42 +00:00
return 0;
}