Community
SCI Programming => SCI Syntax Help => Topic started by: Doan Sephim on September 10, 2021, 01:00:11 PM
-
Does anyone know why this happens? This particular text box reveals a "hidden" area behind a breakable wall.
This isn't a super high priority as I can just move the location of the text box, but this is an issue I don't think I've ever seen anyone talk about before.
-
Do you have a view covering the hole?
-
Do you have a view covering the hole?
I do. But whenever the text is there, it cuts out a square shaped "hole" in the view. I'm guessing the windows dimensions might be being drawn improperly...or at least the clearing for it?
The attached is what it looks like without the text box interference.
-
Or the view is not being redrawn after the box is disposed.
-
I should clarify. Once the text box is gone, the view's pixels are restored. It only when the text window is on screen that the view has a piece cut out
-
Yes, I've seen this happen before too. Not sure how to fix it though.
-
One possible workaround might be to addToPic the wall view over the hole on init (only if it should be covered of course), and redraw the room picture (which has no wall there) when it's revealed.
Edit: it's actually quite surprising how often this happens!
-
One possible workaround might be to addToPic the wall view over the hole on init (only if it should be covered of course), and redraw the room picture (which has no wall there) when it's revealed.
Interesting. I don't have any experience with "addToPic." I'll have to tinker with it to see how it works. Would it work with a crumbling animation? Or would addToPic keep the first cel of the view static on the background?
I have a hard time deciphering a lot of the base template code, so I just wonder if there were some errors in the window printing that was causing this.
-
Would it work with a crumbling animation? Or would addToPic keep the first cel of the view static on the background?
If you redraw the pic first and then play the crumble animation, you should be fine. And yes, addToPic-ing involves the View's current view loop and cel.
I have a hard time deciphering a lot of the base template code, so I just wonder if there were some errors in the window printing that was causing this.
As you can see from my little montage, windows cutting off views is a common issue even in SCI11 and with custom frames. It's not you.
-
Cool! Thanks for the replies and help :)
-
edit: startUpd does nothing for this issue.
Sounds like you have already addressed the problem, but I was seeing this issue with doors in KQIV. I was able to fix it by adding startUpd: on the door views.
-
That's an elegant solution!
-
If it works.
Not all windows are alike -- some are blocking, others are not. We know Ego has their "start update" bit set even when standing still, and they still get cut off by non-blocking windows like "Enter command" and talkers, as I've shown before.
So just to put my money where my mouth is, I took my SCI0 test game, which has a timed, non-blocking response, and stood right at the edge where the window would appear. For one frame, I could catch a gap between Ego and the window, and then Ego updated again, filling the gap. The other test response, an attempt at QFG2-ish talkers, was blocking, as is the prompt, and caused the gap to appear.
I don't know where exactly that startUpd call doomlazer speaks of would go, but I don't see how it could work for regular Print calls that don't #dispose.
-
Good point. I'm not sure how it interacts with ego as all of the issues I've come across are on non-ego views.
Does calling (ego startUpd:) just before the printing the message or adding it to the room's ego init make any difference? I realize you mentioned the ego's update bit should already be set, so probably not.
Is your SCI0 test game available for download?
-
Why bother downloading the whole game?
(Print "Stand at the edge of this message." #font 0 #dispose #time 5)
If it's Ego or other another view shouldn't matter. The point is that they aren't stopUpd:-ed, and thus are redrawn every frame even if "nothing" has changed¹. They stop being redrawn every frame while a blocking window is on screen despite being in their startUpd state, because the cast isn't being redrawn during the inner loop driving the print dialog. The window being drawn knocks off part of any sprites within so many pixels from its sides, and since the cast isn't redrawn until the print's loop ends, the gaps stay on screen². Then we're back in the game's loop, which does redraw the cast.
If you #dispose a Print, that inner loop is skipped entirely. It's not Print that handles closing the window again when those five seconds in my example are over, that's handled elsewhere through a pointer and time limit left behind by Print.
But note that even making the window non-blocking like that does not properly solve the issue this thread started with, since there's a single frame wherein the views underneath do have the gap.
Does calling (ego startUpd:) just before the printing the message or adding it to the room's ego init make any difference? I realize you mentioned the ego's update bit should already be set, so probably not.
Blocking:
Frame 1: draw the cast, run room scripts, catch a said or whatever. (ego startUpd:), no change since it's already in that state. (Print "testing!"), open a window, cut Ego in two, enter dialog processing loop waiting for a key, exit loop, close window, restore underbits.
Frame ...whenever you pressed enter: draw the cast, run room scripts...
With #dispose:
Frame 1: draw the cast, run room scripts, catch a said or whatever. (ego startUpd:), no change since it's already in that state. (Print "testing!" #dispose #timer 5), open a window, cut Ego in two, immediately exit the Print function we done here.
Frame 2: draw the cast, which fixes Ego's back problems. The window's shape is cut into the priority screen so it all works out.
Frame whenever: notice there's a modeless dialog timer that just ran out, close that window, restore its underbits.
¹: On a low detail setting one might stopUpd a waterfall, save some effort.
²: A talker portrait or DCIcon is not part of the cast, they are animated by the talker class and print routine respectively.
-
After reading your post I think you are right, this is a different issue than what I experienced with the doors. It sounds like the hole was filling back in when the text box was dismissed. My doors were never drawn again.
I'm inexperienced with SCI and still learning, so startUpd seemed like a possible solution for this as well.