It took most of the weekend, but I've got Leadwerks GUI running on Linux, rendering directly to an X11 window. This is the fastest possible rendering method on Linux, and I think you'll agree the results are worth it. You can try a demo here:
http://www.leadwerks.com/werkspace/topic/14867-gui-demo/#entry100912
Just like the Windows implementation, I found it necessary to implement double-buffering. In X11 this is accomplished with the use of an extension called "xdbe". The document
In Leadwerks GUI, any widget can be the child of another widget. If the child goes outside of the parent widget's area it will be clipped for both rendering and mouse events. Below you can see the button in the upper-left corner and the progress bar and slider on the right are clipped by the parent tabber.
A parent widget can also have a padding value which indents the area. The tabber uses padding on the top to display the tabs and make sure children don't appear on top of the tabs.
The slider widget is used for scrollbars, trackbars, and steppers. It has a lot of style options, so it's really six different widgets packed into one. (In Leadwerks Editor, a slider and textfield widget are combined to make the numerical entries you use to adjust positions and other values.)
To create a new slider you just create a widget and set the slider script:
local slider = Widget:Create(230+40,140,20,20,panel)
slider:SetScript("Scripts/GUI/Slider.lua")
You can then se
The combobox and listbox widget scripts are now updated. The combobox is presently using a more game-like style that jus shows the currently selected item. You can change the selection by clicking on the widget with the mouse, pressing keyboard keys, or scrolling the mouse wheel.
The listbox includes a slider that automatically appears when needed. In order to make rendering faster, the draw function calculates the first and last visible items, and only iterates through those items while
It took a few hours to add scrolling to the textfield widget. Now when the caret moves beyond the bounds of the box, text will slide over to keep the caret visible. This really isn't much different from a full text editor. The script is available now on the beta branch on Steam and presently weights in at 381 lines of Lua code.
The Draw function is pretty short and easy to understand. I think most people will customize the appearance of these widgets more than the behavior:
f
I've added a textfield widget script to the beta branch, and a new build, for (Lua interpreter, Windows only, at this time). The textfield widget allows editing of a single line of text. It's actually one of the more difficult widgets to implement due to all the user interaction features. Text is entered from the keyboard and may be selected with arrow keys or by clicking the mouse. A range of text can be selected by clicking and dragging the mouse, or by pressing an arrow key while the shif
I've added an optional radius for rectangle corners, for use with the DrawRect() command, along with a new gradient mode that uses a second color to draw a linear gradient on primitives. I like the interface for the program Vue, and I am modeling my default widget scripts after this style.
Here it is rendered at 800% scale. This is rendered directly on a window and sub-pixel antialias is used (Microsoft ClearType):
The appearance of the button widget at this point is somethin
I've updated the beta branch (Lua on Windows only) with a new build that solves the DPI scaling issues I previously described. Widget creation still works the same, using the same coordinate system regardless of GUI scale. Widget scripts must use global coordinates in the drawing commands, which means calling Widget:GetPosition(true) and Widget:GetSize(true). Here's the very simple panel script, which simply draws a solid block on the screen to frame child widgets within:
function Script:D
At 100% scaling this image appears correctly:
At 200% scaling it falls apart. The line points are in fact scaled correctly, but they are not surrounding the shape as intended:
So I think instead of converting the coordinate system back and forth between scaled and non-scaled coordinates, the creation function needs to multiply the coordinates by the scaling factor. That means if you create a 70x30 pixel widget and the GUI is using a 200% scaling factor, it will actually create a 14
I've implemented DPI scaling into Leadwerks GUI (beta branch, Lua on Windows only).
To set the GUI scale you just call gui:SetScale(scalefactor). A scale factor greater than one will make it bigger, a scale factor less than one will make it smaller. There is no limit to the range you can set, but negative numbers are probably not good.
Scaling causes the GUI to be drawn at a different size, but widget dimensions and mouse events are still interpreted as though they were at their origin
Leadwerks GUI is now functioning, on the beta branch, Windows only, Lua interpreter only.
GUI Class
static GUI* Create(Context* context)
Creates a new GUI
Widget Class
static Widget* Create(const int x, const int y, const int width, const int height, Widget* parent, const int style=0)
Creates a new Widget. Widgets can be made into buttons, dropdown boxes, or anything else by attaching a script.
virtual bool SetScript(const std::string& path, const bool start = true)
Se
To provide support for advanced GUI rendering, some of the features I implemented in the refactored window class are being brought into the 2D drawing command set. This includes a lot of text rendering features like word wrap, multiline, horizontal and vertical centering, and viewport clipping.
A new text drawing function includes additional parameters for better control:
Context::DrawText(std::string text, int x, int y, int width, int height, int style)
The style parameter can be
An update is available on the beta branch. This adds the Window::Center style back into the new refactored Window class, and adds a missing header file in the Professional Edition.
If you'd like to try out a basic implementation of the new GUI, download and extract the attached scripts:
Scripts.zip
This code will create a GUI on the rendering context. It simply consists of a solid background filling the screen and a textless button.
--Initialize Steamworks (optional)
Steamworks:Ini
The beta branch on Steam is updated with a new build. This uses the refactored Window class, on Windows and Linux. The GUI and Widget class are also added, although they are highly experimental and still in development. Both the engine and editor are using the refactored Window class, so please report any erroneous behavior your detect.
Leadwerks is now using GDI+ for some GUI drawing commands, on Windows. You need to update your existing project by modifying the "Linker \ Input \ Additi
This code creates a GUI directly on a window, with no OpenGL rendering context created at all. The same scripts can be used for widgets created on a window, a rendering context, or a texture:
--Initialize Steamworks (optional)
Steamworks:Initialize()
--Set the application title
title="$PROJECT_TITLE"
--Create a window
local windowstyle = window.Titlebar + window.Resizable + window.Hidden
if System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+window.FullScreen end
window=Wind
This code added to main.lua actually works:
--Create a window
local windowstyle = window.Titlebar
if System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+window.FullScreen end
window=Window:Create(title,0,0,System:GetProperty("screenwidth","1024"),System:GetProperty("screenheight","768"),windowstyle)
window:HideMouse()
--Create the graphics context
context=Context:Create(window,0)
if context==nil then return end
--Create a GUI
local gui = GUI:Create(context)
local widget = Wid
GUI* GUI::Create(window);
GUI* GUI::Create(context);
GUI* GUI::Create(texture);
A GUI created on a window would draw to the window, with no graphics context, and would be used for making 3D applications (like Leadwerks Editor). A GUI created on a context would use OpenGL drawing to render the GUI onto the context. A GUI created on a texture would require the user to manually input events and would be used for interfaces that appear in the 3D world, like a computer panel you can interact
Our ranking on Steam is 185 ratings with 75% positive, which Steam categorizes as "Mostly positive". This is great. Over the last couple of years the reviews have gotten more positive as more features and better documentation has been added. So at this point, the more reviews we get the higher our rating goes, since our average rating today is better than when we started on Steam.
From what I gather looking at other products on Steam, we're only 5% away from a "Very positive" rating at 80
Just thinking out loud here, and I am considering designing the GUI like this:
The GUI class handles events, window clipping, widget layout, etc. Rather than having a bunch of C++ classes that extend a base Widget class, there would just be the Widget class with a Lua script attached to it. The Lua script would handle all events and drawing, so it would determine what kind of widget the C++ object is. For example, here's a script for a simple button:
function Script:Draw(x,y,width,h
An update is available on the beta branch. This includes all recent bug fixes, and is a full build with C++ libs for Windows and Linux.
The following header search path needs to be added to your Visual Studio projects:
$(LeadwerksHeaderPath)\Libraries\glslang
An update is available on the beta branch. This only updates the editor, only on Windows.
The environment probe entity should now be available to create in the editor, for all users.
When shaders are compiled with the "Debug" button (F5) they will now be run through the GLSlang reference compiler first. This can help to catch errors that more permissive hardware lets slide by (Nvidia). The goal of this is to prevent games from not working on AMD and Intel hardware when they use third-
Leadwerks Game Engine 4.1 beta is now available on the beta branch on Steam. This is the final version 4.1, barring any bug fixes that are made before the release later this month. I am going to focus on just resolving bug reports and adding new documentation for the next two weeks.
4.1 adds environment probes, which have been covered previously, and volumetric lighting. Point and spot lights can display a volumetric effect by adjusting the "Volume strength" setting, found under Ligh
I came across a very interesting presentation that talks about how to avoid "banding" artifacts in game graphics. The author uses dithering to add noise to an image and break up the visible lines your eye can detect. This even works with audio. When noise is added to the mix, the original tune appears to become more high-fidelity than it actually is:
I was able to use this concept to improve the appearance of banding in shadow acne in a low-resolution spotlight with a large volum
First, there's a lot of confusion about what HDR actually is, and I want to clear it up. HDR does not automatically mean "iris adjustment" although the two often go together. HDR, at its simplest, means that colors won't get washed out during the rendering pipeline.
Game graphics inputs are 8-bit (per channel textures). The output is 8-bit (unless you have a 10-bit monitor). So if we only perform one rendering step, it is impossible to lose color resolution. Even if our lighting step br