[Ohrrpgce] SVN: teeemcee/11102 Transparent rect slices

Ralph Versteegen teeemcee at gmail.com
Sat Apr 6 15:46:09 PDT 2019


On Sun, 7 Apr 2019 at 10:44, Ralph Versteegen <teeemcee at gmail.com> wrote:

>
> On Sun, 7 Apr 2019 at 06:30, James Paige <Bob at hamsterrepublic.com> wrote:
>
>> Oh... my...goodness!
>>
>> These are really beautiful!
>>
>> I would love to start using these instead of fuzzyrect almost everywhere
>>
>
> Yes, in general it would look better to use trans instead of fuzzy rects :
> )
> Do beware that computing the lookup table with 256 nearcolor is currently
> quite slow, but I'm going to optimise that using the k-d tree
> implementation in lib/gif.h.
>
> I feel like the default transparency setting (solid, fuzzy or transparent)
> could be defined as part of the box style. Textboxes could still override
> it, but have "default" as a "Translucent" setting. Replacing the current
> yes/no "Translucent" setting is my next task.
>

Or maybe I could just skip that for now and add transparency type as a
boxstyle setting instead...


> In future, I also want to allow more box style settings, like transparency
> %/fuzz factor, background gradients, and even background textures (a drawn
> image, similar to box borders). So it makes sense to put these settings in
> the box styles menu. And to allow more than 15 styles.
>
> BTW, recall the Ctrl+3 debug key in the slice editor to switch to 32-bit
> mode, which enables actual-true transparency. I imagine that I'll finish
> 32-bit support this year.
> The only things not supported in 32-bit mode yet are screen fades and
> sprite dissolves (because they use Frame masks).
> The main thing I want to do first is a huge refactor to merge Frame and
> Surface. I do want to have a backend hardware-accelerated Surface type, but
> we need 32-bit image support everywhere, not just in the backends.
>
>
>>
>> I did notice one odd anomaly when I was playing around with them:
>>
>> [image: wander0011.gif]
>>
>> In this case the rectangle is filling its parent container, and the
>> parent container is set to clip children.
>> The two sprites are children of the rectangle. When the rectangle is
>> switched to transparent, aside from becoming gloriously beautiful, it also
>> inhibits the clipping of the sprites
>>
>
> That had me baffled for a moment, until I actually had a look at the code.
> Because it performs a draw onto a view Frame, that resets the global
> cliprect, which is associated with a particular target Frame.
>
>
>>
>> On Sat, Apr 6, 2019 at 1:16 AM <subversion at hamsterrepublic.com> wrote:
>>
>>> teeemcee
>>> 2019-04-05 22:16:20 -0700 (Fri, 05 Apr 2019)
>>> 23
>>> Transparent rect slices
>>> ---
>>> U   wip/common.bi
>>> U   wip/common.rbas
>>> U   wip/scriptcommands.bas
>>> U   wip/sliceedit.bas
>>> U   wip/whatsnew.txt
>>> _______________________________________________
>>> 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/20190407/3fba2d4b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wander0011.gif
Type: image/gif
Size: 625039 bytes
Desc: not available
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20190407/3fba2d4b/attachment-0001.gif>


More information about the Ohrrpgce mailing list