SCI1.1 Screen Transitions *again*

[MusicallyInspired]

I'm trying to get screen transitions right. In the SQ5 code it looks like all that's done is to add

Code: [Select]

(send gRoom:style(dpOPEN_SCROLL_LEFT))to the gPreviousRoomNumber switch for each case. But then SQ5 handles changing rooms differently. I'm using the planet Klorox II as a reference (rooms 400 and 410) as those rooms scroll back and forth. They seem to trigger a separate script altogether for handling room inits. After it figures out which room you came from, it sets the picture transition style and then immediately runs a separate script called sRoomInit. Bizarre! What's the point? Anyway, it's not working for me in the template game. Can't get transitions to work at all. Am I missing something? Here's what I have here in one of my room's init methods:

Code: [Select]

    (method (init)
        (super:init())
        (self:setScript(RoomScript))
        (switch (gPreviousRoomNumber)
            (case east
            (send gRoom:
            style(dpOPEN_SCROLL_RIGHT)
)
                (send gEgo:
                    posn(310 (send gEgo:y))
                    loop(1)
                )
            )
        )
        SetUpEgo()
        (send gEgo:init())
    )


[troflip]

What happens if you just set the style directly on self? (i.e. maybe gRoom isn't set to the new room yet?).

[MusicallyInspired]

Just like:

Code: [Select]

(self:style(dpOPEN_SCROLL_LEFT))?

That doesn't do anything either.

[troflip]

Ha, it was just a guess.

Took a quick look at the code. Rm::init is the one that calls drawPic (where the style is used). Looks like the planet klorox code calls super:init again after setting the style in the switch statement. Maybe try that?

[lskovlun]

Ha, it was just a guess.

Took a quick look at the code. Rm::init is the one that calls drawPic (where the style is used). Looks like the planet klorox code calls super:init again after setting the style in the switch statement. Maybe try that?

or set the style property before calling the superclass in the first place...

[MusicallyInspired]

Finally went back at this. I fixed it by sending to the gRoom global and then moving the superclass init call after the states.

[MusicallyInspired]

Ugh...so I'm having problems with this again. I'm trying to get a screen to scroll to a picture below it but not as a room change. I want it to be in the same room at a certain state in the changeState method by just using the DrawPic command to transition to the new screen. The transition code

Code: [Select]

(DrawPic 500 dpOPEN_SCROLL_UP dpNO_CLEAR) has no effect, though, and just immediately draws the picture with no transition. What am I doing wrong...again?

[troflip]

It works for me, but it's extremely fast. Like, the transition is over in a fraction of a second.

I wonder if there's some DOSBox setting that might control this? Maybe the transitions aren't based on gamespeed, but processor speed.  What does it look like in ScummVM?

[MusicallyInspired]

You're right it does work. I thought I tested slowing down the DOSBox cycles but apparently not enough. Had to throw it right down to 3000. The scaling animation I was working on earlier took a long time to complete but the scroll effect was still quite fast. Strange. I don't remember this behaviour when I was testing KQ1VGA scroll effects. Unless it has something to do with drawing the pic directly instead of changing rooms with a transition style. The effect is nice and smooth in ScummVM. I guess it can't transition to a cycle speed rather than processor speed. Sierra games appear behave the same way. I guess my memory was faulty there.

[MusicallyInspired]

Interestingly, I noticed a glitch when running in ScummVM. I set a DrawPic transition to animate from the center to the edge (dpOPEN_CENTEREDGE) which works properly in DOSBox, but in ScummVM it actually does the opposite (dpOPEN_EDGECENTER). Switching them around in the code makes it work properly in ScummVM but obviously opposite in DOSBox. Not sure if I should report that or not, seeing as it's not an official game...can anyone confirm or recreate this? I'm not sure I'm running the latest version of ScummVM either.

[troflip]

It could be due to the SCI1.1 template game version not being properly identified by ScummVM.

In sci.sh (for both template games):

Code: [Select]

(define dpOPEN_EDGECENTER 6)   // open from edges to center
(define dpOPEN_CENTEREDGE 7)   // open from center to edges

In ScummVM:

Code: [Select]

SCI_TRANSITIONS_DIAGONALROLL_FROMCENTER = 6,
SCI_TRANSITIONS_DIAGONALROLL_TOCENTER = 7,

But then also:

Code: [Select]

// This table contains a mapping between oldIDs (prior SCI1LATE) and newIDs
{   6, SCI_TRANSITIONS_DIAGONALROLL_TOCENTER, false },
{   7, SCI_TRANSITIONS_DIAGONALROLL_FROMCENTER, false },

So it sounds like Sierra switched them in "late SCI1".

[MusicallyInspired]

I suppose this is a consequence of using the LSL6 interpreter, yes? ScummVM still detects all Template games as SQ5.

[troflip]

Perhaps. Does it detect all Template games as SQ5?

I tried using both lsl6-cd (the default for the SCI1.1 template game) and sq5 for Scumm Ids. In both cases the transition behavior was the same (the opposite of DOSBox + lsl6 terp).

[MusicallyInspired]

Yeah, all as SQ5. All from at least the latest Template game, anyway. Interesting that it doesn't change the behaviour.