Community
SCI Programming => SCI Community How To's & Tutorials => Topic started by: troflip on July 09, 2015, 11:34:44 PM
-
Later tonight I hope to have the first part of a little project ready... a room that is used to explore all the palette APIs. I'll upload it when it's ready.
I have a little problem maybe someone has come across. I have an object that can be in one of three states. I was trying to use the condition to have 3 different look messages displayed, but it turns out Feature doesn't have a cond property. So my solution was to change the feature's noun property. Does that sound right? (I know I could write code to call gTestMessager:say directly, but this seems like a common case that shouldn't require that).
Another issue I just ran into is it appears only one sound can play at a time. Has anyone else encountered this? I have a short sound that doesn't loop. I play that, then I try to play a looping sound and it fails. I tried using gSq5Music1 to play the looping sound, and I get the same result. Any subsequent sound overrides the previous playing one. Can't we play multiple sounds at once? gPolyphony is set to 9.
[edit:] Hmm... I guess my answer comes from running it in Scumm... Scumm outputs some message saying a sound was already playing. So I guess the answer is no, you can't play two sounds at once! I guess I'll have to use a midi file for my looping drone noise.
-
Are you referring to digital sounds? Yeah, only one at a time sounds right. Can you play more than one MIDI sound at a time? I guess it would depend on what channels/instruments are already being used?
-
I have a little problem maybe someone has come across. I have an object that can be in one of three states. I was trying to use the condition to have 3 different look messages displayed, but it turns out Feature doesn't have a cond property. So my solution was to change the feature's noun property. Does that sound right? (I know I could write code to call gTestMessager:say directly, but this seems like a common case that shouldn't require that).
From what I have seen, calling the messager directly seems to be the common case in a doverb method of the feature or props instances.
-
Here it is...
From the main room, walk through the door to the north into the "palette room". It shows off palette cycling, palette transitioning, and palette intensity variations. Also some cool tricks with assigning regions of the palette to different parts of the picture, which will be much easier with the next update to SCI Companion ;)
-
Oh good! Looking forward to that new update! Thank you for this demonstration room! I'll be making good use out of it!
-
Err...the button to turn on the big screen does nothing.
EDIT: Never mind, it was just difficult to walk towards it.
-
Yeah, I'm still having trouble with the walking. It was working for a while, then I moved objects around, and now sometimes the ego gets caught. I think the approach x/y and the polygon boundary are competing or something :-(
[edit:] Ah, I see. I was missing ignAct. Updated Explore.zip now.
-
Nice room edit. 8)
-
Here it is...
From the main room, walk through the door to the north into the "palette room". It shows off palette cycling, palette transitioning, and palette intensity variations. Also some cool tricks with assigning regions of the palette to different parts of the picture, which will be much easier with the next update to SCI Companion ;)
Does it also show off PalVary (aka "Intersections")? You do mention transitioning, but I think that it would be a good idea to fix this name for discoverability...
-
Does it also show off PalVary (aka "Intersections")? You do mention transitioning, but I think that it would be a good idea to fix this name for discoverability...
Hmm... I guess not, because I'm not sure what you mean?
It shows off transitioning to another palette with PalVary(pvINIT ... ). What name do you want fixed?
-
This may have been fixed already, but in some games, calls to PalVary are annotated as Intersections. Even LSL6, which is used for the template game. But if you are using it already, then I suppose it's OK.
(and yes, there is the problem of different games mapping kernel functions differently)
-
A few more screenshots...
-
Ok, what is the secret here for getting the palette from Photoshop to show up in the same order when I import the background into companion. One screenshot shows what photoshop showed me as the palette, and the other is what I could get companion to do with it. I was hoping to pull off some fancy shit with palette cycling of some water (especially if you recognize the palettes from anywhere) but that really isn't going to be possible with them scrambled up.
I have the adobe suite, so if I need to be using another program to get my palette to transfer from the image software into companion that is fine, just someone please fill me in on the best way to accomplish this please.
-
You need to select "use imported image palette" in the Import background dialog. I'm guessing you have it set to "Generate best palette".
I'm seeing some issues with Companion not recognizing palettes though... let me see if it's a bug, or if there's something wrong with the files I'm using...
-
Ok, I only see a problem when using multi-frame gifs for pic backgrounds. For single-frame gifs, it works fine, and I can select the range of palette indices to use with "Use imported image palette".
Also, this is how I did some palette cycling, it might be of help:
http://scicompanion.com/Documentation/palettecycling.html