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

Mon Oct 21 08:33:19 PDT 2019

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