In this post, tokumaru wrote:
I don't find FCEU accurate at all.
I know of four instructions to detect Nesticle, but what's the fastest way for an NES program to detect FCEU and FCEUX, or any other popular emulator for that matter?
I know of four instructions to detect Nesticle, but what's the fastest way for an NES program to detect FCEU and FCEUX, or any other popular emulator for that matter?
Simplest: ask the user, though that isn't reliable.
Now you got me. Most problems I found with FCEU(X)(D) were reletaed to graphics. I seem to remember it not emulating the sprite pattern fetching during HBlank well. Maybe a timed change of sprite patterns (through bankswitching or a $2000 write) followed by a sprite 0 hit could be used.
I don't remember the problem exactly, but back when I was trying to switch out a bank with empty tiles for one with the tiles I'd use during the frame, depending on where in HBlank the switch was made, Nintendulator, Nestopia and my NES would display some of the sprites in the following scanline with transparent patterns (the ones that were fetched before the switch), but FCEUXD would never do that.
I don't remember the problem exactly, but back when I was trying to switch out a bank with empty tiles for one with the tiles I'd use during the frame, depending on where in HBlank the switch was made, Nintendulator, Nestopia and my NES would display some of the sprites in the following scanline with transparent patterns (the ones that were fetched before the switch), but FCEUXD would never do that.
tepples wrote:
... what's the fastest way for an NES program to detect FCEU and FCEUX, or any other popular emulator for that matter?
I have to ask -- why on earth would a person want to do this? Seems like the logic is completely backwards. Is it really the responsibility of the coder to make exceptions of this nature? Let me know if you find a NES or Famicom cartridge that "caters" to a Nintendo-branded console vs. a clone, via code. :-)
One reason for emulator detection is to warn users that a game might not work. For example, some versions of LJ65 use the Nesticle-detection code listed on the linked page, and they put up a disclaimer screen styled to fit into Nesticle's UI.
Another is to warn players that their online score submission codes will be subject to more scrutiny or even disqualification if the game is run in an environment supporting cheating.
koitsu: On Super NES see SA1 and S-DD1.
Another is to warn players that their online score submission codes will be subject to more scrutiny or even disqualification if the game is run in an environment supporting cheating.
koitsu: On Super NES see SA1 and S-DD1.
Reading the palette from vram was broken up to Fceuxdsp 1.07 and the version of Fceux I tried about a year or so ago. I'm not sure if it has since been fixed.
tepples wrote:
One reason for emulator detection is to warn users that a game might not work. For example, some versions of LJ65 use the Nesticle-detection code listed on the linked page, and they put up a disclaimer screen styled to fit into Nesticle's UI.
I still don't see how this is effective. You would actually need to do emulator *version* identification for it to be reliable. Blocking a single emulator entirely seems excessive. If the emu author fixes the emulation mistake, someone is going to have to come out with an IPS patch for the ROM anyway (and how do you think that reflects on the author of the game? Definitely not positively, that's for sure).
If this is a commercial game, then put it on the packaging or cart, or better yet, the manual. "Snakeman's NES Emu v1.22 doesn't work with this game". Game authors shouldn't have to "cater" to emulators is what I'm getting at.
tepples wrote:
Another is to warn players that their online score submission codes will be subject to more scrutiny or even disqualification if the game is run in an environment supporting cheating.
Is this really the responsibility of a NES game though? I would think the "online site" that tracks scores has a strict list of requirements. If they permit emulators, that's their own fault/problem, not the games'.
What I'm trying to say is that I think the above two points you've made aren't the responsibility of a NES game to solve. If anything, they border on Nintendo's introduction of copier detection in Super Mario All Stars. Folks are already used to going to an emulator's forum (or more commonly, asking friends/peers) and inquiring as to why game X doesn't work; the process is a social one, leave it as such.
tepples wrote:
koitsu: On Super NES see SA-1 and SDD-1.
These are hardware expansion chips. Carts which have them also contain games (read: code) that utilises them. Let me know if you can take a SA-1 or SDD-1 game and have it still work on the console without said chips in place. :-)
I think tepples' approach is to solve the issue of random ignorant user claiming a game sucks because it doesn't work on his favorite emulator. If the game had a screen at the beginning, "Note: this game is made for a genuine NES, and may not work in clones or emulators.", said person might be less-apt to claim it's the game's fault.
And you wouldn't need to do emulator version identification, since you aren't actually detecting the emulator, rather something that behaves differently than on a NES. If the emulator later became perfect, then by definition there's no way the game could detect it and put up any kind of warning. Emulators aren't perfect, but neither can a game detect every possible deviance from NES behavior. If a good number of homebrew games put up warnings like this, there would be incentive for emulator authors to fix the inaccuracies said games exploit to detect them, resulting in a sort of arms race whose end-state would be perfect emulators. It's an interesting approach.
And you wouldn't need to do emulator version identification, since you aren't actually detecting the emulator, rather something that behaves differently than on a NES. If the emulator later became perfect, then by definition there's no way the game could detect it and put up any kind of warning. Emulators aren't perfect, but neither can a game detect every possible deviance from NES behavior. If a good number of homebrew games put up warnings like this, there would be incentive for emulator authors to fix the inaccuracies said games exploit to detect them, resulting in a sort of arms race whose end-state would be perfect emulators. It's an interesting approach.
blargg wrote:
If a good number of homebrew games put up warnings like this, there would be incentive for emulator authors to fix the inaccuracies said games exploit to detect them, resulting in a sort of arms race whose end-state would be perfect emulators. It's an interesting approach.
This is true, the same thing happened with the c64 emulators. Demo writers frequently shame emulator use and it really drove some emulator authors to write a near perfect c64 emulator, like VICE.
koitsu wrote:
tepples wrote:
Another is to warn players that their online score submission codes will be subject to more scrutiny or even disqualification if the game is run in an environment supporting cheating.
Is this really the responsibility of a NES game though? I would think the "online site" that tracks scores has a strict list of requirements. If they permit emulators, that's their own fault/problem, not the games'.
That's reason #3. Which is why I want to encode whether or not an emulator was used in the code, so that the site can verify it against its requirements.
Quote:
If anything, they border on Nintendo's introduction of copier detection in Super Mario All Stars.
That's reason #2.
Quote:
tepples wrote:
koitsu: On Super NES see SA-1 and SDD-1.
These are hardware expansion chips. Carts which have them also contain games (read: code) that utilises them.
I was referring to the fact that unlike the DSP-1 and the Super FX, these chips require the matching host CIC to be in place.
Quote:
Let me know if you can take a SA-1 or SDD-1 game and have it still work on the console without said chips in place. 
Star Ocean graphics pack.
blargg wrote:
I think tepples' approach is to solve the issue of random ignorant user claiming a game sucks because it doesn't work on his favorite emulator. If the game had a screen at the beginning, "Note: this game is made for a genuine NES, and may not work in clones or emulators.", said person might be less-apt to claim it's the game's fault.
That's reason #1. See also Demotronic for Game Boy Color: you have to either run it on a Game Boy Color or Game Boy Advance system with a Game Boy Color flash card (not a GBA flash card), run it on a best-of-breed emulator (KiGB, not even Goomba Color), or use a patch to skip the emulator check.
How to detect almost any SNES emulator:
I don't recall off the top of my head what the V flag should be, unfortunately. The truth is, the SNES emulation scene is still in the NESticle phase.
Detecting emulators via blargg's approach (eg not name and shame) can be useful. Especially if you use the behavior you're testing.
I also don't think that testing an unrelated behavior to block your game is all that useful. d4s added an emulator check using hardware mul/div delays, and nobody touched it for a few years. It was blargg that ended up cracking it, and I'm not sure he even knows about that game. I only asked him to help because I felt bad for putting it off for so long. That sort of thing requires a really competitive environment to work.
ZSNES v Snes9X in the 90s would be a good example of that environment. Nestopia vs RockNES would not be. It is hard to pressure someone to improve when they have more than ten times your market share.
Not worrying about emulators that can't support it isn't a good approach. I've had two people accuse me of intentionally making one of my translations not work on ZSNES just to get people to use my emulator. The hole in that logic was that the original Japanese game didn't work either. I kind of wish I did add such a check in retrospect, as the game is still broken, 14 years after reporting the bug. It's not those two reports that bug me, it's the dozens of false bug reports to this day that do.
Also, neviksti's Star Ocean patch? I understand you like to point out any exception to a rule, but come on :P
That has all of nothing to do with emulator detection anymore.
Code:
sed
lda #$9a
sbc #$01
bv? emulatorDetected
lda #$9a
sbc #$01
bv? emulatorDetected
I don't recall off the top of my head what the V flag should be, unfortunately. The truth is, the SNES emulation scene is still in the NESticle phase.
Detecting emulators via blargg's approach (eg not name and shame) can be useful. Especially if you use the behavior you're testing.
I also don't think that testing an unrelated behavior to block your game is all that useful. d4s added an emulator check using hardware mul/div delays, and nobody touched it for a few years. It was blargg that ended up cracking it, and I'm not sure he even knows about that game. I only asked him to help because I felt bad for putting it off for so long. That sort of thing requires a really competitive environment to work.
ZSNES v Snes9X in the 90s would be a good example of that environment. Nestopia vs RockNES would not be. It is hard to pressure someone to improve when they have more than ten times your market share.
Not worrying about emulators that can't support it isn't a good approach. I've had two people accuse me of intentionally making one of my translations not work on ZSNES just to get people to use my emulator. The hole in that logic was that the original Japanese game didn't work either. I kind of wish I did add such a check in retrospect, as the game is still broken, 14 years after reporting the bug. It's not those two reports that bug me, it's the dozens of false bug reports to this day that do.
Also, neviksti's Star Ocean patch? I understand you like to point out any exception to a rule, but come on :P
That has all of nothing to do with emulator detection anymore.
Sprite DMA from an open bus area, and then examine the contents of OAM (either directly or indirectly), should be able to detect a good deal of NES emulators, and it's fairly simple.
You might catch a number of emulators that way, but surely some would pass.
How about sprite collision aimed at junk scanlines from inaccurate MMC3 emulation?
That's actually a useful one, as it directly targets what you might want to avoid, graphical junk due to the emulator, that would get blamed on your game. The CPU can "see" quite a bit via a sprite #0 with a single non-transparent pixel. With the palette all black, the player need not see any visual glitches while you verify that you aren't running on a sub-par emulator.