(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.
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." 8)
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)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: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?
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]
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.
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, what was the code you used for that thing with the two sounds and the handle?
/******************************************************************************/
(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)
)
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.
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.
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.
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.
"C:\Program Files (x86)\ScummVM\scummvm.exe" --config=scummvm.ini sq5-demo[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
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.
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.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.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)...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)...In that case, it still wouldn't work out:
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.
What does remapcolors do? How is it different than just setting a palette entry?Among other things, it allows dynamic-like shadows.
What does remapcolors do? How is it different than just setting a palette entry?More concretely, the colors between 236 and 254 are treated specially (actually, that range is divided in two for reasons that I don't fully understand). When a view contains these colors, they affect things that are drawn on top and below (by altering their brightness, by displaying them in black & white, etc.). The desired effect of each color in that range is set with an initial call to RemapColors (typically in the room init) and the system takes care of the rest. This is in contrast to setting palette entries manually, where the script must do something on each game cycle.
| Demo version | Presumed full version equivalent | Used for |
| StrSplit(0 50) | RemapColors(2 254 50) | 50% shaded shadow |
| StrSplit(1 112 175 62) | RemapColors(1 254 112 175 62) | Torch effect in starting cave |
| StrSplit(2) | RemapColors(0) | Unused in demo |
Except in the QFG4 Demo, which assumes color 254 and doesn't accept anything else~(I was talking about SCI32)
(I was talking about SCI32)And I was talking about the different parameters for RemapColors between versions. There is no conflict here. :)
| Demo version | Full version equivalent | Used for |
| StrSplit(0 50) | RemapColors(2 254 60) | 50/60% shaded shadow |
| StrSplit(1 112 175 62) | RemapColors(1 253 112 175 62) | Torch effect in starting cave |
/td]
|