GUI

[oln]

Probably something changed in the code then. Just ignore that for now, i'll look at it later.

[StefanP.MUC]

Ah, maybe I found it. The host button calls startServer(). And there are also hardcoded GUI strings that set the active tab yet to a non-existing one. I corrected this. But this is surely no place where no GUI calls should happen.

[svenskmand]

edit: In the gui folder, there is a "bluehighway-12.font" file. Open it with a text editor and set at the end of the file AutoScaled="false" (currently it's true). This should solve the font problem for now. In my next GUI release this will be already the default.

It now looks like this (see attachment). I am sorry to say, but now I am having trouble reading the text. It should be at least twice the size.

[oln]

It would be best if the text could scale dynamically.

[svenskmand]

Yes, but then we need to not use text inside of bitmaps in the gui else these bitmaps also need to scale which blablub wanted to avoid. But I still think scaling the whole think would be best in the long run.

Blablub can you show how it looks if you let CEGUI scale the whole GUI dynamically? (if it is not too much trouble).

[StefanP.MUC]

If the text would scale, the bitmaps would need to scale too, but this can't be achived, becaue it destroys the aspect ratio (CEGUI and also no other GUI can do this) and also looks very unsharp then. It will be possible of course to raise the font size.

svenskmand, here's a link explaining all the options for the font files:
http://www.cegui.org.uk/wiki/index.php/Font_files
You can try to play around with. Maybe inserting Size="14" already fixes it (default is 12) without destroying the look on smaller resolutions.
Maybe another solution could be to use a low font Size, but let it be AutoSaled="true" (this is doing as far as I understand it, that the absolut size of text - the one you measure with a ruler at your monitor - is always the same.)

[TheAncientGoat]

What about tiling? Breaking the bitmaps apart into corners, borders, and background, and then making them tile as the size gets bigger?

[StefanP.MUC]

CEGUI is doing that already, but it doesn't keep the aspect ratio. A fully automatic-scaling AND nice looking GUI can only be done for exactly ONE resolution aspect ratio (4:3 OR 16:9 OR 16:10). If we design it autoscaling for 4:3 then it will look very bad on 16:9 screens. That's why I have to use absolute pixel lengths. And this is leading to small controls on very large resolutions.

The two possibilities are:
1) Take it as it is now: small but good looking gui on huge resolutions - that's how most apps are doing it that use pixelart GUIs
2) create a layout for each possible aspect ratio - the common ones I know of are 4:3, 5:4, 16:9, 16:10. But this a HUGE amount of work (hundreds of {x,y} pair calculations made by hand) and makes it more bug-prone (not to talk about users with uncommon aspects ratios - they will be left out completly). Also, when using non-tilable pixelart icons in this scenario (what we are going to to) they will be scaled up/down, meaning will get blurry.

I'll definitly will stick to number 1), but since this is an opensource game, anyone can try number 2) and see if he get's better results.

[svenskmand]

It needs to work on all the common resolutions we are using today. But it would be best if it worked for any future resolution

[andrewbuck]

I think blablub has the right idea on this. The issues everyone else is raising here have obviously been raised by other people and no one seems to have found a good solution or everyone would use that. Using fixed sizes for the buttons and relative positions allows you to use "whitespace" to adjust to slightly different sizes/aspects without too much deviation from the intended design. When the game gets more complete we could offer 4 layouts, a small and large version of 4x3 and 16x9. The large versions could be identical to the small ones, just with their button images externally scaled (in gimp or something) to exactly twice their original size (so you don't get artifacts). So if someone starts at 640x480 and keeps upping the resolution the buttons will get smaller and the whitespace will grow until about 1280x960 when the "large button" version kicks in. This will make the buttons the right size again and they will only shrink by ~25% by the time you get to 1600x1200. In the future when we have 4000x3000 displays we can just release a quick 3x scaled version and be good again. This addresses the issues pretty effectively and means we only need to make two manually built versions and one manually created set of buttons.

-Buck

[oln]

We could also have the GUI size as an option in the menu instead of scaling if we have more than one size.
If we are planning to go with this approach, it might be an idea to have the person making the icons make them at the size meant for the "large" buttons (or ideally vectorised), and then use a downsized version when the gui is "small".

[StefanP.MUC]

I think it's a loooong way until more than 1% of all users will have more than 2000xsomething resolutions. Most users will never go above 1280x something, since it's the notebookresolution (they won't grow much bigger).

As I already said somewhere: we shouldn't make the life harder than it is for the start. Even many commercial games have very ugly GUIs (--> GUIs seem to be problematic in general).
I have now everything in the GUI part cleaned up, gave good names, created the framework. This already looks very good on many resolutions (starting at minimum of 800x600 up to 1920xsth.), even without much content or "uniqueness" (considering the very early alpha state of the game).
If there will be some time in the future when there are 10000x6000 displays, then also CEGUI will be at version 1.5 with A LOT more features to cover this new situation and take a lot of work from us.

So, I'd say for now: It's time to create GUI content and not worry about the technical aspects anymore.

[andrewbuck]

Yeah, large size content would be preferable as you say, I was just saying scale them up for the sake of outlining the basic idea.

I tested the latest GUI layout and works on my system here. I did notice a problem though when you middle click on creatures the game crashes. Part of the issue was the names were still using TaharezLook so I changed that (I will push the changes to git so others don't have to change them manually), but it still throws an error when I try to spawn the window. The code which does this is located in src/Creature.cpp around line 1950. It should create a text window and then fill it with some text. I thought I would post it here as you know more about CEGUI at this point than I do. Here is the error that gets thrown to the terminal when you middle click.

-Buck

{l Code}: {l Select All Code}

Info: Freetype returned null for character 160 in font MyFont
Texture: MyFontTexture: Loading 1 faces(PF_BYTE_LA,256x256x1) with 0 generated mipmaps from Image. Internal format is PF_BYTE_LA,256x256x1.
CEGUI::UnknownObjectException in file CEGUIWindowFactoryManager.cpp(180) : WindowFactoryManager::getFactory - A WindowFactory object, an alias, or mapping for 'OpenDungeons/FrameWindow' Window objects is not registered with the system.
terminate called after throwing an instance of 'CEGUI::UnknownObjectException'
  what():  CEGUI::UnknownObjectException in file CEGUIWindowFactoryManager.cpp(180) : WindowFactoryManager::getFactory - A WindowFactory object, an alias, or mapping for 'OpenDungeons/FrameWindow' Window objects is not registered with the system.


[StefanP.MUC]

Rename "OpenDungeons/FrameWindow" to "OD/FrameWindow".

I named all the basic control element types "OD/something" to separate it from the content (in the example file everythig had exactly the same name, that was confusing).

[andrewbuck]

Ok, I will have a go at that then. I like the idea of the separate naming scheme. That was something I wanted to work on with regard to the content cleanup discussed in the other thread as well. Getting a consistent naming policy for everything would be good.

EDIT: This fixes it. I will push the changes to git then. Also, if you want to look at how that window is done too that would be cool. The position/size settings are at that same spot in the code and the window types were just chosen somewhat at random, I don't know if those are the best solution out of what is available.

-Buck

[StefanP.MUC]

I just pushed a svn commit containign new unique pictures and tooltips for each button. The new GUI now has everything from the old and more. It won't block the 0.4.7-final release anymore.

Oh, what do you mean? Creating the creature info in the layout file?

[svenskmand]

I think blablub has the right idea on this. The issues everyone else is raising here have obviously been raised by other people and no one seems to have found a good solution or everyone would use that. Using fixed sizes for the buttons and relative positions allows you to use "whitespace" to adjust to slightly different sizes/aspects without too much deviation from the intended design. When the game gets more complete we could offer 4 layouts, a small and large version of 4x3 and 16x9. The large versions could be identical to the small ones, just with their button images externally scaled (in gimp or something) to exactly twice their original size (so you don't get artifacts). So if someone starts at 640x480 and keeps upping the resolution the buttons will get smaller and the whitespace will grow until about 1280x960 when the "large button" version kicks in. This will make the buttons the right size again and they will only shrink by ~25% by the time you get to 1600x1200. In the future when we have 4000x3000 displays we can just release a quick 3x scaled version and be good again. This addresses the issues pretty effectively and means we only need to make two manually built versions and one manually created set of buttons.

-Buck

This is what I would like to see done too.

We could also have the GUI size as an option in the menu instead of scaling if we have more than one size.
If we are planning to go with this approach, it might be an idea to have the person making the icons make them at the size meant for the "large" buttons (or ideally vectorised), and then use a downsized version when the gui is "small".

All my stuff is vector graphics any ways so it should be good

As I already said somewhere: we shouldn't make the life harder than it is for the start.

Yes no need to rush, but we need to be aware of the future, and not just rush into a blind-end. Else we might end up having to dispose of allot of valuable work.

[StefanP.MUC]

The new GUI can comparably easy be "multiplied" by two. Maybe this can even be done in "realtime" (by telling the source code to x*=2, y*=2 and load a different x2-imageset at runtime, but not sure on this). But this is only possible with absolute pixel lengths. If I had done relative pixel sizes than everything would be a mess with different monitor aspect ratios.

[andrewbuck]

The new buttons look pretty cool, definitely a huge improvement over the old system. It will be nice to be able to include all of this in the final 0.4.7 release in a few days. The game has definitely improved since the release candidate came out.

If it is possible it would be nice to have the buttons that say Rooms, Traps, Spells, etc, be a little bit bigger. On my monitor (1680x1050) they look a bit small (and are somewhat hard to hit). I would suggest scaling them up so that they take up most of the width of that window on the bottom left, the height can probably be increased by the same amount to make the aspect ratio stay the same. This will make them a lot easier to push when you need them.

-Buck

[StefanP.MUC]

I increased the tab height from 20 to 30 pixel and the text padding from 6 to 10 pixel.

[andrewbuck]

That looks better. If we don't plan to add any more buttons to that section it could be made the full width, but this is already quite an improvement.

-Buck

[StefanP.MUC]

OK, now that the rough technical framework is clear, I'll start to modify the looknfeel and put together the basic imageset (the window tiles, like frameborders and tooltip background). These currently still are mostly the original ones from the example and contain a lot of unused and unordered stuff.

[Danimal]

Somehow i think the actual textures for buttoms looks nice even if they are so rough, good work on the GUI

[TheAncientGoat]

Yeah, I think the new GUI is looking very good so far, I really like the room icons

[StefanP.MUC]

I just did some further reading on CEGUI. About the whole scaling/aspect ratio/resolution topic. There's a function in CEGUI that should always be called when setting a resolution for the first time as their forums say.

http://cegui.org.uk/api_reference/class ... b90779929c
http://cegui.org.uk/api_reference/class ... 77a93dbfb1

For OpenDungeons this would be at start up and after we have have a proper ingame graphics options menu we need to call this there, too. I have the feeling this could reduce a lot of the above mentioned problems. Maybe we can then even switch back to autoscaling.

Calling this function ensures that any other parts of the system that need to know about display size changes are notified. This affects things such as the MouseCursor default constraint area, and also the auto-scale functioning of Imagesets and Fonts.