I didn't realize Regen was also closed source though.
He also had GPL code in the first few versions, but still didn't release his code. The worst possible case, benefiting from people who share whilst not returning the favor
I would suggest that if ZSNES bugs are hampering translations, then maybe translations groups should advertise prominently that their stuff only works on hardware or in bsnes or (hopefully) MESS.
Oh, it's much worse than that. The latest was a team who released a patch that only ran on ZSNES. When they found out it didn't work on hardware or other emulators, they espoused, "well, it doesn't really matter, just use ZSNES instead."
I was as polite as possible and offered to help debug and fix the issue for them, but they were very
notably perturbed that people were upset with the patch.
It bothers me because one day we'll either have to:
a) create a ZSNES emulator, or
b) completely lose these gem translations for good
And now from the other side of the spectrum: when I released my DL translation, I had two people accuse me of hacking it to ONLY run on bsnes. Nevermind the fact that the original, unmodified Japanese game also locked up and crashed on ZSNES ...
Yes, some people might not like having set names, but creating even more rom formats is probably just going to result in only a handful of people caring, and plenty of people confused as to why a new format is needed, and simply ignoring it.
My plan was to match the loaded SHA256 sum to the database, preferably with an O(log n) search. I can understand how calculating an SHA256 sum would be a problem for MESS on CD/DVD-based systems. But for ROMs, it's more fool-proof. Can't trick the system by renaming a file wrong, and rainbow attacks on SHA256 are pretty hard at the moment.
I don't know, I guess I'll believe it when I see it working on an actual SNES using an actual proper mass storage device.
Okay, sure http://byuusan.kuro-hitsuji.net/lunar.sfc
This is the Lunar: Silver Star Story MPEG opening, encoded at 240x160x8bpp @ 30fps along with 32KHz stereo sound output, running on the S-DD1 hardware.
The only way in which it cheats is by accessing 64MB through the S-DD1 MMC, whereas the ROM on a real cartridge was 6MB in size. However, someone took that file and cut it to 6MB and was able to run the first several seconds off his cart. I can try and find out who, but it was mentioned on the nesdev thread by smkdan about his video ROMs.
I am happy to go into the explanation, but I am beyond 100% confident that the above is fully and completely possible. It's actually really, really very easy to do.
you certainly may put an 8-core Nehalem-EX inside a SNES cart if you want to, but good luck feeding it data fast enough or getting data off the cart fast enough
Of course. My point was that the cartridge could have anything inside of it, not that the SNES could fully utilize what was there
You could for instance turn it into a really souped up DSP-1 if you wanted. Or have Deep Blue's chess algorithm going.
By saying you could put anything, of course it's a bit asinine since all commercial games ever made have been released. We have a fixed set of chips to support. I was more trying to represent that the chips inside the cartridge are not part of the SNES itself. Having DSP-1 support doesn't mean it's part of the SNES emulator, it's a DSP-1 chip emulator, or essentially a specific cartridge simulator at that point.