Community
SCI Programming => SCI Development Tools => Topic started by: aardvark4lunch on February 11, 2016, 08:42:30 AM
-
Hey all. Game Designer and Voice actor here. I downloaded the new SCICompanion earlier today and started digging around some SCI1.1 games. Specifically I am interested in creating a Talkie patch for SQV. I poked around in SQIV and found it quite easy to record over existing voices, but I have no idea how to add voices to a previously voice-less game.
My problem is three fold from what I can tell.
1. the "speech and lip-syncing" option isn't available when I open a message file for SQV
2. I can force the aforementioned options to appear by going into version detector and ticking on "Supports Message Audio" (probably not a good work around :P), but when I record the message and then save, the program crashes.
3. Even if it saved correctly and put the speech in the game, would it play back properly? For example, SQV doesn't have a speech/text/both option in the menu. Would it know to play the audio?
I haven't worked on SCI games in a long time, so virtually any assistance/suggestions are appreciated.
-
I've actually tried this myself, by following the instructions Phil posted here (http://sciprogramming.com/community/index.php?topic=1458.msg7538#msg7538). Unfortunately, something about it reduced the on-screen text to just "M". Same in my own game. I might be doing something wrong myself, but you're just missing a bunch of steps.
The default framework, the template as it were, that Sierra used is all set up to play audio (where available) for any message spoken by the Narrator or any Talker, depending on the value of gMessageType/global90. So yes, it would know.
Oh, also? There are parts that would not. The intro, for example, when Roger dictates a log and it appears word-for-word? That uses messages as a source, but neither Narrator nor anything derived from it, so that wouldn't be automatically voiced.
-
I've actually tried this myself, by following the instructions Phil posted here (http://sciprogramming.com/community/index.php?topic=1458.msg7538#msg7538). Unfortunately, something about it reduced the on-screen text to just "M". Same in my own game. I might be doing something wrong myself, but you're just missing a bunch of steps.
The default framework, the template as it were, that Sierra used is all set up to play audio (where available) for any message spoken by the Narrator or any Talker, depending on the value of gMessageType/global90. So yes, it would know.
Oh, also? There are parts that would not. The intro, for example, when Roger dictates a log and it appears word-for-word? That uses messages as a source, but neither Narrator nor anything derived from it, so that wouldn't be automatically voiced.
Thanks, but I can't open the main script.
(forgive my noob-ness)
"---------------------------
SCICompanion
---------------------------
c:\users\stirling\desktop\sci\space quest 5\src\n000.sc could not be opened.
Would you like to see the disassembly instead?
---------------------------
Yes No
---------------------------
"
-
You gotta decompile it first. The whole thing, preferably.
-
Herp, my brain wasn't working there for a sec, thanks. Tried decompiling but it but it keeps crashing :(
-
You're attempting to do a pretty advanced thing that requires a good understanding of how the games are put together, and some programming knowledge... to my knowledge, no one has done this before, really.
Roughly speaking, here's what you need to do first:
- start with a fresh copy of your game files (if you've been mucking around with trying to add message audio in the wrong way, SCI Companion may have created a "bad" audio map file for the speech, or something like that). At any rate, start with a fresh copy of the original game
- rename resource.aud to resource.sfx. Speech and digital audio go in separate resource package files, and you'll end up deleting all digital audio in the game if you don't do this (since speech always goes in .aud, and digital audio sfx goes in .aud... or in games with speech it goes in .sfx).
- open the game in SCI Companion. Make the changes necessary as outlined in the thread that kawa linked (check "supports message audio", Set the Audio36 format to "sync map late", and set the Audio volume name to "aud/sfx", reload the game, and add an audio recording to a message resource, etc..).
- make sure the game still runs. Also, you should have both a resource.aud and a resource.sfx in your game folder now
At this point, you should have a game where you can add message audio, and the game should run. Might want to make a backup at this point.
Because now you have to start mucking with scripts. The first thing is to decompile all scripts:
http://scicompanion.com/Documentation/decompiler.html
At the very least, you're going to need to make changes to the Main.sc script. After decompiling things, you should be able to open the Main.sc (and not get the warning message asking if you want to disassemble it).
One other thing is that you'll want to open Tools->PReferences and uncheck " save scripts before run" and " Compile modified scripts before run", or else Companion will recompile scripts that depend on Main after you change Main. Not a huge deal, but to minimize risk (e.g. to change as few script resources as possible to avoid any decompiler bugs) it's a good idea.
Next, in the Main.sc script, you'll want to change the two places that global90 is set to 1, to instead have it set to 2. This switches from text mode to speech mode. Compile, and run the game.
And now... you'll hear nothing when the speech is supposed to play. Haha... I just tried this, and that's what happened anyway. It paused for roughly the right amount of time while the speech played, but I heard nothing.
-
Keeps crashing while decompiling :(
What version of SCI Companion are you using?
Can you send me a zipped up copy of your game folder?
(you don't have a debugger or anything attached to SCI Companion, do you?)
Is this just a standard "this program caused an error and needs to close" Windows error message?
When exactly during decompilation does it crash?
-
https://drive.google.com/file/d/0B2QwV5L8BhSKemFFWHp4cDFwOW8/view?usp=sharing
(http://i.imgur.com/FkTCOm7.png)
Thanks for helping by the way. I can debug with visual studio, yes. I'm using SCICompanion version 3.0.1.7
-
Thanks for this. I can actually repro the crash! So your SQ5 must be different than my copy for script 924... let me see what's going on.
Of note, it looks like you have a 924.scr patch applied to this game... suspicious. Mine doesn't have that. Is it an official Sierra patch, or some fan-made patch?
(Also of note, if you do end up compiling any scripts, you'll need to delete any .scr and .hep patch files for that script, or else the game won't pick it up - since SCI Companion builds the scripts into the resource package, and patch files always take precedence)
-
Thanks for this. I can actually repro the crash! So your SQ5 must be different than my copy for script 924... let me see what's going on.
Of note, it looks like you have a 924.scr patch applied to this game... suspicious. Mine doesn't have that. Is it an official Sierra patch, or some fan-made patch?
(Also of note, if you do end up compiling any scripts, you'll need to delete any .scr and .hep patch files for that script, or else the game won't pick it up - since SCI Companion builds the scripts into the resource package, and patch files always take precedence)
924.scr patch was my attempt at replacing Messager.sc with the one from the template game. I must reiterate, I really don't know what I'm doing as far as SCICompanion goes.
And now I'm getting an error compiling. [Error]: new is not a property or method on type 'SpeakWindow'. Line: 577, col: 38
03:14:50AM
-
924.scr patch was my attempt at replacing Messager.sc with the one from the template game. I must reiterate, I really don't know what I'm doing as far as SCICompanion goes.
Oh yeah, you can't just plop in a script from another game and expect it to work. The SCI1.1 template game *was* based on SQ5, but it's had modifications so it can run on the LSL6 interpreter. And for scripts, the script resource (.scr) is paired with the heap resource (.hep). So at the very least you need both those (you only copied the .scr).
But at any rate, you should start with a clean version of your copy of SQ5, and follow the instructions I listed above. Decompilation should work fine and not crash.
The needed changes to the Messager script should be accomplished by decompiling that script, changing the source code and recompiling it.
*******
As for the feasibility of accomplishing your goal, there are two things to note:
- The SQ5 Messager class doesn't handle printing text and having speech at the same time (which is true for the majority of Sierra games, I think). The SCI 1.1 template game was modified in a few spots to allow for both. So if you want speech and text at the same time, there will need to be some changes. If you just want all speech (global90 set to 2) or all text (global90 set to 1), then this shouldn't be an issue.
- I haven't even been able to get the speech to work by making the changes I listed above (as I mentioned). I don't know if this is a problem with the SQ5 interpreter not allowing it, some remaining changes that need to be made in the script resources, or some issue with the audio drivers included with SQ5.
-
I started from a clean version, and decompilation went smoothly. However, I changed the global90 variable and now I'm getting an error when I try and compile [Error]: new is not a property or method on type 'SpeakWindow'. Line: 577, col: 38
03:14:50AM
I may just have to give up. I don't know enough about SCI to mess about and experiment and if you can't figure it out, there's no way I will be able to :P
-
I started from a clean version, and decompilation went smoothly. However, I changed the global90 variable and now I'm getting an error when I try and compile [Error]: new is not a property or method on type 'SpeakWindow'. Line: 577, col: 38
Works fine for me using your zipped SQ5 (after I deleted the 3 .scr files you added, deleted the src folder and re-decompiled everything). What does your SpeakWindow.sc look like?
-
Don't give up, this just gives us a project to work out together. This place needs activity.
-
What does your SpeakWindow.sc look like?
A little like this:
;;; Sierra Script 1.0 - (do not remove this comment)
(script# 877)
(include sci.sh)
(use n958)
(use n981)
(class SpeakWindow of SysWindow
(properties
top 0
left 0
bottom 0
right 0
color 0
back 15
priority -1
window 0
type $0000
title 0
brTop 0
brLeft 0
brBottom 190
brRight 320
lsTop 0
lsLeft 0
lsBottom 0
lsRight 0
eraseOnly 0
hMargin 0
vMargin 0
tailTop 0
tailLeft 0
tailBottom 0
tailRight 0
tailBits 0
tailX 0
tailY 0
isBottom 1
xOffset 0
underBits1 0
underBits2 0
)
(method (init)
(super init: &rest)
(proc958_0 128 993)
)
(method (dispose &tmp temp0)
(super dispose: &rest)
(= temp0 (GetPort))
(SetPort 0)
(Graph grRESTORE_BOX underBits1)
(Graph
grUPDATE_BOX
tailTop
tailLeft
tailBottom
tailRight
1
)
(SetPort temp0)
)
(method (open &tmp [temp0 2] temp2 temp3 theLeft [temp5 2] temp7 temp8 temp9)
(SetPort 0)
(= priority 15)
(= color 0)
(= back 6)
(= temp8 1)
(if (!= priority -1) (= temp8 (| temp8 $0002)))
(= temp2 (- right left))
(= temp9 (- bottom top))
(cond
((not xOffset) (= temp3 2))
((< 0 xOffset) (= temp3 0))
(else (= temp3 1))
)
(if (not isBottom)
(= temp3 (+ temp3 3))
(= lsTop (+ tailY (CelHigh 993 0 temp3)))
(= top (+ lsTop 3))
(= bottom (+ top temp9))
(= lsBottom (+ bottom 3))
else
(= lsBottom tailY)
(= bottom (- lsBottom 3))
(= top (- bottom temp9))
(= lsTop (- top 3))
)
(= lsLeft
(- (= theLeft (+ (- tailX (/ temp2 2)) xOffset)) 3)
)
(= left theLeft)
(= right (+ left temp2))
(= lsRight (+ 4 right))
(= type 128)
(= tailTop tailY)
(= tailLeft tailX)
(= tailBottom
(+ tailY (if isBottom -2 else 1) (CelHigh 993 0 temp3))
)
(= tailRight (+ tailX (CelWide 993 0 temp3)))
(= underBits1
(Graph
grSAVE_BOX
tailTop
tailLeft
tailBottom
tailRight
temp8
)
)
(super open: &rest)
(= temp7 (GetPort))
(SetPort 0)
(Graph
grFILL_BOX
(- top 3)
(+ left 3)
(+ bottom 2)
(- right 3)
temp8
back
priority
)
(Graph
grFILL_BOX
(+ top 3)
(- left 3)
(- bottom 3)
(+ right 3)
temp8
back
priority
)
(DrawCel 993 1 0 (- left 3) (- top 3) priority)
(DrawCel
993
1
1
(+ (- right (CelWide 993 1 0)) 3)
(- top 3)
priority
)
(DrawCel
993
1
3
(+ (- right (CelWide 993 1 0)) 3)
(+ (- bottom (CelHigh 993 1 0)) 3)
priority
)
(DrawCel
993
1
2
(- left 3)
(+ (- bottom (CelHigh 993 1 0)) 3)
priority
)
(= temp2 6)
(= temp9 3)
(Graph
grDRAW_LINE
lsTop
(+ left temp2)
(- top temp9)
(- right temp2)
7
-1
-1
)
(Graph
grDRAW_LINE
(+ top (* temp9 2))
lsLeft
(- bottom (* temp9 2))
lsLeft
7
-1
-1
)
(Graph
grDRAW_LINE
(+ top (* temp9 2))
(- lsRight 2)
(- bottom (* temp9 2))
(- lsRight 2)
5
-1
-1
)
(Graph
grDRAW_LINE
(- lsBottom 2)
(+ left temp2)
(- lsBottom 2)
(- right temp2)
4
-1
-1
)
(Graph
grDRAW_LINE
(- lsBottom 1)
(+ left temp2)
(- lsBottom 1)
(- right temp2)
0
-1
-1
)
(DrawCel
993
0
temp3
tailX
(+ tailY (if isBottom -2 else 1))
priority
)
(Graph grUPDATE_BOX lsTop lsLeft lsBottom lsRight 1)
(Graph
grREDRAW_BOX
tailY
tailX
(+ tailY (if isBottom -2 else 1) (CelHigh 993 0 temp3))
(+ tailX (CelWide 993 0 temp3))
)
(SetPort temp7)
)
(method (move param1 param2)
(= top (+ top param2))
(= left (+ left param1))
(= bottom (+ bottom param2))
(= right (+ right param1))
)
(method (moveTo param1 param2)
(self move: (- param1 left) (- param2 top))
)
(method (repos param1 param2)
(= top (+ top param2))
(= left (+ left param1))
(= bottom (- bottom param2))
(= right (- right param1))
)
)
-
Don't give up, this just gives us a project to work out together. This place needs activity.
Thanks, I just don't want to come across as someone who demands everyone to do what they want without pulling their own weight.
-
Not sure what you're got going on exactly (I suspect maybe some turds left over from a previous decompile), but here's a link to a version that works:
https://drive.google.com/file/d/0B7AkuhunCLJTamxyVWxXdlVWVms/view?usp=sharing
It should be able to compile Main.sc just fine (I've already changed the global90 to 2 to enable speech). I added speech to an entry in message resource 110.
It "works" as in it's ready for someone to hack on... but there's no speech actually being heard when you run the game in DOSBox. The speech *does* work in ScummVM though... so that's a start.
It's possible the Sierra SQ5 interpreter just doesn't support the DoAudio kernel call that takes a message entry identifier. Or maybe the audio driver just needs to be changed.
-
Tangentially related, but I did it! I got "both" to work in my game! No more trying to display audio as text!
First, in Talker.sc, I changed Narrator::say:
(method (say theText theAudio theCaller)
(if gIconBar (gIconBar disable:))
(if (not initialized) (self init:))
(= caller (if (and (> argc 2) theCaller) theCaller else 0))
(if (& gMessageType $0001) (self startText: theText))
(if (& gMessageType $0002) (self startAudio: theAudio))
; ...Then in Messager::sayNext:
(if (!= theTalker -1)
(talkerSet add: theTalker)
(theTalker modNum: theModNum say: @buffer temp201 self theModNum noun verb case seq)
; temp201 being the audio handle and buffer being the text.
;;; (if (& gMessageType $0002)
;;; (theTalker modNum: theModNum say: temp201 self theModNum noun verb case seq)
;;; else
;;; (theTalker
;;; modNum: theModNum
;;; say: @buffer self theModNum noun verb case seq
;;; )
;;; )
(++ curSequence)
; ...
-
Tangentially related, but I did it! I got "both" to work in my game! No more trying to display audio as text!
That's great to hear :D
Hopefully someone can get it working in SQV.
-
Well aardvark4lunch, considering SQV reacted the same way my game did when I last tried to talkify it...
Other thing I've done to SQV: made the log part of the intro type character-by-character.
-
Well aardvark4lunch, considering SQV reacted the same way my game did when I last tried to talkify it...
True. It'd be great if we could get a SQIV style button to switch between them.
-
The SCI 1.1 template game supports all of this, btw. Text-only, speech-only, or both, with a button to switch between them. So it's just a matter of adapting that code.
-
The SCI 1.1 template game supports all of this, btw. Text-only, speech-only, or both, with a button to switch between them. So it's just a matter of adapting that code.
Does it really support both though? Cos I'm looking at the template right now and it too uses either temp201 or @buffer. It too would logically try to display non-text data if it were set to "both", it seems to me.
-
It does, try creating a new game, switch into "both" mode and "look" at the room background.
I patterned it after one of the Sierra games that offered a "both" mode (EcoQuest CD maybe?). I remember the code being a little weird, maybe your way is better.
[edit:]
Yeah, when in "both" mode, startText: does some needless calculations for StrLen and ticks (which then gets immediately overridden by startAudio). When display: is called, if the messagetype has the speech flag (0x2), it uses the data in the buffer to obtain the actual text via a call to msgGET.
-
*looks*
Ah.
That's a bit wasteful, innit? Cos no matter the gMessageType value, Messager::sayNext will have its own copy of the actual line.
Edit: It seems EcoQuest doesn't have a Messager -- it invokes Talkers directly, as if using text resources instead of messages.
Edit?: Aw dammit, my research took too long :D
-
Yup, looks like it's a waste. Oh well. EcoQuest had a simpler "Messager" that didn't have all that logic in it, so that's why it had that cruft in its Talker.
-
It paused for roughly the right amount of time while the speech played
Not sure how true this is. Just recorded quite a long clip and it played for the same short amount of time.
Also, is the last version you uploaded still based on the copy I sent you? Because in the version you uploaded, it has far fewer sound effects to my version. Whirring of the simulator, hissing sound when it opens etc. Not sure if it's just because of different versions, or if it has something to do with the voices not playing either.
-
Not sure how true this is. Just recorded quite a long clip and it played for the same short amount of time.
Ok, then that means it's really not seeing the audio. So that might mean the DoAudio kernel in the SQ5 interpreter just doesn't handle the aud36 resources that are used for speech.
Also, is the last version you uploaded still based on the copy I sent you? Because in the version you uploaded, it has far fewer sound effects to my version. Whirring of the simulator, hissing sound when it opens etc. Not sure if it's just because of different versions, or if it has something to do with the voices not playing either.
Nope, the version I uploaded was based on the original.
-
Not sure how true this is. Just recorded quite a long clip and it played for the same short amount of time.
Nope, the version I uploaded was based on the original.
So whatever we've done that's stopped the sound effects from playing might be the same thing that's stopping speech from playing?
I went through the process again, running the game everytime to see when the sound effects stop. They stop when you rename resource.aud to resource.sfx.
-
Oops, yeah, I didn't even notice that, sorry. For some reason I thought I was hearing digital sfx still working when I renamed resource.aud to resource.sfx, but it looks like I was mixing them up with the midi sfx.
So it sounds like the SQ5 interpreter really doesn't support what you're trying to do.
In that case, it sounds like your options are:
- be ok with it only working in ScummVM (you can talk what you have right now and it appears to work), or
- switch to using the LSL6 interpreter, which does support speech
The SCI 1.1 template game is based on SQ5, but uses the LSL6 interpreter. So... it's possible to do this, but it wasn't trivial. You'll get to know SCI really well if you attempt this :-). Unfortunately I don't have time to help with this, but hopefully other forums members might be able to. There should be some threads buried in here somewhere about problems I ran into, and the solutions (often with great help from Lars, who works on the SCI part of the Scumm interpreter). Off the top of my head:
- some of the base classes (View, Prop, Actor, etc..) might need to have a property added here and there
- vocab 994 (I think?) needs to be the one from the LSL6 interpreter
- there's a version stamp that needs to be changed somewhere (was it in resource.map? I forget).
- the global variables may need to be move around a bit
-
- be ok with it only working in ScummVM (you can talk what you have right now and it appears to work), or
Holy crap. The one you uploaded is working in scummVM. Not sure if it'd be worth the effort figuring it out for dos if it's already working in scummVM
https://www.youtube.com/watch?v=hb7ien-ChUA&feature=youtu.be&ab_channel=Aardvark4lunch
Video quality is crap and yes, the voiceovers are terrible. I just quickly recorded them with my webcam to test.
-
What's this about SQV's terp not supporting speech? I heard it myself, right? I mean, with broken "both" support but...
-
It would absolutely be worth making it work in DOS because ScummVM isn't perfect and not everybody uses it.
-
I was surprised to find that lip sync works with dialogue portraits automatically. But there are still many things that need to be fixed. When you skip dialogue for example, it gives control back to the player but the speech keeps playing.
It would absolutely be worth making it work in DOS because ScummVM isn't perfect and not everybody uses it.
Damn. Seems like an awful lot of (advanced) work and I have zero experience with this kind of thing :S
-
It would absolutely be worth making it work in DOS because ScummVM isn't perfect and not everybody uses it.
Agreed.
-
I'd be happy to try and get it working in DOS. But I don't really know what I'd need to do, or more specifically how to do it.
-
I'd be happy to try and get it working in DOS. But I don't really know what I'd need to do, or more specifically how to do it.
Basically, you have to replace the interpreter (sierra.exe) with one from a game that supports speech (aud36 resources), such as LSL6. Then you need to modify the game files so it works on that interpreter*.
Here's a link to the thread where I did this last year, when I was paring down SQ5 into a minimal template game, and I/we decided to use the LSL6 interpreter instead:
http://sciprogramming.com/community/index.php?topic=1383.msg6268#msg6268
*That's the hard part.
-
Then you need to modify the game files so it works on that interpreter*.
How much would need to be changed? Just a few scripts? Or every script in the game?
-
It depends on which classes (or kernel functions?) are the same or different between interpreters. Not every game has the same ones, hence the differences. If one game does something a certain way with one interpreter, it might not work the same in another. ScummVM mostly works because it supports *all the interpreters.
*most, as close as possible. Which means that if it does work in ScummVM, it's probably possible with some combination of script and DOS interpreter.
-
Probably a few scripts would need to change, as there may be some kernel differences as MI indicated. And even though the classes are totally separate from the kernel, the interpreter does make some assumptions about what methods and properties are on each class. But I suspect they're fairly minor, given that I was able to "port" a trimmed down SQ5 to the LSL6 interpreter (but more differences may be exposed if you're trying to get the whole game working on LSL6 terp).
You'll see in the thread I linked that vocab.994 needs to tightly tied to the class hierarchy, as this provides a map of which properties are where in various core classes. That is, it contains information like "x is the 10th property on the Actor class". If this doesn't match exactly, nothing will really work. I forget what changed I made. I *think* I just grabbed the vocab.994 from LSL6 and used that, and then made sure that core classes (Feature, Prop, Sound, Ego, Room, Region and every other class that inherits from them etc...) has property lists that matched the LSL6 classes. Maybe I didn't even need to make any changes, I forget. At any rate, it should be easy to compare the SCI 1.1 template game core classes to those you get from decompiling SQ5, and see if there are any differences in the property lists (I added a "case" property to Feature and its subclasses, that's unrelated, you can leave that out). The SCI Companion documentation has diagrams that show the class hierarchy well.
I think there's also a version number in the resource.map file that would need to be manually "hex-edited" otherwise the interpreter will reject the game completely. It's near the beginning of the file, it should maybe be obvious by comparing the resource.map of SQ5, LSL6 and the SCI 1.1 template game. Oh, it actually looks like I hard-coded it to the LSL6 version number when writing out the SCI1.1 resource maps, so maybe there's nothing to do here except "rebuild resources", which is what will write it out. I hope I didn't break things for other games, yikes.
Finally, I think there were some global variables that needed to be correct, this thread might be useful:
http://sciprogramming.com/community/index.php?topic=1421.15
The actual set of changes required is probably small. But when something isn't working, it can be very hard to find out why.
-
But I did try to talkify SQV before and it worked. I don't recall switching terps.
-
What was the version of the interpreter? There may have been different versions (e.g. for the international flavors of SQ5?).
How did you handle separating the regular digital audio resources with the speech ones? Did you copy the resource.aud to resource.sfx (which the SQ5 terp I have doesn't seem to understand) first? Otherwise it seems like the audio resources could clobber the aud36 ones, or vice versa.
If you have something that's working, seems like it would be useful to upload it somewhere.
-
1. My copy of SQ5 was English-only, but to be entirely honest I can't quite confirm that it was the same terp.
2. I did not bother with the digital audio resources.
3. I threw it away after finding "both" was broken, but if you insist I can do it again with a fresh copy.
-
That would be greatly appreciated, if you have the spare time.
-
I have all the time. I'll be off to get that fresh copy now.
Okay, got my results. The terps from Space Quest V (as in, the one that came with this download) and Freddy Pharkas (disk version) did not do any speech at all, while the terps from King's Quest 6 and Freddy Pharkas (both CD versions), Larry 6 (low-res version), and The Dating Pool (my project) did, but then the sound went haywire and DOSBox itself froze to death. Which is quite interesting.
Switching the value of global90 was easy though. I suspect editing the messenger and narrator the way I did in my game wouldn't be too difficult either.
For reference:
terp hash result
catdate 2E7B25F3B1C2A5C792C731EE46A30A12 speech, noise crash after
fpfp 7CC5255876F22D531A261D06FED6349A no speech
fpfp-cd DF7E4339E89DFEE3795CE3612FC536E2 speech, noise crash after, palette issue
kq6-cd 167E51135DD3EC70E96E4DF9B38541A5 speech, noise crash after
lsl6 2E7B25F3B1C2A5C792C731EE46A30A12 speech, noise crash after
sq5 B1D29B42DE35F70265852D42BE8FFD62 no speech
Aaand only now do I realize catdate uses the larry 6 terp. Huh.
-
I'd tried the KQ6 one earlier. Got excited for a sec, then the glitched music hit. Yikes. Not sure where to go from here. Any idea why it would be doing it to the music?
-
Absolutely none.
-
I'm guessing it's nothing TOO complicated. I just need to figure out what it is. :/
EDIT 1: Huh. I deleted resource.sfx and now the KQ6 terp is working with SQV with music and voices working in DOSbox. Only problem is text and speech don't seem to be working global90 is set to 3 in both places and yet, voices only.
EDIT 2: Welp, seems like resource.sfx is mostly used for comedic scream sounds. :/ That narrows it down at least. Just gotta figure out why the terp doesn't like resource.sfx
(http://i.imgur.com/wpkEOsg.png)
-
Some info that may be useful...
You'll note that for versions of the interpreter that don't support speech (SQ5), the games tend to come with resource.aud, which is where the digital audio resources are placed (which share the same "number namespace" as the midi sounds).
As best I can tell (and this is what SCI Companion assumes), for interpreters that do support speech, the audio were moved to resource.sfx, and resource.aud becomes the place to put speech (aud36) resources.
In addition to the package files mentioned above (which contain the actual audio data), there are the map resources that tell where in the package files the audio data starts for a particular resource number.
For audio resources, the corresponding map resource is 65535.map (occasionally 0.map in some games). For aud36 resources, the map resource is [nnnnn].map, where nnnnn corresponds to the speech resources for a particular room number. So there are lots of map resources for speech.
There are three possible formats for the 65535.map file (shown as 5 bytes, 6 bytes or 8 bytes in SCI Companion, as that's how large each entry is). For the [nnnnn].map files for the aud36 resources, there are 2 possible formats (shown as Sync map late, or Sync map early).
Sometimes 65535.map is its own file, sometimes its embedded in resource.map/resource.000 like a normal resources (I'm not sure if matters to the interpreter). The [nnnnn].map resources are either found in message.map (most commonly), or sometimes resource.map with the regular resources, or sometimes altres.map.
Now, if you start trying to manipulate the resources in SCI Companion while moving files around and stuff, and the way you have the files set up doesn't match a normal game... s*** can get f***ed up. For instance, while I was initially playing around with this, I hadn't changed resource.aud to resource.sfx, so resource.aud was getting filled with both audio and aud36 resources.
It looks like there bug in SCI Companion in that it doesn't display the correct "audio map format" if 65535.map is not a lone file (i.e. if it's embedded in resource.map/resource.000). However, I will tell you that, from what I can tell, 65535.map is:
- LSL6: 6 bytes
- SQ5: 5 bytes
- KQ6: 6 bytes
- KQ6 CD: 5 bytes
So if digital audio sfx stop working when switching the terp from SQ5 to LSL6, that could be the reason (not sure if later terps can handle various audio map formats or not). If that's indeed the case, then to move the digital audio over, you'd need to export all the audio resources and then add them back in. Of course, when adding them back in, you'd need to start with an audio map that is compatible with the newer interpreter, otherwise Companion will still write the old format.
-
Ok, I got a lot of stuff working, Music works no problem now. Voices work too (where I've done them). and the "Doh!" ect. SFX are working too. jsut a couple problems remain.
1.text and speech is still not working
2. when dialogue is skipped, the last voice file keeps playing after the player is given back control
3. I fear I have gotten the stuff working in a really dumb way.
If someone with more experience could look over my work, that'd be much appreciated.
https://drive.google.com/file/d/0B2QwV5L8BhSKak9DNEQ3aFRfMUk/view?usp=sharing
-
Problem 1 is already solved, sort of (http://sciprogramming.com/community/index.php?topic=1577.msg8632#msg8632).
-
Weird. I can't find a talker script in my SQV 0_o
EDIT: I just realised I have no idea where to implement the code. If you've already managed to do it in your game, could you possibly have a go of getting it to work in the version I uploaded earlier?
-
Talkers aren't the first thing in their script block. You'll want Blink.sc. The Narrator class is the second one defined therein, and Blink is the first, so the file is autonamed such.
-
I'm getting a whole lot of errors when I recompile. Thanks to the new terp no doubt.
-
I do doubt it.
-
Well, you would know. Again. I have zero experience in SCICompanion
-
The compiler is completely ignorant of the interpreter, so compile errors have nothing to do with that.
Your scripts aren't compiling because they seem to reference a bunch of global variables that don't exist (i.e. in Main.sc, the global variables generally have retained their "globalNNN" names, whereas they have nicer names in the other script files). As I mentioned in another thread (or this one? I forget), you'll need to decompile all scripts a few times in order for the global variable names to propagate around.
You've also got about 150 patch files in your game directory, include lots of .aud, some .hep and .scr, and even 65535.map, the audio map. Not sure how this happened.
Given that SCI Companion writes resources to the resource packages and not the patch files, this is going to seriously mess things up.
-
I patched the AUD files because they all broke when I changed the terp. (again, with the me not knowing what I'm doing).