Interpreter Detection: SSCI or ScummVM?

[Kawa]

I've been following the development of a certain SNES emulator up close, and earlier today I was reminded of something from a while back. It was a SNES ROM that could identify with a high degree of certainty which emulator or console revision it ran on. The challenge for this certain emulator whose author strives for accuracy was to foil the detection without resorting to blatant lies.

How this ended is ultimately irrevelant.

What is, is that this in turn reminded me of a certain difference between Sierra's SCI terps and ScummVM: the latter supports everything at once, while the former has somewhat game-specific terps. For example, King's Quest 6 has its SEQ videos, while Larry 6 has the old SCI01 menu bar, and there are at least two "magnifying glass" effects that only work in their own respective games. If you run LSL6 on the SIERRA.EXE from KQ6, it outright says AddMenu is not supported.

On the other hand, ScummVM does not seem to care as much, as long as the kernel functions are basically all uniquely numbered. There doesn't seem to be anything stopping you from using SetCursor subop 10, the magnifying glass effect in Freddy Pharkas, and the menu bar code doesn't seem to care at all. Thus, theoretically, one should be able to play videos (both SEQ and AVI?) as well as do a magnification effect, color remapping (thanks QFG4 Demo), and a menu bar to bind them all together... if you run in ScummVM.

Now imagine an SCI11 game that actually does all these things. No single SSCI terp would be able to run it, of course; only ScummVM could. But imagine you want to let those who try it anyway down gently, like a Gameboy Color game in a classic mono Gameboy. Of course, where the GBC actually lets the game ROM know outright that it's a GBC (A=11h from the get-go, easy to check), I can't think of a way for an SCI11 script to tell if it's running on ScummVM or SSCI without deliberately crashing. The first idea I had was to check for a driver file, since ScummVM doesn't use those, but that wouldn't work as well considering they can still be present...

So what method, if any, is there to detect that you're running in ScummVM so that if you're not, you can show a gentle error message and quit again. Showing the message in SCI proper would be preferred, but that's a bit out of scope.

Of course, if all of the above is wrong and I've been misinterpreting the source code all along, that's a valid answer as well

[troflip]

Well, given we know that you can't play two digital audio sounds at once, you could try playing a looping digital sound (its handle property will then become non-zero), and then invoke a call to DoAudio(audPlay etc.....) and check if the sound's handle becomes 0 (indicating it has stopped playing). I just verified that it becomes zero in Sierra's interpreters (well, the one with the template game).

Presumably it stays non-zero in ScummVM (since the first sound keeps playing), though I haven't checked.

So... that's my idea for a hacky way to do this.


Another way would be to detect if certain commonly-used selectors on commonly-used object are being set by index (Sierra's interpreter) or by name (ScummVM). For instance, make a class that has the same properties as Prop (except with a pair of key properties swapped), add it to the scene and wait for some call that the interpreter makes to set values on this object (you'll have to figure that part out), then see if the values are what you expect.

[Kawa]

Both are excellent ideas, but I think I must've messed on the audio thing cos the handle stays 1 in SSCI.

Given two audio resources, a tone and some noise:

Code: [Select]

(case 1
DebugPrint("sound test go! detectorSound handle is %d." (detectorSound:handle))
(detectorSound:play())
DebugPrint("playing! detectorSound handle is %d." (detectorSound:handle))
= seconds 1 //Sounds are two seconds long.
)
(case 2
DebugPrint("about to DoAudio! detectorSound handle is %d." (detectorSound:handle))
DoAudio(2 43)
DebugPrint("playing! detectorSound handle is %d." (detectorSound:handle))
= cycles 1
)It plays the tone for ~1 second, then replaces it with noise. The debug output is 0, 1, 1, 1.

[troflip]

And detectorSound only has a digital effect, no midi-version that would be playing instead?

Maybe you need to wait a game cycle in order for its handle to be reset. I think the Sound::check method would need to be called in order for SCI to set the handle to 0 after detecting the sound is no longer playing.

At any rate, it worked for me (I was also using audio36 resources for DoAudio).

[MusicallyInspired]

Obviously I can see the merit in doing an auto-detect for this, but is there anything wrong with simply asking the user which interpreter he's playing on and going from there? (ie- "Are you playing in DOS/DOSBox or ScummVM?")

[Kawa]

is there anything wrong with simply asking the user which interpreter he's playing on and going from there?

As a great man used to say, "everybody lies."

[MusicallyInspired]

I'd say that's their own problem. But it's a fair point. And if you can make it auto-choose all the better.

[Kawa]

Well then. I can't seem to reproduce the sound-based method (sauce plz?) and I'm not leet enough to do the other one.

I might as well experiment with those features I mentioned in the OP... after sleep.


Edit: hold on a moment there. What was that about DebugPrint in the other thread?

[troflip]

Edit: hold on a moment there. What was that about DebugPrint in the other thread?

Oh yeah... you can write a file. Then try to read it back. If there's nothing there, then you must be running in ScummVM (or it could be that you don't have write privileges in the directory the game is in)

[lskovlun]

Oh yeah... you can write a file. Then try to read it back. If there's nothing there, then you must be running in ScummVM (or it could be that you don't have write privileges in the directory the game is in)

I don't understand this, because the games manage to read and write files just fine. Are you doing something very differently?

[Kawa]

Oh yeah... you can write a file. Then try to read it back. If there's nothing there, then you must be running in ScummVM (or it could be that you don't have write privileges in the directory the game is in)

I don't understand this, because the games manage to read and write files just fine. Are you doing something very differently?

Well, I've had my sleep. Time to test what Phil implied:

I wish I could get the DebugPrint working in ScummVM. But the FileIO functions seem to work differently...
[edit: ah, ScummVM doesn't support writing arbitrary files... only save game files]

[lskovlun]

Oh yeah... you can write a file. Then try to read it back. If there's nothing there, then you must be running in ScummVM (or it could be that you don't have write privileges in the directory the game is in)

Right, so I went back and looked. The issue is not with FileIO, it is with the entire concept behind DebugPrint. You create a file and expect it to be stored in the game folder. The SCI engine in ScummVM uses the ScummVM filesystem abstraction. This means that any files created by the games (by saving or otherwise) go into a different directory than the game files. This makes sense, because under Windows, program directories are ostensibly read-only anyway (and similar, but stricter, requirements exist on other platforms that ScummVM supports, such as smartphones). Another problem is that the FS routines implicitly compress the files when creating them.

All of this is transparent as long as the files are only accessed from a single game (no sharing!) from within SCI. Thus, it can't be used for detection purposes. It breaks down when you try to use files as a portable IPC mechanism.

[Kawa]

Yeah, I just found that out myself. Shit sucks.

(no really it kinda does when a four-byte check string is saved as 24 bytes.)

New detection idea! SCIAudio! One of the first things ScummVM's kFileIOWriteString does is check if the string starts with "(sciAudio", and it doesn't actually write anything to the file then. Try to write "(sciAudio" to a file, read it back. What do you get?

Edit: wait shit no what the hell is this handle -1 stuff how is that supposed to work?

[troflip]

All of this is transparent as long as the files are only accessed from a single game (no sharing!) from within SCI. Thus, it can't be used for detection purposes. It breaks down when you try to use files as a portable IPC mechanism.

Can you think of another way to have that kind of communication in ScummVM?

Or is there a way the game can do something to cause debug spew to go into Scumm's console? (which would kind of be achieving the same thing)

Oh, also... is there a way to have ScummVM run a game directly, without going through the game-choosing menu? I couldn't find any cmd line option that does this. It would be nice to be able to hit the "run" button in SCI Companion and have it go right into the game in Scumm.

[MusicallyInspired]

Yes, there is. You add the game's id (visible when you go to Edit Game... in ScummVM) to the command line. Every game has (needs) a unique game ID, and you can set it manually, I think.