[Ohrrpgce] SVN: teeemcee/7792 Fix Select slices updating child visibility when drawing instead of refr

[Ralph Versteegen]

On 15 March 2016 at 21:52, Ralph Versteegen <teeemcee at gmail.com> wrote:
> On 15 March 2016 at 03:30, James Paige <Bob at hamsterrepublic.com> wrote:
>>
>>
>> On Sat, Mar 12, 2016 at 8:05 PM, <subversion at hamsterrepublic.com> wrote:
>>>
>>> teeemcee
>>> 2016-03-12 20:05:27 -0800 (Sat, 12 Mar 2016)
>>> 1750
>>> Fix Select slices updating child visibility when drawing instead of
>>> refreshing
>>>
>>> This change affects when a script will see up-to-date visibility of select
>>> child slices. You still need to do something to cause the slice to be
>>> refreshed.
>>> This also affects "slice at pixel" and "find colliding slice" called with
>>> visibleonly=true.
>>>
>>> ChildRefresh is now called even on non-visible slices by DrawSlice, but it
>>> takes an additional visibleonly argument to skip refreshing the size and
>>> position in that case. This is both to avoid unneeded processing for
>>> hidden
>>> slices and to exactly match the previous behaviour for non-select slices
>>> (although I really hope noone is relying on the size of hidden slices not
>>> being
>>> updated!)
>>
>>
>> I know I am not worried. All of my invisible-slice-voodoo is using container
>> slices, not selects.
>
> It took me a moment to work out what you mean, but you must mean
> storing data as the width and height of a slice. I actually had not
> thought of that, but it is a very good reason why it wouldn't have
> been safe to start refreshing hidden slices that previously weren't. I
> see the slice system as a whole as highly delicate, where changes are
> likely to break backcompat, unfortunately.
>
>>>
>>> Slices shouldn't modify themselves when drawn, aside from calling
>>> ChildRefresh,
>>> so that we can draw slices more or less than expected without breaking
>>> anything
>>> as long as they're refreshed somehow (e.g. RefreshSliceTreeScreenPos()).
>>> For example, slice velocity is applied in AdvanceSlice, not DrawSlice.
>>> In future this will allow things like frame skpping and drawing slices
>>> multiple
>>> times on small wrapping maps.
>>
>>
>> Will this allow multiple views of the same map? I had some crazy ideas a
>> while back about split screen multiplayer, but gave up on them at the time
>> because I couldn't do that with mapslices.
>
> Yes, that's another possible use! One that I'd really like to enable.
> I haven't thought too deeply about it, but it does seem a tad complex.
> You would have to add a script command to duplicate the whole tree
> from maproot down, and some way to delete it again, and the multiple
> trees all need to be recreated when changing map. A bunch of state,
> like the loaded tilesets and various gmap() stuff would have to be
> applied to all copies of the map tree, which should be easy (whereas
> splitscreen viewing different maps certainly would not be). The
> original/real map root tree would correspond to the camera position,
> so we need some place to store the other camera positions. Would we
> add optional arguments to all of the camera script commands, a map
> root slice handle or other handle, to specify which map tree to act
> on?

Wait, duplicate map layer slices seemed like the simplest way to draw
multiple views on the map, but clearly you can't duplicate all the
NPC/hero slices in the same way, and anyway duplicating map layer
slices already breaks parenting slices to map layers. I totally
forgot, I only remembered that I remembered this somehow being really
hard.

So I take it back, the only sensible thing to do is to draw the same
map root multiple times. I actually also haven't really thought about
how to draw the same slice parented to a map layer multiple times if
the map wraps but it's a very similar problem. I think they should
both be solved with a special draw methods on some of the slices on
the map tree. For example maybe we can add a MapViewSlice with a
ChildDraw method that causes it to draw the children of the MapRoot
slice rather than its own children, but with a different offset. In
fact this sounds general enough to be used for drawing any slice tree
twice, not just the map root. It does make it clear that parallax
would need to be computed inside the slice drawing code, not something
like refresh_map_slice.

>
>>
>>>
>>> Unfortunately other slice types don't entirely obey the pure-draw-function
>>> rule.
>>> Both rect and sprite slices delay loading styles or sprites until the
>>> first
>>> draw, which causes modifications.
>>> Even worse, auto-advancing dissolving sprites advance when being drawn;
>>> which
>>> is definitely the wrong place to do so.
>>> Text slices toggle .insert_tog and recompute .line_count when drawn. The
>>> latter
>>> doesn't directly affect drawing but is related to the bug that the height
>>> of
>>> text slices isn't recomputed when their .line_count changes (e.g. because
>>> their
>>> width changes), because that's only done when ChangeTextSlice is called.
>>
>>
>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>