Author Topic: SCI0 - Text window vanishing cutouts of Views  (Read 1523 times)

0 Members and 1 Guest are viewing this topic.

Offline Doan Sephim

SCI0 - Text window vanishing cutouts of Views
« 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.


Artificial Intelligence Competition

Offline Collector

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #1 on: September 10, 2021, 08:23:16 PM »
Do you have a view covering the hole?
KQII Remake Pic

Offline Doan Sephim

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #2 on: September 10, 2021, 09:49:29 PM »
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.
« Last Edit: September 10, 2021, 09:56:00 PM by Doan Sephim »
Artificial Intelligence Competition

Offline Collector

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #3 on: September 11, 2021, 12:29:11 AM »
Or the view is not being redrawn after the box is disposed.
KQII Remake Pic

Offline Doan Sephim

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #4 on: September 11, 2021, 10:15:29 AM »
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

Offline gumby

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #5 on: September 11, 2021, 01:02:14 PM »
Yes, I've seen this happen before too.  Not sure how to fix it though.
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline Kawa

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #6 on: September 11, 2021, 01:43:56 PM »
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!
« Last Edit: September 11, 2021, 02:10:56 PM by Kawa »

Offline Doan Sephim

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #7 on: September 11, 2021, 02:08:07 PM »
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.

Offline Kawa

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #8 on: September 11, 2021, 02:14:18 PM »
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.
Quote
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.

Offline Doan Sephim

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #9 on: September 11, 2021, 02:17:00 PM »
Cool! Thanks for the replies and help  :)

Offline doomlazer

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #10 on: September 20, 2021, 02:13:29 PM »
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.
« Last Edit: September 20, 2021, 11:10:20 PM by doomlazer »

Offline MusicallyInspired

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #11 on: September 20, 2021, 02:46:32 PM »
That's an elegant solution!
Brass Lantern Prop Competition

Offline Kawa

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #12 on: September 20, 2021, 06:15:40 PM »
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.

Offline doomlazer

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #13 on: September 20, 2021, 07:13:03 PM »
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?

Offline Kawa

Re: SCI0 - Text window vanishing cutouts of Views
« Reply #14 on: September 20, 2021, 07:53:06 PM »
Why bother downloading the whole game?

Code: [Select]
(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.


SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.173 seconds with 24 queries.