Community
SCI Programming => SCI Syntax Help => Topic started by: MusicallyInspired on June 19, 2015, 02:49:01 AM
-
I'm trying to get screen transitions right. In the SQ5 code it looks like all that's done is to add
(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:
(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())
)
-
What happens if you just set the style directly on self? (i.e. maybe gRoom isn't set to the new room yet?).
-
Just like:
(self:style(dpOPEN_SCROLL_LEFT))?
That doesn't do anything either.
-
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?
-
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...
-
Finally went back at this. I fixed it by sending to the gRoom global and then moving the superclass init call after the states.
-
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
(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?
-
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?
-
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.
-
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.
-
It could be due to the SCI1.1 template game version not being properly identified by ScummVM.
In sci.sh (for both template games):
(define dpOPEN_EDGECENTER 6) // open from edges to center
(define dpOPEN_CENTEREDGE 7) // open from center to edges
In ScummVM:
SCI_TRANSITIONS_DIAGONALROLL_FROMCENTER = 6,
SCI_TRANSITIONS_DIAGONALROLL_TOCENTER = 7,
But then also:
// 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".
-
I suppose this is a consequence of using the LSL6 interpreter, yes? ScummVM still detects all Template games as SQ5.
-
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).
-
Yeah, all as SQ5. All from at least the latest Template game, anyway. Interesting that it doesn't change the behaviour.