Author Topic: View instance Prop instance and limitations  (Read 849 times)

0 Members and 1 Guest are viewing this topic.

Offline robbo007

View instance Prop instance and limitations
« on: September 12, 2023, 09:49:14 AM »
Hi,

Just wondering if someone could shed some light on why when I define an instance of prop/view I get white control area appearing from that view. (see screenshot 1).  The palm tree displays a white line along the bottom. The Zodiacs display the rectangle box.

In order for these control lines/areas to not appear I need to use the signal ignAct/16384 syntax in the properties of the view or prop. Is this normal? Is this the best way to combat the white control lines/areas that appear? I then have to create the desired control lines in the picture as to not have ego walk through the view. Seems I lose the "natural" view control lines when doing this.

Code: [Select]
(instance aZodiac of View
(properties
view vRoom
loop lZodiac
x 215
y 164
priority 7
signal ignAct ;16384
)
)


Also what limitations does a view have? I've long views which seems to get corrupted on screen when they pass a certain length. IE they won't be displayed properly in game. They display fine when you click on the view icon in the picture edit screen. These are all views I have created in Aseprite and then imported into SC.

Is there a list showing all the limitations of pictures and other resources also? So I can understand what the limit is. I've run into picture limits when importing from Aseprite and I normally cut things up and turn some into view to get around this limit. But it would be good to know everything else.

Thanks,

« Last Edit: September 12, 2023, 09:52:05 AM by robbo007 »



Offline Kawa

Re: View instance Prop instance and limitations
« Reply #1 on: September 12, 2023, 10:31:48 AM »
The thin line for the palm tree would be its base rect, which extends all the way from the bottom left of its cel to the bottom right. The thickness is determined by the object's yStep. Whenever a View is initialized or positioned, it calls the BaseSetter kernel, and that's what sets the View's brTop et al properties.

Now, Views always use the BaseSetter kernel, but Actors have a baseSetter property -- if you attach a Code object to that, it'll call doit on that Code, passing a reference to itself, so you can make the palm tree use a smaller base rectangle. Of course, to use an Actor for a non-animated element like a palm tree might be overkill so perhaps providing your own init might work better. First call (super init:), then set your own base rect right after. That might work well enough.

The ignrAct status bit ($4000) has these effects, among others:
1. When using addToPic, any view not ignoring other actors has its base rect rendered into the control map.
2. CantBeHere will, as the names suggest, skip checking other actors' base rects when determining if a View with ignrAct set can be there or not.
So its relevance here seems a bit off.

Why the Zodiac appears like that, I dunno.

As for view resource limitations, there's the general resource size limit. I'm not sure how well dither patterns RLE compress -- it depends on whether they're by pixel or by color, so that's a consideration and a half.


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.022 seconds with 23 queries.