[Ohrrpgce] OHR - Custom Container Slices (Clipping Paths)

Mon Oct 21 18:39:23 PDT 2019

Yes, maybe "Add to stencil" is the least bad... at least it is more
consistent than both a bool and a new type.
If you look at HTML and CSS, any HTML element can do nearly anything with
enough CSS, while we've taken the opposite approach and have different
slice types for different things. The HTML approach (letting any slice act
as a stencil) would be like being able to override each slice method (Draw,
ChildDraw, etc) separately.

For a moment, before I realised that actually I hadn't nailed this down
yet, I was thinking of squeezing it into Fufluns afterall :o

It seems that it's much more efficient to do unnested stencilling than
nested stencilling - what I didn't realise before is that stencilling where
both stencil mask and sprite have an alpha channel can be done very simply
by using a blend function with premultiplied alpha. I thought it required
using a framebuffer (drawing to a temporary texture). But nested blending
definitely will require using a temporary texture. So it would be most
efficient to implement stencilling in two different ways depending on
whether it's a nested stencil or not! That's also true of CPU rendering,
and in fact I already did that, but there are limitations/problems with
framebuffers on mobile GPUs, which has me worried.

On Tue, 22 Oct 2019 at 04:33, James Paige <Bob at hamsterrepublic.com> wrote:

> The "Add slice tree to stencil" bool actually sounds like a pretty cool
> idea.
>
> And yes the GPU rendering complications sound important to consider right
> now.
>
> *Whispers* "fufluuuuuns!" ;)
>
>
> On Mon, Oct 21, 2019, 11:17 AM Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>> If we made the decision based on what would be most natural to implement,
>> it's very clear that a new slice type, not a 'Stencil' setting on all
>> slices, is the cleanest solution, since it would just have a different
>> ChildDraw method, like Panel and Grid. (Well... if we ignore the fact that
>> adding a new slice type actually means far more code because of all the
>> boilerplate and places to update.) And having both a multistencil type and
>> a stencil bool is the ugliest, the worst of all worlds. However code
>> simplicity isn't the most important thing.
>>
>> A big problem with dropping the Stencil bool I already implemented in
>> favour of just a Stencil type is that having a separate slice type wouldn't
>> allow using protected slices as stencils, since you can't reparent them to
>> a Stencil slice. (While we should allow some restricted form of reparenting
>> anyway, but that still mightn't be practical in some cases due to breaking
>> built-in positioning. And that might not happen for a while.) I'd really
>> like the ability to use map layers as stencils, but that would become
>> impossible, but textbox text and walkabout sprites are also worth
>> mentioning.
>>
>> Another option from the few I mentioned would be, instead of having a
>> separate slice type for cumulative stencils, to add a second bool which
>> only appears on children of a slice set to act as stencil: "Add to parent
>> stencil". Except, it would also add all the descendents of that slice to
>> the stencil mask too. "Add slice tree to stencil"?
>> (It's relevant that to begin with I plan to disallow nested stencils,
>> although it currently works, due to concern that it complicates efficient
>> implementation if using GPU rendering)
>>
>> I don't really like any of these options.
>>
>>
>> On Sun, 20 Oct 2019 at 02:18, James Paige <Bob at hamsterrepublic.com>
>> wrote:
>>
>>> I rather like the idea of a new slice type. It seems like I would like
>>> to group multistencils that way anyway even if an extra slice wasn't
>>> required. And simpler code seems like a nice bonus
>>>
>>> On Fri, Oct 18, 2019, 11:19 PM Ralph Versteegen <teeemcee at gmail.com>
>>> wrote:
>>>
>>>> So I have reimplemented stencil slices so that any kind of visible
>>>> slice (excluding Grid, Panel, etc) can act as a stencil, eg text slices.
>>>> This is way better than just using sprites as stencils. Each slice has a
>>>> "Stencil: yes/no" setting. But I want it to be even more general: a whole
>>>> slice tree should be usable as a stencil, not just a single slice. For
>>>> example if you want to draw an NPC in silhouette, and it might be composed
>>>> of multiple sprites for bits of clothing it's wearing. Or use a whole lot
>>>> of ellipse, rect or line slices to make up a stencil.
>>>>
>>>> There are multiple ways to accomplish that which I can't decide between:
>>>> -Add a new Stencil slice type ("Multistencil" to disambiguate?). The
>>>> first X (configurable) children (and their descendents) are the stencil
>>>> mask, the rest are drawn with the mask
>>>> -Also if we have that new slice type, then we could get rid of the
>>>> "Stencil" bool setting on each slice, and require using that slice type
>>>> instead.  This has the advantage that it cleans up the code, but it
>>>> complicates use since you need an extra slice.
>>>> -Let every slice act like a multistencil by adding an additional
>>>> setting "Add children to stencil: 0+"
>>>>
>>>> On Mon, 14 Oct 2019 at 19:13, Ralph Versteegen <teeemcee at gmail.com>
>>>> wrote:
>>>>
>>>>> Well, you got me motivated, so I started on stencil slices. I did
>>>>> underestimate how easy it would be, but have a working mockup.
>>>>> [image: 22_stencil_slice.gif]
>>>>> Two weeks is a pretty short deadline. As I said, this won't be in
>>>>> Fufluns (I won't be committing these changes to SVN until after the Fufluns
>>>>> branch is made, and we don't want to create branches for stable releases
>>>>> long before the actual release, so that the release candidates are just the
>>>>> nightly builds). I also need to rewrite the implementation to allow all
>>>>> slice kinds to be used both as stencil and as children of a stencil: right
>>>>> now it only works for non-transparent sprites parented to a stencil sprite.
>>>>> Even with all the planning I did I still got it wrong! Planning is no
>>>>> substitute for experimentation.
>>>>> But it's already good enough for your purposes, and I really really
>>>>> want to release Fufluns within two weeks anyway, so maybe you can use it
>>>>> afterall, if you haven't already done it manually.
>>>>>
>>>>> Technical details, since I'm CC'ing to the mailing list:
>>>>>
>>>>> I'd also like to allow multiple sprites/slices to be OR'd into a
>>>>> single stencil, but I'm not sure yet how to do that. Possibly the
>>>>> additional stencils would be children of the main stencil, with a "Combine
>>>>> with parent stencil" setting.
>>>>>
>>>>> Also, I will allow transparent stencils (stencils are actually
>>>>> implemented using the alpha layer/mask, so transparency comes for free).
>>>>> I'm implementing stencils in a way that will allow a straight-forward
>>>>> hardware accelerated implementation when we add that, although the initial
>>>>> implementation is with software and could work any way I want.
>>>>> The funny thing is OpenGL has something called "stencils" but they are
>>>>> useless for my purposes since there's no way to set the stencil mask to a
>>>>> bitmap; if you want to draw something in the mask you have to split it into
>>>>> triangles. So I'm forced to instead implement stencils using the alpha
>>>>> layer and a framebuffer (FBO). Also I don't want to use OpenGL directly if
>>>>> I can avoid it, but go through SDL 2 for rendering, since it has separate
>>>>> backends for DirectX9, OpenGL ES 2.0, OpenGL, etc. SDL2 exposes FBOs as
>>>>> render-target textures, and it allows custom blend modes, but it doesn't
>>>>> expose stencils or depth buffers. (Note I don't have real OpenGL
>>>>> experience, just reading a bunch of docs over the years.)
>>>>> OpenGL stencils would not allow transparency (and since OpenGL is just
>>>>> exposing a feature of the render output units (ROP) on GPUs I assume all
>>>>> other graphics APIs have the same limitation).
>>>>>
>>>>> On Sat, 12 Oct 2019 at 03:33, Matt Edson <colesloth at gmail.com> wrote:
>>>>>
>>>>>> Haha, in like two weeks. I'm already going to plan on doing it
>>>>>> manually. No need in escalating anything on my account. I was just seeing
>>>>>> if it was available already or if it was something easy as some of my
>>>>>> requests are, like when James did Shrink to Center, which was amazing.
>>>>>>
>>>>>> On Fri, Oct 11, 2019 at 10:14 AM Ralph Versteegen <teeemcee at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This is something I've wanted to implement for years! I'm sure
>>>>>>> people would find interesting uses of it, such as drawing reflections.
>>>>>>> It's actually not hard to implement, and the reason I haven't was
>>>>>>> because I wasn't sure exactly how to go about it (there are a lot of ways
>>>>>>> it could work) so that it could be feasibly reimplemented when we switch to
>>>>>>> hardware-accelerated rendering, and in particular, when using SDL 2 for
>>>>>>> rendering, which is far more restrictive than using OpenGL/DirectX/etc
>>>>>>> directly. But a couple months ago I spent most of a day reading the SDL 2
>>>>>>> graphics drivers source code, OpenGL docs, etc, to figure this out and
>>>>>>> confirmed that this should be possible to implement in SDL2 by using a
>>>>>>> destination texture alpha channel and custom blend mode. That means I can
>>>>>>> implement it in our current software renderer too.
>>>>>>>
>>>>>>> I'm certainly not going to do this before Fufluns is released, and I
>>>>>>> don't know when exactly I'll get to it, since there are so many different
>>>>>>> things I want to do after Fufluns is released. When would you need it by?
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 11 Oct 2019 at 14:43, Matt Edson <colesloth at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> No worries. I wanted to check before I did anything. Thanks!
>>>>>>>>
>>>>>>>> On Thu, Oct 10, 2019 at 9:40 PM James Paige <
>>>>>>>> Bob at hamsterrepublic.com> wrote:
>>>>>>>>
>>>>>>>>> That would be so cool!
>>>>>>>>>
>>>>>>>>> We don't have a clipping bitmap slice, although that would be a
>>>>>>>>> fantastic feature which I would love to add someday in the future. I have
>>>>>>>>> no idea how difficult it would be to implement, so I couldn't guess how
>>>>>>>>> long it will take.
>>>>>>>>>
>>>>>>>>> For now, you best bet is to just animate it as a bunch of sprites
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Oct 10, 2019 at 5:23 PM Matt Edson <colesloth at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hey guys...
>>>>>>>>>>
>>>>>>>>>> So I'm getting ready to move on to the next area for Axe Cop and
>>>>>>>>>> I do fancy intros for all of the levels. I had this idea today where I
>>>>>>>>>> could do a clipping mask of the word WATER in a font that I figure out and
>>>>>>>>>> I was kind of hoping to make a clipping mask of it and then I was going to
>>>>>>>>>> ascend a graphic of running water through it so it would look like the word
>>>>>>>>>> Water was filling up with water to fill it up and it'd look really cool.
>>>>>>>>>>
>>>>>>>>>> I opened the container area of the slice editor and it seems I
>>>>>>>>>> can only do rectangles. Is there any way to do this idea/and/or is there an
>>>>>>>>>> easy way to implement custom containers for this type of thing or is it one
>>>>>>>>>> of those things I should just brainstorm a new idea for the title card of
>>>>>>>>>> the level?
>>>>>>>>>>
>>>>>>>>>> This idea worked well just because the stage is about raising and
>>>>>>>>>> lowering the levels of water. I could draw all of the frames manually but I
>>>>>>>>>> try to be the most economic with my resources and that'd be a ton of new
>>>>>>>>>> giant sprites.
>>>>>>>>>>
>>>>>>>>>> Let me know! Thanks dudes!
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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/20191022/fff86eb4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 22_stencil_slice.gif
Type: image/gif
Size: 265521 bytes
Desc: not available
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20191022/fff86eb4/attachment-0001.gif>