Dialog Box Edges Hiding Objects Behind

[NilG]

Just going to go for broke and ask this one, slight as it is, since I notice it every time I play through and forays into the two windows scripts haven't made me any smarter.

I've noticed when dialog windows open, they seem to hide objects a few pixels to either side of them.  The attached is an example.

I'm a shitty artist and trying to work around this by creating most background objects as separate views placed onto the scene.  It ain't pretty, but it's prettier than my attempts at vector-based art.

This really isn't a big deal and doesn't affect play at all, I just notice that background objects like the bookcase in the attached get hidden around the left/right sides of each dialog window (showing the yellow wall instead in this case) and was wondering if there's a modification that can be made to prevent this while maintaining pretty much everything else as is about the dialog box?

[Kawa]

So yeah, Views get clipped when a Window appears in front of them. That can't be helped. But what you really want to do is add the views that make up the background detail to the picture: http://scicompanion.com/Documentation/Kernels/AddToPic.html

Edit: It does say there to use View::addToPic instead, so as a practical example, here's how to do it without defining an entire View object for every other part you want to AddToPic:

Code: [Select]

((View new:) view: 60 ignoreActors: loop: 4 cel: 0 posn: 72 52 setPri: 1 addToPic:)That's the Sierra logo in the LSL2 copy protection screen but you do you. I don't think ignoreActors is required when you're gonna addToPic it anyway but eh.

[NilG]

Nice, thanks, addToPic: does seem to do the trick and save a bit on memory to boot.

Some of the backgrounds objects I'd like to add I initially defined as actors so that they could have cycling animations occurring.  I see that I can pull the same trick with Act new: and addToPic, but it doesn't seem that using setMotion in that call

Code: [Select]

((Act new:) view: 532 loop: 2 cel: 0 posn: 83 85 setPri: 1 addToPic: setMotion: Fwd)
works to provide movement.  I'm taking a look at the Animate kernel call, not sure if that could be helpful?  I haven't done any direct work with cast or gCast, though, and haven't figured out yet how it works, if it's even the right thing to look into.  Would this be the right direction to experiment in, or am I going about it all wrong?  I feel like it's probably possible, although it could just be wishful thinking.

[NilG]

Follow up, I also tried this on a second room that had very limited memory just to see if memory usage was really positively affected.  What I found in this case is that the room has just a bit less memory after committing about a dozen view using addToPic: and that it looks like the heap space is way more fragmented than it was before (attached).

Would this be expected using addToPic?  Just about everything should be disposing between each change of the room, and this fragmentation occurs even if I just alt-T directly to the room from the opening, so there shouldn't be junk carrying over.  There were previously only two listings until addToPic was implemented all around.  Is it a matter of ordering things better, or is this just a thing that happens?

[troflip]

The fragmentation might make sense, since you're adding a bunch of View's, then deleting them and replacing them with PV's (the class which holds information on a view that was added to the background), which consume slightly less memory. That space should be freed when you exit the room and  the PV's are disposed?

As for the setMotion thing, if you're calling addToPic:, your Act is destroyed on the next Animate cycle and replaced with a PV. I mean, the whole point of adding things to the background is that they're static. So that means no cycling, no motion, and no scripts on them.

[NilG]

That makes sense, then, I didn't realize the Views were added then replaced.  If the PVs utilize less room, do they still end up in the space in memory where the Views were before?  My limited understanding is that heap doesn't get any defragging, so do the deleted Views just leave holes which can be utilized by smaller chunks, if any arise?  I'm not very memory knowledgeable, aside from the bits I've read here, and there may be more for me to read and experiment with to better understand.

As for the animated background objects, makes sense too.  I wasn't sure after reading through the Animate kernel call if it applied to objects added to the pic (and also didn't realize that the Views and Acts were replaced by a different object class).  I can certainly deal with any clipping around text that has to result from background objects anyway, just figured I'd ask.

[troflip]

That makes sense, then, I didn't realize the Views were added then replaced.  If the PVs utilize less room, do they still end up in the space in memory where the Views were before?  My limited understanding is that heap doesn't get any defragging, so do the deleted Views just leave holes which can be utilized by smaller chunks, if any arise?

If they're smaller and the PVs are allocated before the View's are disposed (but it doesn't look like they are), then they could end up in those holes.

You might just be able to create PVs directly... what happens if you just set properties on a new PV and call init on it? (PV:init adds itself to gAddToPics).

Btw, the whole reason these PVs exist (i.e. a representation of the addtopic'd view in heap memory) is so that they are re-added to the background automatically when you load a save game.

As for the animated background objects, makes sense too.  I wasn't sure after reading through the Animate kernel call if it applied to objects added to the pic

Animate does its job partially by calling the doit: method on Props and Act's, which then increment their animation cel/move themselves as necessary.

[NilG]

It seems like adding and initing a PV directly doesn't do anything; no compiler errors or anything, the object just isn't appear.  Strange, I think, but I could just be missing something.

Out of curiosity, what do you mean when you say that PVs exist for automatic re-addition to the background on restore?  I don't know much about the save/restore process, but without this object type specifically, things wouldn't show up?

[Kawa]

Indeed they wouldn't.

The game is restored, and the picture is redrawn. That is, the original picture from the PIC resource. That doesn't contain anything you baked into it with AddToPic. The PV objects serve to let the restore process re-bake them.

[lskovlun]

The PV objects serve to let the restore process re-bake them.

Given that heap consumption is so carefully tallied and optimized in the standard library (and in the games), it's surprising that they didn't design a more efficient way of doing this (put the list in hunk memory, for example, and have some way of enumerating the items).

[Kawa]

They did eventually do so. It's called "use bitmaps for backgrounds".

[lskovlun]

They did eventually do so. It's called "use bitmaps for backgrounds".

But I like vector backgrounds! (of course, I liked the undithering algorithm too)

[Kawa]

1) You can still use vectors in SCI1 and later, in 256 colors no less.
2) You'll excuse my French but fuck the very concept of undithering.

[Collector]

Gotta agree about the undithering. There is a difference in the perceived colors of a dithered image and the actual colors generated from "undithering". The human brain is a big factor in the perception of color as the mere averaging of temperature of colors. Undithering is taking artistic license with the artists intent. It may be close, but no cigar.

[MusicallyInspired]

Yeah. I love the idea of the technology and accomplishing it was really cool. But I don't care for the resulting effect at all. Still, some people like it and that's cool too.

You know what would be really neat is making some kind of algorithm that converts dithered EGA into 256-colour VGA complete with Deluxe Paint-style gradient shading. I can't imagine you'd get much success starting out, but the concept combined with some sort of AI neural-net processing (similar to all the ESRGAN upscales going around right now for old game images and textures) I think has the potential to produce something pretty neat eventually and I'm so sorry I'm really derailing this thread. Moving on.