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

Ralph Versteegen teeemcee at gmail.com
Mon Oct 21 08:16:48 PDT 2019


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20191022/65f3102d/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/65f3102d/attachment-0001.gif>


More information about the Ohrrpgce mailing list