Willing to try it I suppose. A lot of the trouble is finding the games in the first place. For that, I am going to need people in Europe and Japan who can scour game shops, build up small bundles and ship them internationally all at once. Many of them will be very, very hard to find at all.
I agree with you completely. Read up on what Rufus Pollock, a Harvard professor found after doing research on copyright. The optimal length is 14 years, of which all SNES games have passed. Anything longer is corporate greed.
As far as letting someone read them, that is exactly why I bought them in the first place. I read every one by hand with my own custom hardware (here is a picture of my setup.) This allowed me to image the entire function of the PCB, not just the ROMs like current dumps. I also scanned every box, cartridge and PCB. I then put up all the information in my online database here. I can't distribute the ROM images for legal reasons, but by comparing my SHA256 hashes to yours, you can verify your ROMs are legitimate and unmodified, clean dumps.
About a dozen were unfindable, I had to trade three of mine to get unfindable boxes, too. The rest were unaffordable. I completely maxed out my 401K loan, and my savings are empty. I can't continue buying until this set sells. Otherwise I would have loved to have listed it as a 100% CIB set. Probably could have made 50K just from some rich person not wanting to spend a decade searching. Note: only one person in the world is known to have a 100% CIB US set, DreamTR.
The PCB contacts were scrubbed with sodium hydroxide (to remove oxidation) and isopropyl alcohol (to remove residue.) Took about five minutes per cart. Which is about 60 hours of labor. Not a whole lot, it just ensures that every game will turn on with your very first try, and you won't dirty up your SNES connector on these carts.
It's a licensed retail only set. Donkey Kong Country Competition was another game sold only after a Blockbuster competition. Mountain Bike Rally + Speed Racer was another game that was only sold by mail order for $200 after you bought a $4,000 exercise bike. Noah's Ark 3D was an unlicensed game sold in Christian book stores. MACS was a training game designed for use in the US military. Powerfest '94 and Campus Challenge '92 were produced for their respective competitions, and were supposed to be destroyed (two of each were not.) SNES tester decks existed only inside Nintendo repair centers. This can pretty much go on forever, so you have to draw the line somewhere. However, many can legitimately say it's not a complete set if their definition includes any of the above.
The thing I disliked most was the way emulated images do not come with any box art or instruction manuals. That was always part of the fun as a kid for me.
Ironically, you can consider my effort to be undermining the very value of owning the set: I've scanned all of this stuff in at high resolution so it'll be available long after the games are gone. That's why I bought them in the first place. I'm only selling them so I can buy more games from other regions to do the same.
I am probably underselling myself here, but I would likely accept the first serious offer for $20K or above.
That may seem like a lot, but if you do completed auction searches on eBay, you will see that the top dozen or so games (EarthBound, Hagane, Harvest Moon, Incantation, Aero Fighters, 3 Ninjas Kick Back, Metal Warriors, Mega Man X3,...) routinely sell for $400-1000 a piece when complete in box. The next four dozen easily command $100-350. That leaves you with about $5 per complete in box game for the rest, in a market where the prices have continued to rise steadily for the past several years.
MESS is great for the obscure systems, but not very good for the popular ones. I suppose that much is obvious. A great site I found for this was http://nonmess.retrogames.com/... its author compares MESS against other emulators and documents whether or not MESS is the superior option.
Ah, tepples. Always the pedant. bsnes has a Vsync feature. You could also argue that resampling the audio to get smooth audio+video at the same time is not accurate, and you'd be right. Except for the fact that perfect video+audio sync without doing that is impossible on modern hardware. So I guess there's no such thing as an accurate software-based emulator:P
The default key binding for fullscreen is F11. You're right that it's not a 'true' fullscreen, which I don't do because mode setting changes take forever and only reliably work on Windows. That and they break the UI (you can't display windows, menubars, etc anymore.) However, Vsync works just fine so long as you turn off the garbage Windows compositor (it does not move the Vsync time like OS X, so using it basically guarantees tearing as the compositor and D3D/OGL app fight for who blits first.)
Trust me, you really, really don't want a low-level PS2 emulator. It would be a great thing to have made now for documentation purposes (so that the knowledge is preserved while it's still easily accessible), but it wouldn't run full speed on anything released in the next 40-50 years.
Does a hate crime conviction even matter (eg does it mean anything, or have any teeth), when that in addition to *14* other counts gets you a whopping 30 days in jail? That's not going to serve as a deterrent to anyone.
... wow. The reason PGO is so nice is because it reorders your human-readable code into something faster.
Assume a switch with eight possible cases, and non-linear indices that do not allow for a simple jump table optimization. Two of them may be vastly more common than the other six, and PGO can take them out of the switch, or reorder them to the top. You can also do this by hand, but it will make your code messier and harder to maintain.
Or take the frequency of code execution. Two routines may execute a lot, so they are stuck together in memory to aid in caching. But it may make no sense to have these two functions anywhere near each other... say they are from two entirely different classes.
PGO also frequently decides when to inline things or when not to, and even telling the compiler when to inline isn't guaranteed. You'd have to resort to compiler-specific attributes (always_inline/__forceinline.) And the list goes on and on.
Taking your argument to the extreme, hand-writing your code in pure assembler can get you even more speed, and now you don't even need -O3 for decent speed. But there's a reason people use high-level languages. PGO is just one more tool to make your code more stable and easier to maintain.
It has little to do with reading the contracts. The problem is that if you want a good white collar job, you need a cell phone. And if you want a cell phone, every last service provider has the same clauses. Reading the clause won't help, as unfortunately most people don't care about their privacy. The providers won't care even if they did lose 0.1% of their customer base if the spyware gained them +10% profits.
One of the worst trends in computing is trying to make real-world analogies to everything. Who cares what the real top of your desk looks like? Your desk is not a personal computer, and vice versa.
My Intel Atom @ 1.6GHz can get 80fps, so yes, it's most definitely a configuration issue. Or perhaps he is using the accuracy profile. I really need to be more clear on the downloads page about the performance of the three profiles.
My first PC was a 25MHz 486SX. You will have a PC fast enough for bsnes one day. In fact, you can get such a system for ~$100 used today. And then you can play every game you care about, and every game that people other than you care about as well. Whereas you probably won't be using ZSNES on your new Windows 10 box that lacks 32-bit run-time libraries.
Anyway, something else is wrong if 2.5GHz isn't enough for you. But it doesn't seem like you are interested in troubleshooting, so no worries. Sorry that my software gave you a hard time.
Without double-checking the list, I can tell you right now that Wild Guns has hacks in most emulators.
That game will trigger a DMA past the end of NMI, and immediately toggle NMI on the next instruction for unknown reasons. Because of a hardware edge case, the NMI status is cached one cycle sooner than the next opcode.
Only bsnes and Super Sleuth simulate that delay, the rest hack around it. Without either, the entire in-game screen would flash between the real image and garbage every other frame.
The library is still in progress re: memory management. Right now the idea is that the UI elements won't eat all that much memory, so why waste time with allocation/deallocation? You can of course use pointers anyway, and delete them whenever, but at the moment it'll be your responsibility to ensure they were no longer in use or bad things will happen. I'll add destructors that remove widgets from containers and such in a future release.
I use my own string class because std::string is garbage. No token replace (eg replace all 'cat' with 'dog'), no tokenize string (split, explode on key), unsafe find/strpos return value on non-matches (boost::optional works much better and throws exceptions when abused), no char transform (PHP strtr), no case-insensitive find, no support for parsing quoted strings (think split on = in a config file, quoted parameter may have = that we want to ignore; or think any kind of scripting/assembly syntax's strings), no math parsing (tell me what "3+2*7+4" equals), has to create a new object to be compatible with the native char* type of the language (c_str()), formatting with ios is torture, and building streams is a pain (no return { "My name is ", name, ", and I am ", age, " years old.\n" }; or openFIle({ baseFileName, ".txt" });) - it prefers the nonsensical operator left-shift over using traits to allow the more natural +, on and on. I could write a book on this class alone.
I have my own function class because std::function sucks at binding to member function pointers. You have to mix memfn/bind1st in odd ways, and when you get above one parameter I can't even figure out how to use it anymore. With mine: onClose = &globalFuncOrMemberStaticFunc; onClose = { &Class::MemberFunc, &classObject }; onClose = [this]() { closure(); }; can also attach to boost::bind for argument shuffling.
My version of optional is so you don't need boost to use it, and is four lines long. And that's it. The only thing you are ever exposed to is my string class on some return values, which is castable to and convertible from const char*, so pretend it's that and use with std::string if you like.
Thank you kindly for testing that for me. The numbers are at least twice as good as Qt, and GTK+ is DLL city. And yeah, ten years will do that to a project. I have noticed the run-time sizes going up with each new release of Qt. Also agree with you on sizes in general. Super Mario World was a 512KB game, and applications used to come on floppy disks. We've really lost our way when it comes to size and speed optimizations in programs.
I know it's not a big deal for most people, especially with Google Code hosting. But for one example, I had a binary differencing patcher. In the game translation scene, most people like to include a patcher with their patch files. But when the patcher is bigger than the entire game itself... they tend to scoff and stick with the older DOS-based 40KB IPS patchers. And then you get a site like smwcentral that hosts thousands of patches, and having a patcher with each archive becomes impossible. Make them download a second file, and the less intelligent get confused. So there really are use cases where binary size matters.
Slashdot Mirror
Willing to try it I suppose. A lot of the trouble is finding the games in the first place. For that, I am going to need people in Europe and Japan who can scour game shops, build up small bundles and ship them internationally all at once. Many of them will be very, very hard to find at all.
I agree with you completely. Read up on what Rufus Pollock, a Harvard professor found after doing research on copyright. The optimal length is 14 years, of which all SNES games have passed. Anything longer is corporate greed.
As far as letting someone read them, that is exactly why I bought them in the first place. I read every one by hand with my own custom hardware (here is a picture of my setup.) This allowed me to image the entire function of the PCB, not just the ROMs like current dumps. I also scanned every box, cartridge and PCB. I then put up all the information in my online database here. I can't distribute the ROM images for legal reasons, but by comparing my SHA256 hashes to yours, you can verify your ROMs are legitimate and unmodified, clean dumps.
About a dozen were unfindable, I had to trade three of mine to get unfindable boxes, too. The rest were unaffordable. I completely maxed out my 401K loan, and my savings are empty. I can't continue buying until this set sells. Otherwise I would have loved to have listed it as a 100% CIB set. Probably could have made 50K just from some rich person not wanting to spend a decade searching. Note: only one person in the world is known to have a 100% CIB US set, DreamTR.
The PCB contacts were scrubbed with sodium hydroxide (to remove oxidation) and isopropyl alcohol (to remove residue.) Took about five minutes per cart. Which is about 60 hours of labor. Not a whole lot, it just ensures that every game will turn on with your very first try, and you won't dirty up your SNES connector on these carts.
Summary states that I will freight ship the collection. It will cost about $400 to do this in the US, and a small fortune internationally.
I haven't distributed any of the images, only SHA256 checksums (here), and I promise that I'll delete all the ROMs as soon as the set sells ;)
It's a licensed retail only set. Donkey Kong Country Competition was another game sold only after a Blockbuster competition. Mountain Bike Rally + Speed Racer was another game that was only sold by mail order for $200 after you bought a $4,000 exercise bike. Noah's Ark 3D was an unlicensed game sold in Christian book stores. MACS was a training game designed for use in the US military. Powerfest '94 and Campus Challenge '92 were produced for their respective competitions, and were supposed to be destroyed (two of each were not.) SNES tester decks existed only inside Nintendo repair centers. This can pretty much go on forever, so you have to draw the line somewhere. However, many can legitimately say it's not a complete set if their definition includes any of the above.
And it's yours for under $60!
The thing I disliked most was the way emulated images do not come with any box art or instruction manuals. That was always part of the fun as a kid for me.
Ironically, you can consider my effort to be undermining the very value of owning the set: I've scanned all of this stuff in at high resolution so it'll be available long after the games are gone. That's why I bought them in the first place. I'm only selling them so I can buy more games from other regions to do the same.
[ eBay Link to auction ]
...) routinely sell for $400-1000 a piece when complete in box. The next four dozen easily command $100-350. That leaves you with about $5 per complete in box game for the rest, in a market where the prices have continued to rise steadily for the past several years.
I am probably underselling myself here, but I would likely accept the first serious offer for $20K or above.
That may seem like a lot, but if you do completed auction searches on eBay, you will see that the top dozen or so games (EarthBound, Hagane, Harvest Moon, Incantation, Aero Fighters, 3 Ninjas Kick Back, Metal Warriors, Mega Man X3,
MESS is great for the obscure systems, but not very good for the popular ones. I suppose that much is obvious. A great site I found for this was http://nonmess.retrogames.com/ ... its author compares MESS against other emulators and documents whether or not MESS is the superior option.
Ah, tepples. Always the pedant. bsnes has a Vsync feature. You could also argue that resampling the audio to get smooth audio+video at the same time is not accurate, and you'd be right. Except for the fact that perfect video+audio sync without doing that is impossible on modern hardware. So I guess there's no such thing as an accurate software-based emulator :P
The default key binding for fullscreen is F11. You're right that it's not a 'true' fullscreen, which I don't do because mode setting changes take forever and only reliably work on Windows. That and they break the UI (you can't display windows, menubars, etc anymore.) However, Vsync works just fine so long as you turn off the garbage Windows compositor (it does not move the Vsync time like OS X, so using it basically guarantees tearing as the compositor and D3D/OGL app fight for who blits first.)
Trust me, you really, really don't want a low-level PS2 emulator. It would be a great thing to have made now for documentation purposes (so that the knowledge is preserved while it's still easily accessible), but it wouldn't run full speed on anything released in the next 40-50 years.
Why bother with conditional branches? :P
int min(int x, int y) { return y + ((x - y) & -(x < y)); }
There is no patent cloud over Java. This was proven less than two weeks ago.
Although I believe you are correct, risk averse businesses are still going to want to wait for the 12 years of appeals to complete first.
Does a hate crime conviction even matter (eg does it mean anything, or have any teeth), when that in addition to *14* other counts gets you a whopping 30 days in jail? That's not going to serve as a deterrent to anyone.
... wow. The reason PGO is so nice is because it reorders your human-readable code into something faster.
... say they are from two entirely different classes.
Assume a switch with eight possible cases, and non-linear indices that do not allow for a simple jump table optimization. Two of them may be vastly more common than the other six, and PGO can take them out of the switch, or reorder them to the top. You can also do this by hand, but it will make your code messier and harder to maintain.
Or take the frequency of code execution. Two routines may execute a lot, so they are stuck together in memory to aid in caching. But it may make no sense to have these two functions anywhere near each other
PGO also frequently decides when to inline things or when not to, and even telling the compiler when to inline isn't guaranteed. You'd have to resort to compiler-specific attributes (always_inline/__forceinline.) And the list goes on and on.
Taking your argument to the extreme, hand-writing your code in pure assembler can get you even more speed, and now you don't even need -O3 for decent speed. But there's a reason people use high-level languages. PGO is just one more tool to make your code more stable and easier to maintain.
It has little to do with reading the contracts. The problem is that if you want a good white collar job, you need a cell phone. And if you want a cell phone, every last service provider has the same clauses. Reading the clause won't help, as unfortunately most people don't care about their privacy. The providers won't care even if they did lose 0.1% of their customer base if the spyware gained them +10% profits.
One of the worst trends in computing is trying to make real-world analogies to everything. Who cares what the real top of your desk looks like? Your desk is not a personal computer, and vice versa.
My Intel Atom @ 1.6GHz can get 80fps, so yes, it's most definitely a configuration issue. Or perhaps he is using the accuracy profile. I really need to be more clear on the downloads page about the performance of the three profiles.
Ex: http://img405.imageshack.us/img405/9608/zelda3v.png
Why would you quote my name? :/
My first PC was a 25MHz 486SX. You will have a PC fast enough for bsnes one day. In fact, you can get such a system for ~$100 used today. And then you can play every game you care about, and every game that people other than you care about as well. Whereas you probably won't be using ZSNES on your new Windows 10 box that lacks 32-bit run-time libraries.
Anyway, something else is wrong if 2.5GHz isn't enough for you. But it doesn't seem like you are interested in troubleshooting, so no worries. Sorry that my software gave you a hard time.
Without double-checking the list, I can tell you right now that Wild Guns has hacks in most emulators.
That game will trigger a DMA past the end of NMI, and immediately toggle NMI on the next instruction for unknown reasons. Because of a hardware edge case, the NMI status is cached one cycle sooner than the next opcode.
Only bsnes and Super Sleuth simulate that delay, the rest hack around it. Without either, the entire in-game screen would flash between the real image and garbage every other frame.
If you want to see a list of ~100 or so known bugs, you could try here: https://zsnes.bountysource.com/development/bug_report
The library is still in progress re: memory management. Right now the idea is that the UI elements won't eat all that much memory, so why waste time with allocation/deallocation? You can of course use pointers anyway, and delete them whenever, but at the moment it'll be your responsibility to ensure they were no longer in use or bad things will happen. I'll add destructors that remove widgets from containers and such in a future release.
I use my own string class because std::string is garbage. No token replace (eg replace all 'cat' with 'dog'), no tokenize string (split, explode on key), unsafe find/strpos return value on non-matches (boost::optional works much better and throws exceptions when abused), no char transform (PHP strtr), no case-insensitive find, no support for parsing quoted strings (think split on = in a config file, quoted parameter may have = that we want to ignore; or think any kind of scripting/assembly syntax's strings), no math parsing (tell me what "3+2*7+4" equals), has to create a new object to be compatible with the native char* type of the language (c_str()), formatting with ios is torture, and building streams is a pain (no return { "My name is ", name, ", and I am ", age, " years old.\n" }; or openFIle({ baseFileName, ".txt" });) - it prefers the nonsensical operator left-shift over using traits to allow the more natural +, on and on. I could write a book on this class alone.
I have my own function class because std::function sucks at binding to member function pointers. You have to mix memfn/bind1st in odd ways, and when you get above one parameter I can't even figure out how to use it anymore. With mine: onClose = &globalFuncOrMemberStaticFunc; onClose = { &Class::MemberFunc, &classObject }; onClose = [this]() { closure(); }; can also attach to boost::bind for argument shuffling.
My version of optional is so you don't need boost to use it, and is four lines long. And that's it. The only thing you are ever exposed to is my string class on some return values, which is castable to and convertible from const char*, so pretend it's that and use with std::string if you like.
Thank you kindly for testing that for me. The numbers are at least twice as good as Qt, and GTK+ is DLL city. And yeah, ten years will do that to a project. I have noticed the run-time sizes going up with each new release of Qt. Also agree with you on sizes in general. Super Mario World was a 512KB game, and applications used to come on floppy disks. We've really lost our way when it comes to size and speed optimizations in programs.
... they tend to scoff and stick with the older DOS-based 40KB IPS patchers. And then you get a site like smwcentral that hosts thousands of patches, and having a patcher with each archive becomes impossible. Make them download a second file, and the less intelligent get confused. So there really are use cases where binary size matters.
I know it's not a big deal for most people, especially with Google Code hosting. But for one example, I had a binary differencing patcher. In the game translation scene, most people like to include a patcher with their patch files. But when the patcher is bigger than the entire game itself