Arggh stencil is a nightmare : I did thousands of tests and didn't succeed into clipping properly these objects. I began to make a clipping function that takes a TriangleArray and two Point2f (topLeft, bottomRight) as arguments and return a clipped TriangleArray (not necessarily the same vertex count). It's not finished yet, but I think it could be useable. I just hope it won't be too slow.

Wow, that'd be great. But wasn't it more logical to take some kind of clip-quad as the clip-definer. Of course it'd be absolutely the same, but I think, it would be more clear to the user. There could be several constructors to define the clip-quad: two points, a point and a normal, etc... Of course one could reuse the clip-quad for each clipping operation.

Arggh stencil is a nightmare : I did thousands of tests and didn't succeed into clipping properly these objects. I began to make a clipping function that takes a TriangleArray and two Point2f (topLeft, bottomRight) as arguments and return a clipped TriangleArray (not necessarily the same vertex count). It's not finished yet, but I think it could be useable. I just hope it won't be too slow.

Wow, that'd be great. But wasn't it more logical to take some kind of clip-quad as the clip-definer. Of course it'd be absolutely the same, but I think, it would be more clear to the user. There could be several constructors to define the clip-quad: two points, a point and a normal, etc... Of course one could reuse the clip-quad for each clipping operation.

It'd be nice to have a callback from the renderer that gave you access to a glOrtho display so you could render simple UI using normal GL commands - this would of course be renderer dependent so a big sign saying "USE AT YOUR OWN RISK" should be applied.

It'd be nice to have a callback from the renderer that gave you access to a glOrtho display so you could render simple UI using normal GL commands - this would of course be renderer dependent so a big sign saying "USE AT YOUR OWN RISK" should be applied.

It would however be amazingly useful and flexible.

Kev

Mmyeah sure but say for our HUDwe don't want to be renderer-dependant and anyway in "glOrtho" you have "gl", what if someone implemented a DirectX renderer ? And aren't displays handled differently by JOGL and LWJGL ? Which means different classes, and run-time type detection (and cast) and alt that stuff. Pheww not easy.

The Border- and Button Widget each have an inner class called ButtonDescription / BorderDescription. They're used to first describe the Button or Border easily and then create a new Button or Border Widget passing this BorderDescription instance to the constructor. This has to be done for the Scrollbar Widget, too. Would you do that, Amos? I don't know, if I have too much time, the next days.

Improved the WidgetTheme to support the new features

Added a class named WidgetZIndexGroup. It can logically group some Widgets to set the last clicked Widget in the group the group-local-maximum-z-index.

Added an easy mechanism to link a Panel and a Scrollbar < scrollbar.link(panel1) >

Added many, many constructors to take Tuple2f intead of (width, height).

Fixed some bugs

Marvin

EDIT: Maybe someone could draw / find a nicer border texture than I used in the HUD3DTest.

Mmyeah sure but say for our HUDwe don't want to be renderer-dependant and anyway in "glOrtho" you have "gl", what if someone implemented a DirectX renderer ? And aren't displays handled differently by JOGL and LWJGL ? Which means different classes, and run-time type detection (and cast) and alt that stuff. Pheww not easy.

No, I don't think it has to be like that. The thing thats passed back could be a OrthoContext on which you can call some small subset of the commands you need to draw 2D images. Then within Xith the context could be handled however the renderer desires. Just seems way more flexible than all this pushing 3D into 2D to me.

But, since I'm not will to contribute the code myself, I'll just shut up now

Mmyeah sure but say for our HUDwe don't want to be renderer-dependant and anyway in "glOrtho" you have "gl", what if someone implemented a DirectX renderer ? And aren't displays handled differently by JOGL and LWJGL ? Which means different classes, and run-time type detection (and cast) and alt that stuff. Pheww not easy.

No, I don't think it has to be like that. The thing thats passed back could be a OrthoContext on which you can call some small subset of the commands you need to draw 2D images. Then within Xith the context could be handled however the renderer desires. Just seems way more flexible than all this pushing 3D into 2D to me.

But, since I'm not will to contribute the code myself, I'll just shut up now

Kev

No please don't shut up it's really interesting. What commands would be needed in OrthoContext (and BTW why not contribute ?)

It'd be more work initially but it would also make Xith very easy to understand when working with GUIs. You could just draw whatever you wanted to over the top of the scene in an accelerated way. Naive implementation would be just to proxy the methods onto a GL context configured for orthographic projection - more complicated might be to cache the calls into arrays and spit them to card in batches.

If someone came along an implemented a DirectX layer you just translate the calls into whatever it needs to be for DirectX - which I seem to remember is pretty similiar at this basic level anyway.

Re: Contribute - I don't use Xith active and I have plenty of other stuff to do at the moment. I'm also not too keen on the style of responses I've seen with respect to contributions recently.

I've just finished adding a Description class to all Widgets that need one. Now the Widget handling should be even simpler. And it helped me a lot in theming.

Additionally we now have a RadioButton Widget and a Checkbox Widget. In org.xith3d.ui.hud.util there is a new class called StateGroup. One should always add RadioButtons to an instance of StateGroup, which manages the activation state of all members such that only one RadioButton in the group can be activated at a time.

I've just finished adding a Description class to all Widgets that need one. Now the Widget handling should be even simpler. And it helped me a lot in theming.

Additionally we now have a RadioButton Widget and a Checkbox Widget. In org.xith3d.ui.hud.util there is a new class called StateGroup. One should always add RadioButtons to an instance of StateGroup, which manages the activation state of all members such that only one RadioButton in the group can be activated at a time.

I just added the new HIAL version (1.4) to xith-tk which adds support for the mouse wheel and the possibility to monitor a "mouse-stopped" event, which is useful for tooltips. This event is fired, when this feature is enabled and the mouse hasn't moved for a certain amount of time. Additionally the pressed and released events get the current mouse x and y position as parameters.

For the new events the listeners needed to be enhanced. This is done in new, separate listeners (postfix "2"), such that the old ones still exist and the whole thing is fully backwards compatible.

This version still has problems with an AWT event bug on Linux which is discussed in this thread.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org