Hi Guys,
a little stuck on what direction I should be taking here...
Just say I have a large rectangular object as a parent at co-ordinates (100,100).
Then I have a child square object at local co-ordinates (10, 10) so that it is 10 pixels in and 10 pixels down from the top relative to the parent.
That part is easy enough.
But if I want to move the child object slightly out of the boundary of the parent, I would like the display surrounding the parent to clip the child, ie:
Is this something I would do through a viewport? Or something to do with orxGRAPHIC_KU32_MASK_TYPE? I'm not 100% sure what my approach should be.
Comments
If I were to do something like this, I'd update the origin, pivot and size of the child's graphic to match your needs.
If you look at Mushroom Stew, that's how I get the health icons for all the enemies displayed with the current remaining health ratio in the method MushroomStew::UpdateEnemyIcon().
There are less intrusive ways (like intercepting the object's rendering event and doing your own rendering), but I think this method is by far the easiest one.
The aim is to make a scrolling display that gets cut off outside the border. If I fiddle with Z-order in relation to other objects in the region, it should give satisfactory results.
If not I'll check into the pivot and origin settings. I'll see how I go. Thanks again!
The origin/pivot/size trick ipcan be very helpful if you need things such as textured progress bars.
There's also an easy non-intrusive solution based on a custom shader: you can attach a shader to your child objects (in config or in code), then this shader will only allow pixels inside your parent region to be written (if your region doesn't have fixed coordinates you can send them as shader parameters via the shader param event).
That solution requires attaching a shader to your objects (1 line of config) and to write the shader (1 if/else in shader code, written in config file) but the drawback is that it'll not work on very old hardware.
Each of those eight "bays" have 4 doors which start closed and then slide open to reveal those little orbs within.
I guess it would probably be possible to do this with creative Z-ordering, but I don't want to give my artist the extra work to have to figure out slicing the graphics the correct way.
I think updating the doors' graphic origin and pivot could also do this.
iarwain, do you think the shader trick would work here? And, if so, is it trivial enough to post an example?
Thanks!
Actually, there's another option that would also work without forcing you to fiddle with shaders, as long as you want to limit the drawing to an axis-aligned rectangle surface: calling orxDisplay_SetBitmapClipping() on the screen bitmap with the appropriate coordinates.
You could intercept the orxRENDER_EVENT_OBJECT_START of your gate, set the screen clipping to prevent drawing outside and on the orxRENDER_EVENT_STOP restore the clipping to the full viewport dimension.
For the shader, you'd simply need to send your rectangle coordinates as shader parameters and do a simple test on the fragment coord (gl_Position) and verify it's in the rectangle. If it's not, simply output a pixel with 0 for alpha. Something like:
But again, the best solution, especially for freeform masks, would be to make use of the depth coordinate.
The Z-ordering is a very attractive solution! However, the slightest change in object positioning would require changes in the artwork, so I think it makes sense to solve it in code.
I see there are quite a few potential solutions, so I'll report back with whatever I do.
For example, I'm not sure why Z-ordering would require any artwork changes instead of some config changes only, but I don't know all the details in your current screen organization.
So, to do that with Z-ordering, I think I would have to cut transparency out of the background. Then I'd have to play tricks with the Z-ordering of each of the different groups so the little door pieces don't become visible in the adjacent group when they retract.
And it's certainly possible the requirements will change, e.g. I may be asked to use a Position FX to make the groups move at runtime! And different screen sizes (Android, tablets) may require a bit of different positioning to distribute the groups evenly on the screen.
Catching orxRENDER_EVENT_OBJECT_START and using orxDisplay_SetBitmapClipping there works well and is very easy! It also won't break if the requirements change in the ways I am predicting. Thanks again for that suggestion.
Otherwise I'd have the whole background with holes and rendered with alpha blending.
Ah, well. Happy that the SetBitmapClipping trick works nicely for you.
I'd personally go for a compositing approach, using one of the texture as a mask (like a manually handled stencil buffer if you will), this has the advantage to be supported on all the platforms supported by orx and not require any custom written rendering. But it's more a matter of taste I think.