[Ohrrpgce] CoverChildren and Clamping

James Paige Bob at hamsterrepublic.com
Wed Mar 2 04:39:24 PST 2022


On Wed., Mar. 2, 2022, 12:46 a.m. Ralph Versteegen, <teeemcee at gmail.com>
wrote:

> Cover Children is still visible in privileged mode only.
> Yes, refreshing is broken, and even more so if you nest it. E.g. in
> spriteset_resize_menu_rebuild:
>
>   ' FIXME: CoverChildren is a bit broken, just refreshing doesn't properly
> position
>   ' everything, and even have to draw multiple times due to nested
> CoverChildren.
>   DrawSlice root, vpage
>   DrawSlice root, vpage
>
> To fix this I think I need to make a major change to how recursive drawing
> and refreshing slices works. In fact I wrote all that documentation at the
> top of slices.bas in preparation for making that change, and I have more
> notes.
>


Ah, okay


> As for clamping, I couldn't remember why it was a hidden option in the
> commit message I see I wrote:
>
>     I didn't mean to check in the slice clamping stuff already! There's a
> chance I
>     might change how it works, creating a file format incompatibility if
> you
>     actually use it.
>
> I'm guessing that adding options to clamp in both directions at once
> (turning it into a 4-way bit field) was the change I was considering
> making. That would be a nice feature to have. In the case that the child
> slice is wider than its parent, it could be aligned according to either its
> anchor or align setting (I really can't figure out which is preferable!)
>

I could finish up that feature and enable it.
I guess I'd prefer to use anchor to break the tie when smaller than parent.
Falling back to align in the case of a center anchor, and falling back to
top left in case of a fully aligned slice


> Why won't clamping work forkeeping the cursor on the screen? What have you
> got it parented to? I think it ought to be parented to the root battle
> slice, not to a BattleSprtie slice, for example, because it needs to appear
> above everything else, even if there's a large enemy in front of the one
> you're targetting.
>

So the targetting slices are on their own layer, and then each targeting
slice is a container that has its pos and size matched to the BattleSprite
it is targeting. The actual cursor is a child (or grandchild) of that.

I think I'll want to add a special property for slices that will make Clamp
options use ScreenSlice instead of parent


> On Wed, 2 Mar 2022 at 17:35, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> I was considering making use of CoverChildren... except it seems slightly
>> broken.
>>
>> I see that using it can cause the piston of the children to jump on the
>> first visible tick.
>>
>> I can't remember anything about CoverChildren. Looks like it is enabled
>> in the slice editor, but barely used anywhere
>>
>> I was also looking at slice clamping. I see it is set to be hidden as
>> privileged in the slice editor, although as far as I can tell it works
>> well. I was thinking of adding an option to clamp in both directions at
>> once, but not sure if I want to go that route or not.
>>
>> I need to do some magic to make sure that targeting cursor slices stay
>> onscreen, but clamp won't help me with that, since clamping only respects
>> parent not screen
>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20220302/740daf9c/attachment-0001.html>


More information about the Ohrrpgce mailing list