Gameboy Development Forum

bbbbbr · 2020-07-20 13:53:39

Are there any intentional / semi-standard "tells" to detect whether a ROM is running inside an emulator (vs. real hardware)?

If it was possible, I'd like to consider whether to turn off an effect if the game is in an emulator.

On the intro screen for Petris I wanted to do a 50% duty cycle of hide/show sprites to make the clouds semi-transparent. This looks pretty good on actual hardware where the screen is locked to the frame rate.

But it does not look good when running in an emulator on my computer (which is oldish, and screen refresh is 59.95hz) where the on/off cycle goes in and out of phase making the clouds flicker instead of semi-transparent. Maybe on faster computers with higher refresh rates it's not an issue anymore, but I'd like it to look reasonable under all circumstances.

toxa · 2020-07-20 15:52:28

determining the emu is quite tricky, because emulators want to be as close to hardware as possible.

you might want to determine a specific emu, say, the javascript one that you use with itch.io. that's a simplier task. there are "test roms" for emulators: some clever written pieces of software that test various "corner-cases". that roms are used to determine how close to real hardware your emulator is.

so:
1. take that roms
2. test your emu with that roms, find subset that fail with your emu (or look into some table, somebody might made that testing for you already).
3. take the most simple one
4. write a function, that test that "exploit", if it fails - you run in the emu, if not - on real hardware.
...
5. profit

Last edited by toxa (2020-07-20 16:09:42)

toxa · 2020-07-20 16:09:12

links:
1. https://github.com/Gekkio/mooneye-gb
2. https://gbdev.gg8.se/wiki/articles/Test_ROMs

bbbbbr · 2020-07-20 16:23:00

I was hoping there might be a somewhat universal, reliable and intentional method emulator authors had decided on to signal to a ROM that it was in an emulator. Similar to the no$gmb and BGB informal "standard" for debug printing.

I'd be wary of anything which relies on a particular emulator not faithfully reproducing hardware behavior, since that is both subject to change and limited to specific emulators.

toxa · 2020-07-20 16:38:19

no. the goal of emulator developer is to write software that is 100% accurate. that is opposite to your requirements.

toxa · 2020-07-20 17:13:06

bbbbbr wrote:
Similar to the no$gmb and BGB informal "standard" for debug printing.

but it is tricky to determine from the program itself whether debug string is printed or not.

copy-protection stuff also uses similar methods: it tries to determine emulators, debuggers, even hardware simulators sometimes.

nitro2k01 · 2020-07-23 05:17:49

This sounds very much like an XY problem. Detecting emulators just to disable an effect is trying to solve a problem with an inappropriate solution. Trying to solve the problem this way is likely to trigger both false positives and false negatives, and temporal blending is a very standard technique used in various games, which your fix woouldn't help you with

False positives: Depending on your detection method, it's possible you will run into a situation where your detection triggers even on real hardware. For example, if your detection relies on the initial state of IO registers or RAM contents, a flashcart menu/loader might change those and trigger the detection.

False negatives: For a good emulator, any difference in execution between real hardware and the emulator will be considered a bug and will be fixed, causing the method to stop working.

But why no official method to detect emulators? The point of an emulator, both when using it to play games, and to develop software, is to mimic real hardware. If you're debugging code and the code runs differently when in the emulator, that might have as a side effect that some particularly obscure bug actually never happens in the emulator to do the slight difference in timing. This is why the debug commands in BGB (breakpoint and message) are "nops" (no operation) on real hardware. A compile time breakpoint is just ld B,B for example which does moves the value of the B register to B, ie it does nothing. The code runs the same way cycle by cycle in both cases and any debug side effects exist outside the (emulated) CPU.

The problem: There are several things you could try. Enable frame blending ("mix current and last frame" in BGB's settings). Try changing other outputs in BGB to see if that helps. Try enabling vsync. Try a different emulator, like Sameboy, and see if it has the same problem. Join #gbdev on EFNet and post a bug report to beware.

toxa · 2020-07-23 07:36:40

that is for itch.io js-embedded emu, as i understand. the simpliest way is just to put a special edition rom into the embedded emu, keeping the original one for download.

Ardis · 2020-07-23 09:19:00

I have a different approach to the issue of disabling blending for emulators, similar to what I am doing for the palette inversion on Interceptor (since the black background makes the game nearly unplayable on DMGs, but works fine on other models.)

If your game doesn't use the Select button for anything, you could probably just use that button to disable the blending effect in-game. Or you could add it to the options screen.

bbbbbr · 2020-07-25 21:31:52

Thanks for all the good suggestions and information.

* The BGB option to "mix with last frame" does make the clouds appear as intended as long as it's a 50% duty cycle (not for 75% or anything that spans more than 2 frames)
* The BGB vsync options don't do much, perhaps due to computer speed and/or my monitors refresh rate.
* As mentioned, the javascript emulator I use on itch.io is something I'd like it to not look glitchy on as well. So far as I can tell it doesn't have an option to support temporal blending, and I'm not inclined to try and add it just for this.

It looks like there is not a universal solution which would allow one ROM to look good in all environments (hardware, multiple different emulators of differing ability). Which makes sense and is fine.

So the best course may be to just produce a separate build ROM for some scenarios, as toxa suggests.

Last edited by bbbbbr (2020-07-25 21:40:31)

Gameboy Development Forum

Ads

#1 2020-07-20 13:53:39

How to tell if a game is running in an Emulator

#2 2020-07-20 15:52:28

Re: How to tell if a game is running in an Emulator

#3 2020-07-20 16:09:12

Re: How to tell if a game is running in an Emulator

#4 2020-07-20 16:23:00

Re: How to tell if a game is running in an Emulator

#5 2020-07-20 16:38:19

Re: How to tell if a game is running in an Emulator

#6 2020-07-20 17:13:06

Re: How to tell if a game is running in an Emulator

bbbbbr wrote:

#7 2020-07-23 05:17:49

Re: How to tell if a game is running in an Emulator

#8 2020-07-23 07:36:40

Re: How to tell if a game is running in an Emulator

#9 2020-07-23 09:19:00

Re: How to tell if a game is running in an Emulator

#10 2020-07-25 21:31:52

Re: How to tell if a game is running in an Emulator

Board footer