Here's a tiny and trivial bug. The Assembly Version listed inside the EXE file (you see this inside Windows Explorer) isn't the same version as what the program reports in the About screen. It still says it's version 1.0.1.3523.
What exactly is the point of these comparisons? There's nothing significant that would cause the emulators to run at different speeds. Not at all like the SNES.
The NES CPU and PPU are tightly pegged to each other, 3 dots drawn for every CPU cycle. There are a few obscure hardware quirks that will steal some extra CPU cycles unexpectedly (sometimes including CPU/PPU alignment, which is a random 1/3 factor on bootup) but they are still rare and far between. We're talking maybe up to 6 CPU cycles out of the 29780.66 cycles in a frame. Missing a few stolen cycles only really affects a system that is on the edge of executing too many instructions in a frame before it would lag, or it affects games that spin the RNG until a new frame arrives.
It's not at all like other systems, where there are different memory speeds (cache, slow memory, fast memory, etc).
This thing can't even reach 60FPS on a Core 2 Duo when emulating the NES. (It used to be able to, but not anymore.) Other systems run much faster though.
This is also a Microsoft .NET program, which is unlikely to work on Linux.
Raspberry Pi is completely out of the question.
Site rules say to disregard text animation speed when comparing a time from the US and Japanese versions of the game. So a run of the US version that saves 1 frame during gameplay would still obsolete the Japanese version.
Is the Nico run even legitimate? It dies, then uses the password it just got to save time.
The one thing I really hate about this game is how any sound effect in the noise channel kills the drums for the rest of the song. It shows of incredibly incompetent programming.
Tested Fire Hawk again, still broken.
I had just finished reimplementing DMC emulation in PocketNES, so that was one of the games I was testing out heavily until it worked. I had a half-working implementation that just barely not working until I had implemented the two rules below properly.
I'll repeat my previous post, since old posts tend to get buried on flat paginated boards like Phpbb. Sorry if this is rude.
Two things about DMC emulation that affect this game:
* When starting a new DMC sample (DMC length counter changes from 0 to something else):
** If DMC buffer is empty, DMC fetches the initial sample one CPU cycle later, decreasing the length counter by 1. (This may possibly coincide with the DMC channel doing a fetch anyway if its counters have run down, so it won't be two fetches if that happens, just one fetch)
** If DMC buffer is not empty, there is no immediate DMC fetch. DMC waits for the bit counter to tick to 0 before fetching the first sample and ticking down the length counter.
I just tested out 1.0.3, and Fire Hawk is not working.
Two things about DMC emulation that affect this game:
* When starting a new DMC sample (DMC length counter changes from 0 to something else):
** If DMC buffer is empty, DMC fetches the initial sample immediately, and decreases the length counter by 1 immediately.
** If DMC buffer is not empty, DMC waits for the bit counter to tick to 0 before fetching the first sample (and ticking down the length counter).
I peeked at the source code, and see that it is not fetching the first sample immediately, so the length counter doesn't get ticked down immediately.
note: "Immediately" here means one cpu cycle later. And the immediate fetch does not happen if the bit counter ran out at exact that time and caused a fetch to happen.
This is a "Triggers credits early" run, not a "finishes the game" run.
Just like using the warp glitch in Ocarina of Time to take you from Dogongo's Cavern to the Ending cutscene is different from defeating Ganon as child link from warping out of the deku tree.
If you trigger end credits early without actually beating the boss, it should be a separate category.
I once read a lengthy article from the developers of the game about the copy protection mechanisms they used. Lots of checksumming and crazy stuff happening if the piracy check fails.
But I've never actually seen the game in action before, so I'm interested to see the encode once it's ready.
I wonder if it's possible to corrupt the RAM through TASing, and make the game think its a pirate copy.
