The Development of CEGUI 0.7.x

[gring]

Wow, fast work Eddie,

That solution opens up for alot of posibilities.

/G

[Jamarr]

That is superb I hope utilizing such behavior will be kept simple and/or clean like most of CEGUI

[CrazyEddie]

I hope utilizing such behavior will be kept simple and/or clean...

By default it will use a system similar to what I posted somewhere above in which the strings contain certain control constructs that can be parsed and used to build the more complex string structures. So for instance, to put the editbox and button widgets under the control of the string, you might use a text something like this:

Code: Select all

"set widget positions [window="editbox_name"] so that they appear [window="button_name"] embedded in the text!!"

Implementing a default parser for this is one of the next items that I have to work on.

CE.

[CrazyEddie]

I committed some of the code for the string rendering to svn yesterday; it's not in a form that's usable via the normal APIs yet, and there's a few things to sort out such as the bidirectional text support, and also the justified formatting mentioned above. Hopefully I'll make some more progress on that soon.

As a slight interlude to my text / string rendering shenanigans - and in response to a forum thread that mentioned shaders, I thought I'd do a couple of proof of concepts.

Here's a video showing a wave effect applied to a window (it's the Wobble fragment shader from the Orange Book - the geometry remains the simple two triangle quad).


And here's one I did today that is (quite a bit) more complex, it required addition of support for multiple rendering passes (which I'll commit next week). As mentioned in the other thread, I think it's fairly easy to make out the effect in the video - apologies if not, my 'big' version looks quite cool though


There have been a few issues that come up when doing these tests, so that's good - I'll need to look into these issues some time before we can get 0.7.0 released.

CE.

[earthsruler]

Really cool tech. I'm starting to get the feeling that porting my code to 0.7.x is going to be a lot more involved than i initially thought:S.

Great job dude!

[CrazyEddie]

Thanks I'm sure you'll be happy to hear that porting to 0.7.x should be relatively painless; currently most code just needs to be updated to create Renderer object in a different manner (via a 'create' static member function, rather than directly). There's a few other considerations, but nothing particularly huge (see: http://www.cegui.org.uk/wiki/index.php/ ... _for_0.7.0).

Not much to report as regards to progress at the moment; had a funny week last week, so did not get anything done on CEGUI at all, this coming week is likely to be hit and miss also, though hopefully some progress on the last bits of the string rendering can be made towards next weekend

CE.

[Cypherjb]

Thanks for the continued dedication to the project CE, the changes look quite cool.

[IgnisInCaelum]

Ahhhh, you're awesome, man. These RenderTargets are the stuff of the FUTURE! Well, mine, at least. I've been looking for some sane way to have GUIs on objects in-game, (which sounds happily like "the ability to have different GUIs in different viewports, or maybe targetting textures to have GUIs appearing on items 'in game'. ," which is on the All About RenderTargets wiki page) and you've provided! Praise to the wise and 1337 CrazyEddie!

Edit: Oh, and these nifty effects are sweet, too. Heheh, I've just been quite frustrated at trying to get these working before making them look nice... The libs that seemed like they'd help most were all Windows-only. Is it really that hard to keep from excluding an OS?

[CrazyEddie]

Is it really that hard to keep from excluding an OS?

I think there is no excuse at all for this, especially these days (unless of course you're getting some form of 'incentive' out of Redmond, Ka'ching! ).

[jacmoe]

I am *so* looking forward to this release!
Cheers CE!

[dredogol]

Hey there Eddie, great work so far on v0.7.
I have several questions for you:

1) When do you think v0.7 will be released?

2) During the Resize video, I noticed the buttons / editbox areas grew/shrank in size. Is there a way to LOCK those widget sizes, rather than have them resize based on the main window size? That would be useful...

3) During the Layer video after you changed the alpha values, I noticed those alpha values were static. Is there a way you could implement a method, so that when a user selects the CURRENT window, all other windows would have a lower alpha value? IMHO, that would be a cool feature.

4) During the Layer video, I noticed you always selected the TITLE bar section to select the window. Is there a way to set it so when you select ANY part of that window, it will be selected?

5) Read some posts saying the current v0.6 renders each character as triangles. On the next release, are you changing that so that text will render as one large quad, rather than many tiny triangles?

[CrazyEddie]

Hey there Eddie, great work so far on v0.7.

Hi, and thanks

1) When do you think v0.7 will be released?

This is, unfortunately, an unanswerable question - at least for the moment. The plan is still that I want it released sometime in 2009, though it's looking like it will be later rather than sooner - the only way to get an earlier release now would be to start culling features and skimping in other areas.

2) During the Resize video, I noticed the buttons / editbox areas grew/shrank in size. Is there a way to LOCK those widget sizes, rather than have them resize based on the main window size? That would be useful...

All of our Window coordinates / metrics have both scale and pixel offset components; so yes, this is very easily achieved.

3) During the Layer video after you changed the alpha values, I noticed those alpha values were static. Is there a way you could implement a method, so that when a user selects the CURRENT window, all other windows would have a lower alpha value? IMHO, that would be a cool feature.

The means to have inactive windows kind of fade out more is certainly possible, though it's an application domain type thing so IMO there's no need to add it as a feature to CEGUI itself.

4) During the Layer video, I noticed you always selected the TITLE bar section to select the window. Is there a way to set it so when you select ANY part of that window, it will be selected?

That's just a odd thing that happened - there was no reason that I always clicked the title bar other than the fact I was always moving the windows; it's entirely possible to click anywhere in those windows to select / activate them

5) Read some posts saying the current v0.6 renders each character as triangles. On the next release, are you changing that so that text will render as one large quad, rather than many tiny triangles?

Text glyphs are rendered as two triangles (making a quad), at the lowest levels this is the least amount of work we can do to draw each single entity. For the 0.7.x releases, we are introducing the ability to cache things to texture, thus allowing large performance gains overall - so yes, it is true that where currently a screen of text that consists of perhaps 14000 triangles, this will be reduced to two triangles on every subsequent render when using the caching that will come with 0.7.x.

The key thing about our use of texture caching - as opposed to some of our competitors - is we're not using just for performance gains, and it's not an all or nothing approach either. One additional thing we're using the cached content for is to allow window level rotation (demonstrated in another video), and obviously some of the other effects seen in the videos. Another advantage of our system is that it's 'tunable' by the developer / layout artist so that those areas that gain from caching can use it, while those areas that would suffer (perhaps a window that updates it's content every single frame) can opt not to use the caching. Additionally, where accelerated render to texture is not available (ok, not likely on most hardware in use today), CEGUI will still function without that facility (obviously taking some features away, but basically operating in '0.6.x Mode' - if you like).

I'm glad you're still considering CEGUI over the Ogre based alternatives; it is true that some people find certain areas of CEGUI complex or otherwise not to their liking - but hey, it's impossible to please all the people all the time I had been following your thread on the Ogre forum - I found much of it quite amusing; I did not post there as personally I think that having the creator of a system comment in such comparison / Vs threads is quite bad form - it's best to get opinions from others who have used the things for actual projects (though I might sometimes post in such threads to correct blatant misinformation).

Hope the answers help

CE.

[dredogol]

All of our Window coordinates / metrics have both scale and pixel offset components; so yes, this is very easily achieved.

Could you elaborate on that a little more? This is something I've been wondering about for a while, but have no idea how to do it.

I'm glad you're still considering CEGUI over the Ogre based alternatives

Hehe, thanks. Yeah, after using it for 10-weeks, I kinda got used to it. MyGUI is very similar to CEGUI, in terms of file types and coding convention, but CEGUI is more mature and more logical in flow, IMHO.

I had been following your thread on the Ogre forum - I found much of it quite amusing

Haha, well I'm glad you thought so.
I was thinking about QuickGUI, but then I realized editing the imageset is more cumbersome than CEGUI, and the thought of no XML tags was tempting... but having those tags actually help me understand (in a more abstract way) what everything is.
Then again, it could be because I'm used to those XML tags now (not so foreign to me now).

[CrazyEddie]

All of our Window coordinates / metrics have both scale and pixel offset components; so yes, this is very easily achieved.

Could you elaborate on that a little more? This is something I've been wondering about for a while, but have no idea how to do it.

Please always remember to read the docs and the tutorials. This tutorial page details the main points regarding the unified co-ord system: http://www.cegui.org.uk/wiki/index.php/ ... zes_System and the system is also discussed in the Falagard manual - the appropriate part of which is here: http://www.cegui.org.uk/FalDocs/node5.html

Basically, to overview, the lowest-level part of this system is the UDim, and in code it looks like this:

Code: Select all

CEGUI::UDim(float scale, float offset)

Here, the 'scale' is the relative part of the dimension, and 'offset' is the absolute, or pixel part of the dimension. Basically, to get pixel-only positions and sizes, you just use the 'offset' and set the 'scale' to 0. So for a size or position of 100 pixels a UDim definition would be:

Code: Select all

CEGUI::UDim myCoord( 0.0f, 100.0f );

Beyond the simple UDim there is the UVector2 which is comprised of two UDims and is used for two dimensional positions and sizes, and a URect which defines a rectangular area (these types are described in more detail in the tutorial / docs.

HTH

CE.

[Shareth]

This is, unfortunately, an unanswerable question - at least for the moment. The plan is still that I want it released sometime in 2009, though it's looking like it will be later rather than sooner - the only way to get an earlier release now would be to start culling features and skimping in other areas.

Why don't just release 0.7 with base functionality and then upgrade from there? This way it'll get way more testing and a lot more bugs will be fixed. Also might highlight some design/implementation problems earlier.

I for myself would jump on 0.7 even without all the fancy shader stuff and such as it will improve our rendering speed considerably (it should at least).