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

[Ralph Versteegen]

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?

>
>>
>> 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
>