curved window

[Sachin]

Hi

Is it possible to create a curved window using cegui. i know it can be achieved thru the imageset file by making some portions of the window alpha blended. but the catch in this approach is that the window underneath our (so called) curved window doesn't get mouse messages when we click on the aplha blended portion. So although the window is visually curved but the window underneath it is not receiving the mouse msgs, wherever it is overlapped by the bounding square box of the curved window.

Any bright ideas?

[CrazyEddie]

This is not possible within the current system. Adding this ability would likely require a major rethink of the core system, so is probably not likely to happen any time soon.

[J_A_X]

do you mean curved corners or a curved side of a window?

[Sachin]

I mean the window can be of any shape...like the window may be of circular shape & there may even be holes inside the window.

[J_A_X]

yeah...that's not possible unless you do some major recoding on the GUI part. The WinAPI has skinning options to make your window which ever shape or form you want.

[lindquist]

The thing is that a window area in CEGUI is defined by a rect.
Not a list of vertices defining the shape.

Don't expect this to change!

[Acrion]

Is there any thoughts into creating a region system similar to Windows API HRGN?

It is relatively simple to implement into the core with PointInRgn() in Windows but does anyone know of C++ API to achieve this efficiently under any OS?

[lindquist]

This is not planned at all as focus is currently on the upcoming Falagard skinning system which by the way is going to be extremely cool...

But I'm we could write our own region/point intersection routines that were portable!

[Sachin]

wen is that falagard skin system going to be released?. can u kindly also tell howz it going to be kool...i mean how will it improve the currently existing system?

[CrazyEddie]

The "Falagard" skinning system will debut in the 0.4.0 release, though no release date for this has been discussed.

The reason that "Falagard" is greatly anticipated by some users is because it enables an exremely flexible way of customising the way that widgets are configured and skinned with imagery. Currently, if you want to do anything too different, you have to edit the C++ code or code your own 'look' module, the "Falagard" system enables most areas of the look and feel of a widget to be specified via a XML file.

Example: Something simple like wanting the scrollbar on the left of a listbox instead of the right, to do this pre-falagard would require you to edit C++ code, with falagard you can just specify where you want the scrollbar in the XML (though this example doesn't really even scratch the surface of what's possible).

[gcarlton]

Isn't this fairly easy? If you already have a window with the appropriate alpha'd texture, you just need to decide when the clicks are inside the area.

There may be a virtual function already to do this. Essentially you just need cegui to ask the window "am I clicked". If the click is within the outer bounding box, then cegui can query the window class itself. Then your special derived class can do one of:
1.) Test the position against a circular shape
2.) Test against some polygon
3.) Test against the texture's alpha value

Ok, this is not exactly easy (I'm not even sure if this virtual function currently exists), but it doesn't seem all that hard. Once its done (particuarly if you went with 3), you can go to town with all sorts of strange curvy shapes.

You could even have textures that morphed over time, whatever.

Geoff

[J_A_X]

Have you ever seen the CEGUI coding? You would practically have to remake the whole engine from scratch because of this.

If its that easy, why not do it yourself? Maybe you'll learn a few things...

[CrazyEddie]

Geoff has been using CEGUI for quite a while, has submitted a few patches (some accepted, some rejected ), and made some great suggestions over that time - which is why he has his credit in AUTHORS; so he does indeed have an understanding of the system and its code.

To get back on-topic...
We have a virtual method Window::isHit which can be used for non-standard hit-testing. Using masks for hit-testing is something that's reasonably straighforwards to put in, though my main concern has always been with clipping. While people may initially say not to worry about that, as soon as you have non-rectangular hit-testing people will then start asking why child windows are not clipped to the same 'hit' area, and that opens up a whole other can of worms. Honestly, the system was never really designed with this in mind, and I do think a major re-working of low-level parts would be required to implement the feature properly - and I'd rather not have a feature than have to settle for a quick hack. I'd never say never - just very unlikely (unless someone demonstrates this in a very high quality patch ).

[gcarlton]

Hi,
Thanks, I didn't know that I got a mention. Nice!

That movitates me to try to clean up my version to get a proper rotating-images patch. One of these days I'm going to get sick of merging my tangle of differences each update and just do it. (But not today).

By clipping due you mean child windows rendering where they shouldn't? That does sound like a can of worms! Makes clipping rotated rects look like a walk in the park.

But for a simple circular button or such without that complication, it seems a feasible approach to derive a window and customise isHit().

Geoff

[CrazyEddie]

Yeah, by clipping I mean that if you had a "round" control, any child widgets would still be clipped to the bounding rect, not the masked circular area.