GUI

[StefanP.MUC]

Yeah, the size needs to be lowered. 25% seems good, I'll change it to this. The current position of the counters isn't the best, I agree. But I like them more in the bottom. If they are on top, then I'D prefer them in a vertical row in eitehr of the top corners. Let's hear what other think about this, it's no problem to move them.

I implemented a (not very good looking ) gold coin to the gold number box.

edit: thinking about it, maybe it's really better to not put everything in one box. At least not a horizontal one. The trend is more to widescreen (and 4:3 is also wider than high), so using a only horizontal menu isn't the best. I try putting the counters on another place on the screen side and reduce the frame hight.

[oln]

A horizontal bar on the top is common in strategy games. I suppose a vertical one could work as well, can't remember having seen any game with a layout like that so i don't know how it would look. Would be even better if it was movable in some way so you could put it where you want it.

[Danimal]

i agree with svend, you should put the mana, gold and territory on the upper left corner, and reduce the gui, it takes too much screen space rigth now.

[StefanP.MUC]

oln, it actually IS movable.

[svenskmand]

A horizontal bar on the top is common in strategy games. I suppose a vertical one could work as well, can't remember having seen any game with a layout like that so i don't know how it would look. Would be even better if it was movable in some way so you could put it where you want it.

Dungeon Keeper? You have played that one.

[oln]

I was refering to having a vertical bar with resources in addition to the horizontal one with the rest at the bottom.
A lot of games use the approach with one vertical bar for everything, or resources at the top and a vertical bar for the rest.

[StefanP.MUC]

I came up to another technical problem. I noticed this while experimenting with Icons in the GUI.
CEGUI doesn't have very indepth scaling and apsect ratio options. The problem with CEGUI is, that it only offers lengths values in the style of "relative to parent + fixed pixel number offset". That's not a bad thing as long as you don't use pixelated style elements like icons that need a fixed aspect ratio. Currently my testing GUI with the gold coin icon looks pretty good on 16:10 (my notebook monitor), but letting it run on 4:3 window mode sets the icons to a squeezed state.

I think we have two (maybe 3) possibilities to handle this issue:

1) Three different schemes: one for 4:3, one for 16:9 and one for 16:10 (these 3 are the most common and should cover >99% of all users). The one to be used has to be figured out before loading one in main() by looking what resolution the user has choosen.

2) Fixed pixel size for affected elements. This means the elemts look the same on all apsect ratios and resolutions (this is the main problem here). This means for example 25 pixel on 640x480 and also 25 pixel on 1280x1024. On one it will be very big compared to the 3D content, on the other very small.

maybe 3) I asked in the official CEGUI forum, if there's a workaround. But there are a lot of older threads (on older CEGUI versions) from others having similar issues. The chances are low that they know a way to address all aspect ratios with only one scheme.

[andrewbuck]

That's and interesting problem. I think your idea of making three layouts and then just choosing the one that most closely matches you aspect ratio would probably be the best way to do it. As you said this will get most monitors and the ones it doesn't get exactly will probably be fairly close to one of the ratios. Unfortunately it means manually making three layouts but if we get all the design stuff worked out first it shouldn't be too hard to make tweaked copies of the finished product.

That also gives us the ability to actually design them slightly different on different aspect ratios. As has already been mentioned, many desktop monitors are fairly tight on vertical space so we may want to move things a bit more to the sides in that layout. Also, some games will offer more than one layout scheme that can be switched in-game, either through a menu or sometimes even by keyboard buttons. For example we could have a secondary display that can be switched to with some button that gives you more control over combat actions, or about how the general creatures strategy should be, etc. It is pretty easy to have CEGUI reload another GUI sheet on the fly, so tying this to a keypress would should be a simple matter.

-Buck

[StefanP.MUC]

Yes, if you have one complete layout, it won't be very much work to copy it and adjust the numbers. I'm already quite good in hacking the layout xml by hand (the CELayoutEditor is crap, full of bugs and messy output like "0.4546456e-9" instead of just "0" for a coordinate and these things). I also collected all the good reference pages of the CEGUI docs (very hard to find...)

I think I'l now focus on the 4:3 layout, this should be good enough for most people for the beginning. If we are lucky I get a good solution on the CEGUI forums. If not, then I'll do also the other aspect ratio layouts.

edit: I just tested out fixed sized icons on my smallest (640x480) and largest (1280x800) possible resolution. It doesn't take to much space on the low resolution and still looks good and not to small on the big resolution. I dont know how it would be at 1920xsomething resolutions. But we could try to use a fixed pixel sized GUI.

I think until these technical questions are clear, I'll look (or try to draw myself) for some useful icons and continue after that with the gui layout.

edit2: Ah, seems that it's possible if we create a new contol in lookandfeel instead of using a text+image combination in layout. Then I have to work myself into the lookandfeel structure.

[charlie]

Perhaps you should investigate alternatives to CEGUI as now would be the time to switch

MyGUI springs to mind:
http://mygui.info/
http://www.ogre3d.org/tikiwiki/MyGUI

[StefanP.MUC]

I had this thought, too. CEGUI is very user unfriendly (bad documentation, no real examples, bad Editors). MyGUI seems a lot cleaner and better. Their documentation seems to be better, but I found also advices like "take the LayoutEditor and press some buttons then youl see what controls there are" - I miss on both, CEGUI and MyGUI, a simple overview of ALL the objects and ALL their properties in a clean and easy to read form. More or less all the things I did until now was "reverse engeneering" CEGUI, because nowhere is told how to write own layouts and styles (only for the extreme basics, anything that goes deeper than a button is not well documented).

edit: just found in the MyGUI forums that MyGUI isn't supporting this aspect ratio thing, too (they even said it's uncommon that someone needs this). So we can stick with CEGUI for the time beeing as we are already worked into it a little and MyGUI doesn't seem to offer more features.

[oln]

I feel a bit this way about Ogre as well, but it's a bit too integrated to switch at this state.
Switching GUI toolkit is still possible if there is a very compelling reason for doing so.

[svenskmand]

I think I'l now focus on the 4:3 layout, this should be good enough for most people for the beginning. If we are lucky I get a good solution on the CEGUI forums. If not, then I'll do also the other aspect ratio layouts.

As most people have 16:9 and 16:10 screens I think we should go for that as one of the first priorities.

edit: I just tested out fixed sized icons on my smallest (640x480) and largest (1280x800) possible resolution. It doesn't take to much space on the low resolution and still looks good and not to small on the big resolution. I dont know how it would be at 1920xsomething resolutions. But we could try to use a fixed pixel sized GUI.

This is a no go, I have a resolution of 1920x1080 on my 46" tv and I need to make all text on my computer bigger to see it, along with window menues. Having to try to read small fonts on a screen kills your eyes and you brain when you try to concentrate on reading and focusing on the text.

Perhaps you should investigate alternatives to CEGUI as now would be the time to switch

MyGUI springs to mind:
http://mygui.info/
http://www.ogre3d.org/tikiwiki/MyGUI

I feel a bit this way about Ogre as well, but it's a bit too integrated to switch at this state.
Switching GUI toolkit is still possible if there is a very compelling reason for doing so.

Be careful we do not end up like George Broussard with Duke Nukem Forever.

[StefanP.MUC]

With 4:3 as a start I had also the windowed mode players in mind. But for me it's the same to start with 16:9 as to start with 4:3. Tomorow I will collect/draw some basic icons (Gold Coin, Mana blob, mouse cursor and maybe modify the example imageset tiles and put together a new imageset)

I also don't think we should switch engines. I don't know about OGRE in detail, but to be honest, it's the only OenSource engine I know that has very high standards (meaning even commercial games use it). And it does seem to give us pretty good graphics. And for CEGUI: it isn't bad, it only the lacks of tutorial, documentation and examples. It seems it is intended for Hardcoding an interface directly in the game sourcecode (there's a lot of details in their wiki) - but not for the xml scripting.

[andrewbuck]

Yes, Cegui does have a pretty decent system overall, but it is still very much a work in progress. For the most part I like the way they do things internally in the code, and I think as the project develops further a lot of our complaints about documentaion, etc will be resolved. Glad to here you are figuring it out thou blablub, I look forward to seeing what you come up with.

-Buck

[charlie]

I thought CEGUI was dead... evidently not (0.7.5 released last Nov).

I only suggest MyGUI because it is stable and actively developed (version 3.2.0rc1 just out) and, from what I know, a bit more flexible than CEGUI. I could be wrong. I know of a few projects that have struggled with CEGUI and had better results with MyGUI - I bet there are opposite cases though.

The MyGUI videos are cool:
http://mygui.info/#ui-tabs-13

Saying that, it appears to be pretty subjective as to what is the best one:
http://www.ogre3d.org/forums/viewtopic.php?f=5&t=58068

[StefanP.MUC]

I did a bit more reading. For what we need for OpenDungeons there should be no difference between CEGUI and MyGUI on the designing part (maybe CEGUI is a bit harder to understand, but both use XML files). They both seem to have the same features (CEGUI has some more not-so-important ones). I don't know about the C++ coding part, but according to Andrew, CEGUI seems not very hard to use.

My vote is to stick with CEGUI.

Then, I tried finding other OS projects using CEGUI. There aren't many, but all I could find did it less fastidious than I have planned for OD. They only took the basic example scheme (mostly not even proper renaming to fit the project names and standards), loaded it in the LayoutEditor and edited it. Doing it by hand gives much cleaner results, so I'll do this.

Last thing I read: I did more researching on the aspect ratio/resolution thing. I found several posts on various forums telling to take a calulator and calculate the aspect ratios for the relative coordinates by hand.

Now about the thing that popped up in my mind to solve this problem without needing to create a layout for each aspect ratio:
We create only one layout, namingly a 4:3 one. And one widescreen resolution it gets not scaled up to 16:9 or 16:10, but also only to 4:3 until the screen height is reached. This should be possible with a good combination of UnifiedMaxSize, UnifiedMinSize, UniFiedAreaRect, UnifiedWidth, UnifiedHeight and UnifiedSize.
But maybe it also needs some C++ Code (I hope not, but if it does need it won't be lot, like one or two lines that do a multiplication with the aspect ratio and assign it to the layout at runtime).
With this we would have a scaling GUI that would take the whole width on 4:3 screens, but on widescreen it would only take a part of the width. But in both cases the full height. With a movable box this should be no problem, since the user still can decide if he want's it left or right, top or bottom.

What do you think of this arrangement (a quickly drawn example is attached)?

4:3 base GUI

43.jpg (21.74 KiB) Viewed 15761 times

And with Widescreen adjustment

[StefanP.MUC]

I tried again with fixed pixel. CEGUI imagesets have a autoscale=true/false switch and a native resolution. I read it should be the magical switch that solves our problem. But switching it does nothing that I could see....

But using absolute pixel values I get extremly good outputs, for both 640x480 and 1280x800. I'll now design the GUI for a native resolution of 640x480 and add some icons. Then I'll upload it. And svenksmansk, maybe you could then check it out on your monster monitor. (screenshot would be cool)

edit: It's called "AutoScaled". This actually does something and "false" should the way to go to have high res menus.

[TheAncientGoat]

Blablub: Nice to hear you're making progress, of course the autoscaling would be preferable, but it's not a traincrash if its impossible, especially if the skin ends it off in a way that it's not obvious that the screen edge should be there (for example, having the map in a globe or something, and not having a square "edge" to one side)

Can't wait to see it in action!

[svenskmand]

I think we should use then whole screen when it is there, also this make room for extra buttons that can be visible on screen at the same time. And making two gui one for 4:3 and one for 16:9 should not be much extra work as you said.

[StefanP.MUC]

I did a bit more thinking and genereal researchand calculating: I was looking and thinking about how other programs do the styling. And all I know just use absolute pixels (--> higher resolution means visually smaller pictures): OpenTTD for example and it works pretty good. And even MS Windows is doing the same. Set the resolution lower/higher and all the buttons keep their absolut "pixel count" (with the effect to appear smaller/bigger).
I really think we should do it this way, too, since it's the most easy and best looking way to do.

Now for some calculation:
Even in the most extreme case (640x480 -> 1980x1280 or something) the pictures only get smaller by a factor "3" - and this is the absolute (and probably very uncommon) maximum.
So, if we for example design the GUI for 800x600, then the button size would differ by a factor of a maximum of something like 2.5 - for most people it will be much lower (1 to 2).

Example: Assuming a "2.5 cm/1inch button" at 800x600 (roughly the actual current 0.4.7 layout) it will always at any higher supported resolution be at least "1 cm/0.4inch" big. This should be really good for any monitor/eye combination. In no real scenario it will never ever be a "small unidentifyable blob".

And talking about resolutions: I think we should drop any lower resolution than 800x600, nobody has such small monitors or weak graphic cards anymore.

Any comments on this?

Oh, and svenskmand: Changing 4:3 to 16:9 is "not hard", but it's A LOT. I'm not sure if I feel like doing this after getting one layout done.

[svenskmand]

I did a bit more thinking and genereal researchand calculating: I was looking and thinking about how other programs do the styling. And all I know just use absolute pixels (--> higher resolution means visually smaller pictures): OpenTTD for example and it works pretty good. And even MS Windows is doing the same. Set the resolution lower/higher and all the buttons keep their absolut "pixel count" (with the effect to appear smaller/bigger).
I really think we should do it this way, too, since it's the most easy and best looking way to do.

The hud/gui for any fps game scales with the resolution. Today I would say it is more common to scale with ressolution than not to scale. In the old days the different ressolutions where not that different in size, so having no scaling worked, but not today. Examples are all FPS games (AvP, UT3, L4D2, HL2, ...), Overlord, Alien Swarm, Dawn of War 2, ...

And talking about resolutions: I think we should drop any lower resolution than 800x600, nobody has such small monitors or weak graphic cards anymore.

That should be ok I think.

Now for some calculation:
Even in the most extreme case (640x480 -> 1980x1280 or something) the pictures only get smaller by a factor "3" - and this is the absolute (and probably very uncommon) maximum.
So, if we for example design the GUI for 800x600, then the button size would differ by a factor of a maximum of something like 2.5 - for most people it will be much lower (1 to 2).

Also in the future screen ressolutions will surly still go up, and at that point the factor might be 4,5,6 or even more, and at that time people will still want to play OD

Oh, and svenskmand: Changing 4:3 to 16:9 is "not hard", but it's A LOT. I'm not sure if I feel like doing this after getting one layout done.

Then do it when you feel like it. We only work on this project because we like

[StefanP.MUC]

I think simply multiplying everything with a factor "x2" in the future (like in 10+ years, a looong time ) to adopt the "new and big" resolutions will be easier than doing several custom independent styles.

SuperTuxKart has fixed pixel sizes as well and it looks great on all resolutions.

We shouldn't make us the life harder than it needs to be.

I think without support for vector based icons (there's no GUI system out there supporting SVG) it won't be easy to get what we want: an always exactly the same looking GUI by measuring the lengths in "centimeters" or "inches").

So, my final vote is: "fixed-width/height pixel icons" that are positioned relatively
Everything else is INHO either way to hard or complex (no reasonable gain-cost relation) or just not possible.

[StefanP.MUC]

OK, Update. Screenshot plus files (extract to your gui folder and run the game, it already works - no other files needed, only the attached ones in the 7z archive).

What's new?
Three basic (meaning bad ) icons (mana gold, territory), some rearrengments, some cleanup of the xml files, minimap placeholder (for the coders: to access it it's called "Root/MiniMap"and should already be usable), transparency on the controls at the bottom, removed the "movability" for the time being (can easily be readded after the final concept is clear), added a vertical scrollbar to the log box (enabled automatically if needed, disabled automatically if don't needed).

Reminder for the coders: if you decide to use this layout at some point in the future, dont' forget to rename the hardcoded strings in both the main() and in the xmls files as stated in some post above in this thread (for complete coherence). And multiline on the counters isn't needed anymore.

gui.7z

(38.59 KiB) Downloaded 395 times

800x600 preview screen

[oln]

Looking good so far.
Also we need to move the console text somewhere else (in the code) now that we have resource counters on the top left. Maybe we should use a separate tab?