FlowGUI

[AggrorJorn]

FlowGUI is a flowgraph and editor based GUI system for Leadwerks 3.

 

1.0 release

http://www.leadwerks.com/werkspace/topic/11262-flowgui-for-leadwerks/

 

 

 

Thank you to Rick for finding the global Lua table issue.

 

[josk]

This is great, also nice relaxing music while you watch the video.

 

I'm assuming normal/hover/click image would show a different image on clicking.

 

Do you record video with Fraps?

[AggrorJorn]

Yips, You can have a different color or image for normal state, mouse hovering state and mousedown/mouseHit state. Images weren't working yet when I recorded. Recording is done with Camtasia.

[YouGroove]

Awesome.

How are made buttons ? 3D planes ?

Could we use our own alpha rounded background image for buttons ?

[AggrorJorn]

buttons are either 3d 2d rectangles or textures. You can load in any kind of texture you want. The boundries stay rectangle though. I have added submenus to the list as well since they are quite easy to implement.

[Rick]

buttons are either 3d rectangles or textures.

 

So they can be planes? Is that what you are basically meaning with 3D rectangles? So you are doing like an entity pick vs a 2D screen check for those?

[AggrorJorn]

Whoops typo. Its just 2d rectangles.

[shadmar]

Nice. so where can I pay?

[AggrorJorn]

FlowGUI 0.1.2

 

Menu's can now be placed on 9 different locations for both horizontal as well as vertical.

 

Menu options.

 

Horizontal example

 

Vertical example

[AggrorJorn]

FlowGUI 0.1.3

 

Buttons now support images (with alpha).

 

[YouGroove]

great.

[AggrorJorn]

FlowGUI 0.2.0

 

Checkboxes added.

• Checkboxes can be either staticly positioned or part of a menu. (Just like buttons)
  
• Checkboxes can be either rectangles where you set the colors for or you pick your own images.
  
• Checkboxes can have text positioned to their Left, Right, Above or Underneath the checkbox.
  

 

[AggrorJorn]

FlowGUI 0.3.0

Sliders added.

• Sliders can be either statically positioned or part of a menu. (Just like buttons)
  
• Sliders can be either horizontal or vertical
  
• Sliderscan be either rectangles or images
  
• Images for:
  
  • Background
    
  • DraggerNormal
    
  • DraggerHover
    

  [*]Colors

  • Border
    
  • Background
    
  • PercentageLine
    
  • DraggerNormal
    
  • DraggerHover
    

  [*]Sliders can have text positioned at them: AboveLeft, AboveCenter, AboveRight, Left, Right, UnderLeft, UnderCenter, UnderRight

Todo for slider:

• Stepsize: Slider value jumps in steps of 10 or 25 for instance.
  

 

[Rick]

Is positioning and scale using % of the screen or absolute? I love what you are doing here, but with 2D, I have a fear that resolution and aspect ratio independence is going to be an issue. Different resolutions within the same aspect ratio, positioning and scaling can be solved by using %'s of the screen instead of absolute, but I've found different aspect ratios generally cause issues. A set of %'s for positioning and scaling for 1 aspect ratio doesn't work with another. Unless there is some formula to alter those %'s by aspect ratio, I've had to do it the brute force way of defining different %'s for different aspect ratios. If there was some math you could do on the %'s for different aspect ratios then it would be all good, but using %'s for positioning and scaling is the key starting out. For most video games I don't think absolute positioning/sizing works.

 

I don't want to discourage you but instead to think about the possible pitfalls and maybe start a dialog about it. This has been my experience but maybe I missed something when I was doing it, but this is why I'm looking more into 3D (textured planes) UI. Even if there was a mathimatical way to adjust for aspect ratio when using % for positioning/sizing the scaling of 3D textures on objects seem to look much better than 2D scaling of textures. Not sure why that is or if it can be overcome. These are very important aspects of a GUI though because nothing would be worse than making an entire game using only 1 screen resolution and then when you go to allow various others, or making mobile game which automatically has many different resolutions, running into this problem then.

[AggrorJorn]

Don't worry Rick, it is good to discuss about development and receiving feedback.

 

I have done several attempts at gui libraries in both Lua, C# and C++. Based on previous experience I want to make a mix of ratio scaling and percentages for buttons. This combination allows the user to set up hers/his environment without having to worry about it. This is not without flaws however. The script that I currently have is not as 'nice' or well structured as I wan't it to be, but then again, that is the price you pay for trying to make it work in as many situations as possible.

 

For PC (and max and linux) I now an environment that adepts itself to screen resolution and ratio. There are problems that occur when I want to position close to bottom and right border though. I have to manually catch these by checking for boundary breacing. The isue here is that there multiple solutions to these problems. It takes a lot of tedious and fragile scripting to solve these stupid things. Most of the time they are really minor issues that probably only a trained designer would notice, but when working with GUI, I find them really annoying.

 

I will post some test on realltime resolution scaling between several ratios and what possible solutions are. It is an interesting topic I am 100% dedicated to solving it once and for all.

 

And one more thing; the current FlowGUI is aimed towards PC, Mac and Linux. Once this works good enough, I will have a look at Mobile/Tablet. I suspect there will be lovely anomalies waiting for me there.

[Rick]

I am interested in how you handled different aspect ratios when %'s are used for scaling and positioning as that's where I was unable to easily come up with a way when I was doing my GUI. I had separate config files for different aspect ratios, which is tedious to setup at GUI for.

[AggrorJorn]

It is a process that I like to call 'Sacrificing'.

 

For example:

• GUI BaseResolution 1280 x 800 (ratio:16:10). Button: 200, 40
  
• User has a resolution of 1024 x 768 (ratio: 4:3).
  
• We calculate the ratioScalar:
  
• 1024 / 1280 = 0.8.
  
• 768 / 800 = 0.96. 40 * 0.96 = 38.4
  
• Apply the RatioScalar
  
  • 200 * 0.8 = 160
    
  • 40 * 0.96 = 38.4
    

 

In case we want to preserve original height:

• We make sure that we have a width that is easy to divide by the ratio height. 38.4 % 3 = 2.6 (36 is a nice number ).
  
• Now we have to make sure that the width ratio is correct again.
  
• 36/3 = 12 * 4 = 48
  
• new scale: 48 x 36.
  
• The button is now significantly smaller then with the previous scale, but the height is preserved. This situation is not that common.
  

 

 

In case we want to preserve the width:

• We make sure that we have a width that is easy to divide by the ratio width. 160 % 4 = 0. So 160 is perfect
  
• Now we have to make sure that the heihgt ratio is correct again.
  
• 160 / 4 = 40 * 3 = 120
  
• new scale: 160 x 120.
  
• The button is now smaller in the height but a lot bigger in the height.
  

 

 

Conclusion: either way you have to make a decision on where you want to sacrifice.

Do you want a tiny button that does not exceed the boundries of the previous scale?

Or do you want a smaller button that is more in conform to the previous size, but will exceed the boundries of the previous scale.

 

The question that remains is: where do you position the button with its new scale and or should the user be given the option to chose if width or height has to be preserved?

 

You could let the users choose again but this would take a tremendous amount of time and the script would become very large and somewhat unmanagable. TopLeft, TopCenter, TopRight, CenterLeft, Center etc....

 

In most cases people will go for TopLeft. This had the immediate benefit that we don't need recalculation of the position.

This works in 90% - 95% of the cases. However sometimes this can lead to unwanted results when menu's or GUI elements are directly aligned to the window border. Here I have to use manual solutions that solve these problems. I found 6 situations so far that make the gui inaccurate when using the sacrificing technique, but I was able to solve them with alternative scaling and positioning.

[Rick]

Ah very cool. I'm really hoping the 3D planes that I'm working with work out with the other aspects of a GUI because it is nice that it handles all of this scaling automatically. I hate dealing with that ****

[YouGroove]

This had the immediate benefit that we don't need recalculation of the position.

This works in 90% - 95% of the cases

 

Good.

Will it be some general alignment system from what i read it seems yes : Center, top, low Center etc ...

 

Will it be enought in term of performance to keep some buttons or HUD during gameplay in game like :

-Buttons to open some menu

-Healthbar display

Can it be measured in terms of draw call ?

[AggrorJorn]

You can display all of gui elements whilest having a scene in the background. The progress bars can be used to show the XP or health for instance. You can use labels to show mission info. You can use buttons for an.inventory.

[AggrorJorn]

A little video showing some new possibilities with auto soft scaling and positioning.

 

[YouGroove]

Great work.

The use of invisble Pivots with attached Lua is incerdibly usefull.

[Rick]

Love it Aggor!

 

@YouGroove Actually having to use pivots is a workaround for not having a logical entity, but Josh mentioned he wants to add a logical entity to avoid having to put pivots in our scene.

[AggrorJorn]

The next updates involve the following:

• Sliders (still a nasty bug somewhere )
  
• Labels 0.3.1
  
• Single Image
  
• Font Manager
  
  • Select your font
    
  • Select your size.
    
  • Apply font to menus.
    

[Patrick]

Hey Aggror, are you still working on this?

 

I saw it a while ago but I've only just now downloaded the pdf and read over it... This is really handy so far I have yet to play around with it in the engine, I will do that once I have had some sleep, but I just wanted to say nice work.

 

Also, I think I have some GUI graphics I created sometime last year that I never got around to using, If I can find the files you can have them to include in this, they were themed around an RPG game though. I will look for these later (after some sleep) and that was why I asked if you were still working on this.