SCI1.1 Picture transition speeds?

[Cloudee1]

Also, looking at this a bit more... I am pretty sure that the while loop in the fadeCode can be removed. It is in the doit method, but after the palette intensity has been changed. I would assume that this was intended to build in a bit more delay for a slower fade, but because of where it is, it is accomplishing nothing. I have done a bit of editing so that the while loop now does what I think it was supposed to be doing from the beginning

So First, I renamed the local variables per Phil's suggestion as well as included a new one which is going to be our delay time. The larger it is set, the slower the fade occurs.

Code: [Select]

(local
fCurrent
fTarget
fIncrement
fCallBack
fDelay
)

Then we have our fadeCode of Code instance.

Code: [Select]

(instance FadeCode of Code
(properties)
    (method (init param1 param2 param3 param4)
        = fCallBack 0
        = fDelay 10
        (if (>= paramTotal 1)
            = fIncrement param1
            (if (>= paramTotal 2)
                = fTarget param2
                (if (>= paramTotal 3)
                    = fCallBack param3
                    (if (>= paramTotal 4)
                    = fDelay param4
                    )
                )
            )
        )
        (send gTheDoits:add(self))
    )
    (method (doit)
    (var temp0)
       (while (< temp0 fDelay)
       ++temp0
       )   
       (if(== temp0 fDelay)
          (if (<> fCurrent fIncrement)
            = fCurrent (+ fCurrent (* 1 fTarget))
            Palette(palSET_INTENSITY 0 255 fCurrent)
            = temp0 0
          )
          (else
            (send gTheDoits:delete(self))
            (if (fCallBack and IsObject(fCallBack))
                (send fCallBack:cue())
                = fCallBack 0
            )
          )
   )// end if temp = fDelay
    )
)

To make use of it, heres an example of fading in and out.

Code: [Select]

//FadeIn
(FadeCode:init(100 1 self 10000))// fTarget   fIncrement   fCallBack   fDelay

//FadeOut
(FadeCode:init(0 -1 self 100)) // fTarget   fIncrement   fCallBack   fDelay

And there you go, a variable speed fading screen

[OmerMor]

Nice!
Why don't you rename the parameters to something more meaningful than param#, e.g. pCallback?

[MusicallyInspired]

Hmmm...how does one turn off a palette cycling animation? I've run into a problem where I'm drawing a new picture within the same room and the palette is still cycling but now it's a different palette and random colours are going crazy lol.

[troflip]

Simply by not calling Palette(palAnimate... ). You must be calling it in the doit method or something.

[MusicallyInspired]

Like I said I'm in the same room, I'm just drawing a new picture in a new case of the room's changeState method. Can you not just stop cycling whenever you want or do you HAVE to switch rooms?

EDIT: Oh wait, it is in the doit method! Err...but if I put it anywhere else it doesn't animate.

I also still can't figure out why I can't draw a new picture (with DrawPic) without the dumb game looking for 100msg and displaying whatever's in it rather than the main title menu it's supposed to have. The only thing that triggers that is my extra code that draws a new picture. It doesn't make sense.

[troflip]

Just set a local variable to some value when you draw the new pic, and then make the Palette call conditionally on that local variable.

Or switch to a new Script for the room when you do the drawpic - one with a doit that doesn't cycle the palette.

Lots of ways to handle this.


The 100.msg not found thing is a bit baffling. The DrawPic kernel must call back into the game, and maybe the interpreter is calling into the wrong game code or something. I can repro it, let me take a look.

[MusicallyInspired]

Ok, I figured it out. I guess the palette cycler has to be in the doit method to get triggered constantly or nothing happens. The variable idea worked great thank you.

I think I know why it keeps looking for 100.msg, though. It only happens when I click the mouse which means that it's look for a verb interaction for the room. How do you disable mouse verb interactions so that clicking on nothing doesn't try to do anything?

[troflip]

Ok, I think I know what's going on. Sort of.

First, it looks like this is caused by falling through to super:handleEvent in rm100:handleEvent.

Why does it do this? Look at the logic... if the current room state is 4, then it will call super. I guess in the normal case, an event will never be received while in state 4. (Although state 4 lasts for 5 cycles, so I don't see why an event couldn't come through if you clicked fast enough. Anyway, putting a DrawPic in case 4 has changed things. I'm not sure exactly how the interpreter handles events while a DrawPic transition is happening... but I guess events can come through? Hmm, no that doesn't really make sense. Maybe they are batched and get processed in the next frame immediately, and we're still in state 4.... anyway, I'm not positive.

[edit:] Ok, well if I increase the cycles from 5 to 20 or so, I start being able to repro the problem. I'm not sure why less than that makes it impossible to repro.


As for stopping the 100.msg from coming up, I was able to put an empty doVerb method in rm100:

Code: [Select]

(method (doVerb theEvent)
             // don't call super!
)

I'm not sure if that's the "prescribed" way or not (maybe looking at title screens in other sierra games would clarify), but it seems to work.

[MusicallyInspired]

Thanks! That'll do for now. Will look into it in the future.

[lskovlun]

As for stopping the 100.msg from coming up, I was able to put an empty doVerb method in rm100:

Set the claimed property of the event to TRUE.

[troflip]

I tried that (for evVERB), but it didn't work. And I didn't want to eat all mouse events. It looks like the manufactured evVERB event never comes through Rm's handleEvent? (I assumed it did because the Sierra code was testing for it).

There's something more going on here. Rgn's handleEvent just passes events of any type to doVerb if they're not claimed. That feels like something that shouldn't happen?  (It looks like the "verb" event is created in IconBar::handleEvent, which must not be hit in this case (I guess because it's been disabled on the title screen)).

[troflip]

Regarding the palette cycling, I wonder if it would be less confusing if palANIMATE were called palSHIFT? (To give the idea that you need to keep calling it in order to animate).

[MusicallyInspired]

Yeah, palSHIFT is a good idea. Maybe some variables for the shifting direction as well (palSHIFT_FORWARD for 1 and palSHIFT_BACKWARD for -1 or something). I can add those myself, I guess. Actually, now that I know it needs to be triggered every cycle I've got some ideas for oscillating palette shifts...in the right scenario that could be very effective.

Regarding the evVERB stuff, it'd be really nice if we had the debug mode activated for SCI1.1. I wonder, could we take the SQ5 beta, decompile it, and find the the magic scripts to enable debug mode? I'm not sure if debug mode is active in the SQ5 beta, though. I know it is in the SQ4 beta.

[troflip]

I assume you're talking about the debugger built in to the interpreter? That's... in the interpreter, not the scripts. AFAIK it was only in SCI0 games. Doesn't much matter anyway, since ScummVM has a much better debugger.

Or are you talking about the script debugger that lets you see visual, control, pri screens, and properties on the ego, etc...? It should be trivial to grab from somewhere else (doesn't the SCI0 template game have it? I forget). It's possible we could expand on it to make it more functional. It's not clear how it would help with verbs though.

[MusicallyInspired]

Yes the one in the interpreter. I thought that there were magic script files that activates the debug mode in the interpreter...at least for some games. I know it's not in the scripts. Or maybe the script debugger is what they were talking about.