Interpreter Detection: SSCI or ScummVM?

[Kawa]

troflip, what was the code you used for that thing with the two sounds and the handle?

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.

Actually, I recall a thing in a TODO list where it was suggested that putting ScummVM in a game's folder (like their own terps) and starting it there should do the obvious thing, without necessarily putting the game in ScummVM's library.

[troflip]

troflip, what was the code you used for that thing with the two sounds and the handle?

I forget...

Anyway I *think* I've coded up something that detects the interpreter, but I can't test it because I can't seem to get ScummVM to recognize SCI 1.1 template games anymore. It somehow doesn't recognize it as a fan made game, and won't run it. I'm not sure what changed. Sigh.... [shaking fist at ScummVM]

Anyway, here's the script (hard-coded to script 19 right now). Replace 996 with some other view in your game that is at least 3 pixels high. The code basically uses an object with property positions swapped, and then sees what properties the kernel BaseSetter sets. It should set the wrong ones in Sierra, and the right ones in ScummVM.

Code: [Select]

/******************************************************************************/
(version 2)
(script 19)
/******************************************************************************/
(include "sci.sh")
(use "obj")
(use "main")

(exports
0 IsSierraInterpreter
)

(class FakeView of Obj
    (properties
        x 0
        y 0
        z 0
        heading 0
        noun 0
        modNum -1
        nsTop 0
        nsLeft 0
        nsBottom 0
        nsRight 0
        sightAngle $6789
        actions 0
        onMeCheck omcDISABLE
        state $0000
        approachX 0
        approachY 0
        approachDist 0
        _approachVerbs 0
        yStep 2
        view -1
        loop 0
        cel 0
        priority 0
        underBits 0
        signal $0101
        lsTop 0
        lsLeft 0
        lsBottom 0
        lsRight 0
        scaleSignal $0000
        scaleX 128
        scaleY 128
        maxScale 128
        // The last 4 props have been swapped with the previous 4 (compared to the View class)
        brTop 0
        brLeft 0
        brBottom 0
        brRight 0
    )
)

(instance dummy of FakeView
(properties)
)

(procedure public (IsSierraInterpreter)
(FakeView:view(996))
BaseSetter(FakeView)
DebugPrint("brTop is %d brBottom is %d " (FakeView:brTop) (FakeView:brBottom))
return (== (FakeView:brTop) 0)
)


[lskovlun]

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)

There is a slot in the kernel table reserved for a function called DbugStr, which in SSCI prints to an attached monochrome monitor. I suppose we could use that (it's not currently implemented in ScummVM though, so that will have to be done - but it should be easy). I managed to make the monochrome screen work in DosBox a while ago, but it's a bit of a pain - it requires applying a patch and compiling manually. Of course, you can keep supporting the old method if you like.

My original thread on the topic is here: http://sciprogramming.com/community/index.php?topic=1419.0

[lskovlun]

Anyway, here's the script (hard-coded to script 19 right now). Replace 996 with some other view in your game that is at least 3 pixels high. The code basically uses an object with property positions swapped, and then sees what properties the kernel BaseSetter sets. It should set the wrong ones in Sierra, and the right ones in ScummVM.

I see what you did there. Sneaky.

[Kawa]

I can't seem to get ScummVM to recognize SCI 1.1 template games anymore. It somehow doesn't recognize it as a fan made game, and won't run it. I'm not sure what changed. Sigh.... [shaking fist at ScummVM]

I've found that it's the game's class name or something. Script 0 export 0's name matters, it seems.

Also, the name/number thing works perfectly.

[troflip]

Ooo yeah, you're right. Guess I'll have to leave the template game name as SQ5.

[Kawa]

I got too excited. Turns out RemapColors is only available in QfG4 Demo, because it replaces StrSplit.

Still, I managed to build a copy of ScummVM that maps it to SetSynonyms (empty in SCI11) instead, just for testing. As far as I can tell, the other things plus playing two digital sounds at once are still on the table as valid reasons to do this whole detection dance.

[Collector]

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.

You can start games from the command line.

http://wiki.scummvm.org/index.php/User_Manual/Running_and_Using_ScummVM#Command_line_options

You can do it exactly the same as you are with DOSBox, but may need a couple of extra options. Note that ScummVM IDs the template game as "sq5-demo".

You can also start a game in ScummVM with a custom ini file i.e.:

Code: [Select]

"C:\Program Files (x86)\ScummVM\scummvm.exe" --config=scummvm.ini sq5-demo
And in the ini file it points to something like:

Code: [Select]

[scummvm]
lastselectedgame=sq5-demo
browser_lastpath=C:\Games\New Game\

[kq6-win]
description=Space Quest V: The Next Mutation (Demo/DOS/English)
savepath=C:\Games\New Game\
gfx_mode=2x
path=C:\Games\New Game\
fullscreen=false
gameid=sci
prefer_digitalsfx=true
language=en

The description could be named to the given game's name.

Now one possible problem is that ScummVM IDs games by the hash of a given file. In the case of SCI games I believe this is the MAP file. Not sure what it will do when it does not recognize the hash. It may just throw a message of unknown fan SCI game. I'll have to test it this weekend.

Edit, I posted this before I realized that this had gone onto another page.

[troflip]

Thanks Collector, that works. I saw that before, but didn't realize you had to specify the path *and* the id (in this case sq5 works).

So while the debug spew functionality doesn't work, at least the "start the game in this room" functionality works, which is pretty useful.

[lskovlun]

I got too excited. Turns out RemapColors is only available in QfG4 Demo, because it replaces StrSplit.

And in SCI32. So it will be made, eventually.

[Kawa]

And in SCI32. So it will be made, eventually.

Ah, but only SCI32 games get the full RemapColors, no?

[lskovlun]

And in SCI32. So it will be made, eventually.

Ah, but only SCI32 games get the full RemapColors, no?

That depends. I think if the full SCI32 interface is just a superset of the SCI1.1 one, there is no reason to go out of our way to prevent SCI1.1 games from using it.  I'm not sure if this is the case exactly, but if you look at the source code for FileIO, it is shared with the older file API. SaveGame and friends, too.

There's a new guy on the ScummVM team who was working on some palette code a while ago. I guess it also depends on what kind of changes the full support would require. If they end up architecting a whole new palette manager for SCI32 then we might be in trouble. In that case, it's possible that the QfG4 demo will not be supported at all.

[Kawa]

That depends. I think if the full SCI32 interface is just a superset of the SCI1.1 one, there is no reason to go out of our way to prevent SCI1.1 games from using it.  I'm not sure if this is the case exactly, but if you look at the source code for FileIO, it is shared with the older file API. SaveGame and friends, too.

Tisn't quite. Comparing s_defaultKernelNames[] and sci2_default_knames[], if those numbers are supposed to be right... for example SCI0/SCI11 has Clone as function 4, but it's function 7 in the other list. DrawCel of all things seems to be missing entirely.

[lskovlun]

That depends. I think if the full SCI32 interface is just a superset of the SCI1.1 one, there is no reason to go out of our way to prevent SCI1.1 games from using it.  I'm not sure if this is the case exactly, but if you look at the source code for FileIO, it is shared with the older file API. SaveGame and friends, too.

Tisn't quite. Comparing s_defaultKernelNames[] and sci2_default_knames[], if those numbers are supposed to be right... for example SCI0/SCI11 has Clone as function 4, but it's function 7 in the other list. DrawCel of all things seems to be missing entirely.

I'm not talking about the order of kernel functions, I'm talking about the order of subfunctions of RemapColors. Where it gets mapped to in the kernel table doesn't matter (there's a bunch of things going on for SCI2/2.1 in that regard, too)...

[Kawa]

I'm not talking about the order of kernel functions, I'm talking about the order of subfunctions of RemapColors. Where it gets mapped to in the kernel table doesn't matter (there's a bunch of things going on for SCI2/2.1 in that regard, too)...

In that case, it still wouldn't work out:

Code: [Select]

RemapColors(0 percent)
RemapColors(1 from to base)
RemapColors(2) //turn off

RemapColors32(0) //turn off
RemapColors32(1 color from to base)
RemapColors32(2 color percent)
RemapColors32(3 color percent) //remap to gray
RemapColors32(4 color percent) //remap to % gray?So that's subop 0 and 2 reversed, plus of course the part where the demo version doesn't have a color parameter and just uses 254 instead.