Layout once, use at all resolutions - simple idea

oiking

09-06-2009 12:40:31

A lot of people using GUI have the problem to scale their GUI at different screen sizes. Some need their widgets to remain the same size but layout properly on screen so you have more "work area". Other people just need one layout where everything stays relative to the initial layout size (widget sizes, font sizes, line widths etc...).
I'm currently stumbling upon the second alternative. We're having a layout in 4:3 ratio and need it to work at 4:3, 16:9 and 16:10 resolutions (cropping left and right borders on these). The simplest solution that came into our mind was to modify the projection matrix so that the MyGUI renderer will render on the whole screen without knowing about different screen sizes - it will always assume it's (lets say) 800x600 and we're externally modifying the projection so it's always fitting the whole screen.
I've already looked into the source code and stopped at MyGUI_RenderItem.cpp:110 where the render matrices are reset to identity. My idea is to directly integrate this as a feature into MyGUI, but i can't quite follow the "flow" of the MyGUI code yet - Should I add the "transform modifying matrix" as a member to MyGUI::GUI and or to MyGUI::LayerManager? LayerManager seems to be responsible for rendering (inheriting RenderQueueListener) but at least the matrix has to propagte through to MyGUI::RenderItem::initRenderState. I think the easiest way to do this is to add the matrix reference as a parameter to the render(bool update) methods of MyGUI::LayerKeeper, MyGUI::LayerItemKeeper and finally MyGUI::RenderItem.
This feature is to us (at this time) not a so important one, so I'm asking for better design ideas here before implementing it.

Altren

09-06-2009 14:11:41

Actually it's already implemented in trunk. All that you need is render your widgedts into one texture and resize widget with this texture. You can try compiling TestApp from trunk and see what you can do with this texture ;)

oiking

09-06-2009 14:45:22

Hehe, that screenshot looks actuall cool - but I'm trying not to waste additional resources when I could do it in an easier way (changing the matrices doesn't event introduce any more computational overhead - if you don't regard the rasterizer). And I'm afraid of texture filtering artifacts with the canvas method. I'll try implement the matrix thing and post my results when it's done.

Altren

10-06-2009 08:07:29

Actually you won't waste resources, look at fps, it is debug build and fps is same as if no effect was applied to window. All that happens here is render window to texture (actually most GUI's do it by default) and some tessellation. In your case you don't need tessellation, just two triangles per widget.

oiking

10-06-2009 08:29:59

Hm okay, I'll give it a try then :-) Really doesn't matter anyway when MyGUI already renders into textures for speedup, you're right.