Rotating images

[gcarlton]

I've just used cegui to make up a simple radar, and I've noticed there is no support for rotated images. This would be good to have - both for complex gui elements, and more "gamey" stuff that just happens to use cegui static images, like hud elements or in-game maps.

Also at the end of the day the renderers just throw quads up anyway, so its a feasible change. The main thing is adding a function that requests a draw() with the dest rect having a proper orientation.

Having a look through, the following would need to be changed:
* renderer
* imageset
* image
* staticimage

The scope of it means I haven't launched into it myself (has anybody else added it and kept quiet?).

One solution would be to create a struct for object orientated rects - with functions for getting the absolute (axis aligned) rect bounds, rotating, etc. This would then be passed into the draw() in an overloaded function.

A smaller change would be to add an extra "rotation" float to the draw() functions, that then takes the dest rect and rotates it around its centre by that angle. That may be a better approach, although working out the clipping is still going to be messy.

Anyway, just a thought.

[CrazyEddie]

I agree that it would be very nice to have full rotation support, though as you note it's the clipping which would be the largest issue to overcome (obviously at the mmoment is extremely simple, and therefore fast, because everything is a rectangle and the resulting imagery always comes out as a quad).

So, nobody has done anything of this scale at the moment, although there is a patch on the tracker that contains modifications to perform some very simple flips and 90 degree rotations (there's a whole bunch of other stuff in the same patch, some of which has been integrated and some that has been rejected, so the patches usefulness is reduced due to the way it was submitted). These effects are achieved by modifying the texture co-ords only, and are obviously not on the grand scale of your vision posted above. This current patch might still get included, though I'm reluctant since it means there will be some renderer modules that do not support all the features (which then means the system as a whole is less API/Engine independant).

Anyway, it would be super cool if something like this was available, and implemented so that there were minimal interface changes, and minimal performance impact. The rotation float parameter would be my choice, though there are many things that need to be considered

CE.

[gcarlton]

Ok, I am tempted to add the rotation float in and support it for dx9 only, ignoring the clipping. That should work for my case at least. I guess rotated images wont snap to pixel borders - though I'm not sure if it will "pop" at the 0degree case.

There is also another suggestion I thought of that is tangential to this one. If we have lots of dynamic widgets (rotating, moving, resizing), it will trigger a complete refresh every frame.

Currently the mouse cursor gets away with it with a special case. Another case is dragging items around (e.g. a piece of armour in an inventory).

A low priority optimisation would be to have a "volatile" set of widgets. These wouldn't build into the static quad list, but would instead (like the cursor), be appended at the end.

In actual fact, it would be a bit more complicated than that since we'd need another vertex/index buffer for these volatile ones. Hence, the render would be:
1.) If static refresh: Call draw() on the "static" widgets, filling up the "static" v/i buffer.
2.) Always: Call draw() on the "volatile" widgets, filling up the "volatile" v/i buffer.
3.) Always: Render both buffers.

Obviously not something that has any sort of priority, however it is comforting to think there will be a (moderately) easy solution if we start getting lots of dynamic widgets in the gui systems.

[CrazyEddie]

Yeah, the full redraw thing is really a big issue for many reasons, and is a bit of a performance killer.

It's likely that the renderers will get rewritten around the time the "Falagard" widgets are implemented (much code instability anticipated, when 0.4 is released I'll reccommend that people stick with that until 0.5 is out rather than use CVS HEAD). Knowing that these major changes are coming is is one reason I have been "neglecting" the renderers a bit as far as optimisations go. The same applies to the fact that most of what gets re-calculated for a full-redraw could be cached, because I know what's coming, it all seems like a waste to optimise it

CE.