I guess I understand the issue of the in memory footprint of slices. The place I dislike bit fields most is in the plotscripting interface, but that is what it is.<div><br></div><div>I have no *real* reason to complain :)<br><br>On Thursday, January 31, 2019, Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 1 Feb 2019 at 14:19, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>> wrote:<br>
><br>
> > These days, I always try to make the FB and HS interfaces to something the same if possible.<br>
><br>
> This is wise (if possible!)<br>
><br>
> > or even storing horiz and vert settings as bits in a single int<br>
><br>
> I dislike these kind of bits. I know we do it a bunch, but it always bugs me.<br>
<br>
I WISH that Slice.Fill and Slice.FillMode were an array of two bits<br>
instead of the incredibly unwieldy way it works!<br>
I think actually we hardly use bits and masks at all. In a C program<br>
everything would be in bits!<br>
Also, I don't like that Slice is huge (now 256 bytes plus slice data)<br>
partially due to all these 32bit properties that only have 2-3<br>
possible values, and you sometimes have tens of thousands of slices. I<br>
have been considering redefining bool as a byte instead of a int, but<br>
that will probably break something. FB also supports C-style bitfields<br>
(eek!) but you can only store 1 in a bitfield, not -1, so it's not<br>
safe for bools either.<br>
<br>
But admittedly, putting Vert and Horiz settings in the same int would<br>
be very annoying for implementing it in the slice editor, so I won't<br>
do that.<br>
<br>
><br>
> On Thu, Jan 31, 2019 at 7:28 PM Ralph Versteegen <<a href="mailto:teeemcee@gmail.com">teeemcee@gmail.com</a>> wrote:<br>
>><br>
>> The changes I was thinking of making:<br>
>><br>
>> -I was thinking of having a "Clamp left+right" setting (in fact I<br>
>> already implemented it), like the way the showRight and showLeft<br>
>> RelPos options work: they first clamp to one screen edge, then the<br>
>> other, preferring to show either the left or right part of a<br>
>> larger-than-the-screen object. But this is only useful if the slice<br>
>> *isn't* Aligned to an edge, because in that case the Align effectively<br>
>> clamps to one Edge, and Clamp can clamp the other. For example if you<br>
>> have a tooltip at some point on the screen, and you want it to shift<br>
>> to remain on-screen. Seems like that needs Left+Right+Top+Bottom<br>
>> clamping, scripted or not. I had thought that this could just be<br>
>> accomplished by nesting two clamping slices, but actually that doesn't<br>
>> seem to work.<br>
>><br>
>> -Rather than using the alignLeft, alignRight constants, I was thinking<br>
>> of using a different enum, so that the default value is 0, not 1, to<br>
>> simplify the code, or even storing horiz and vert settings as bits in<br>
>> a single int. Hmm, but I definitely want to use the existing align<br>
>> constants in scripts so there's no confusion, if there are only Left,<br>
>> Right and None options. These days, I always try to make the FB and HS<br>
>> interfaces to something the same if possible.<br>
>><br>
>> On Fri, 1 Feb 2019 at 06:57, James Paige <<a href="mailto:Bob@hamsterrepublic.com">Bob@hamsterrepublic.com</a>> wrote:<br>
>> ><br>
>> > I'll resist the temptation until you declare it stable :)<br>
>> ><br>
>> > On Thursday, January 31, 2019, <<a href="mailto:subversion@hamsterrepublic.com">subversion@hamsterrepublic.com</a>> wrote:<br>
>> >><br>
>> >> teeemcee<br>
>> >> 2019-01-31 06:10:48 -0800 (Thu, 31 Jan 2019)<br>
>> >> 244<br>
>> >> Add slice clamping as a privileged sliceedit option and fix compile errors<br>
>> >><br>
>> >> I didn't mean to check in the slice clamping stuff already! There's a chance I<br>
>> >> might change how it works, creating a file format incompatibility if you<br>
>> >> actually use it.<br>
>> >> ---<br>
>> >> U wip/sliceedit.bas<br>
>> >> U wip/slices.bas<br>
>> >> U wip/<a href="http://util.bi" target="_blank">util.bi</a><br>
>> >> ______________________________<wbr>_________________<br>
>> >> Ohrrpgce mailing list<br>
>> >> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
>> >> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > Ohrrpgce mailing list<br>
>> > <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
>> > <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
>> ______________________________<wbr>_________________<br>
>> Ohrrpgce mailing list<br>
>> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
>> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
><br>
> ______________________________<wbr>_________________<br>
> Ohrrpgce mailing list<br>
> <a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
> <a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
______________________________<wbr>_________________<br>
Ohrrpgce mailing list<br>
<a href="mailto:ohrrpgce@lists.motherhamster.org">ohrrpgce@lists.motherhamster.org</a><br>
<a href="http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org" target="_blank">http://lists.motherhamster.<wbr>org/listinfo.cgi/ohrrpgce-<wbr>motherhamster.org</a><br>
</blockquote></div>