Below you can see LeadwerksGUI running nicely on Ubuntu. Once we get through the window and event code, the GUI code acts exactly the same on Linux and Windows. The behavior of the widgets is reliable and double-buffered rendering makes the appearance perfectly solid. Image loading is not working yet, but you can see the vector graphics are working perfectly.
Leadwerks GUI will provide a smoother user experience on Linux and give us cross-platform UI consistency across all operating
I figured out how to make our GUI resolution-independent so that the existing editor code will correctly create items with the same proportions. This was very difficult, and it works really well! Some images aren't scaled here, but the important thing is the existing code is working the same, with no changes.
When the GUI is scaled to 200%, the buttons are bigger and indented further in from the right / bottom edges. The code that creates them just calls the parent ClientWidth() minus 74
A new build is available on the beta branch on Steam. This updates everything, C++ and Linux included.
A bug where the editor skipped navmesh calculation on brushes is fixed.
We're updated to the latest version of the Steamworks SDK, which may fix some Workshop upload and download issues.
Animation now calculates more than twice as fast as previously. This was achieved by optimizing the animation code, implementing some inline functions, and by changing the way the matrix updating
We're up to 81 games in Steam Workshop now, and I expect we'll see quite a few more released before the end of the tournament. Some of the stuff this tournament especially is really good, so it's not too soon to start thinking about the final release of game launcher on Steam. At that point the application will no longer be marked "Early Preview" and will get a big increase in downloads on Steam since its visibility will be much higher.
I want to launch with at least 100 total games. This
So I've been using Valve's VR technology quite a while before the HTC Vive was released, but I only recently picked up the final consumer version. Here are my thoughts on VR games.
First, VR games are completely different from non-VR games. Motion in the virtual world should never contradict motion in the real world. All the early Oculus demos are examples of what not to do.
"The Lab" by Valve really shows the depth of interaction VR opens up. You interactions with the virtual world
The beta branch of Leadwerks Game Launcher on Steam is now using Leadwerks GUI. You can try it out now for free here:
http://store.steampowered.com/app/355500
As described previously, I decided to create a custom widget script to replace the game launcher's HTML panel. The results are already looking awesome! The UI looks really slick. It's great to see this idea come to life in such a striking and attractive manner.
What's really cool is the OS drawing commands are being used, so the games grid uses cleartype subpixel antialiasing, and the UI is completely solid with no flashes or little visual glitches.
Oh, and except for the window
When the new Window::Embedded style is used in the window creation function, the window will appear as a panel, as part of the parent window. The black region here is an embedded window parented to the main window. (The tabber and other panels and controls are all just Leadwerks objects; Windows doesn't recognize them or know they're there, as they are just created by Leadwerks structures and drawing commands.)
Why is this special?
The embedded child window uses single-buffer draw
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
MaxGUI is an abstracted GUI system for the BlitzMax programming language. This allows Windows, Mac, and Linux native UIs to be created using the same code. The LeadwerksMaxGUIDriver module integrates Leadwerks GUI so that existing programs can be recompiled using our new UI system. Here's the first shot of it working in an actual existing program:
The text area widget is now available on the beta branch on Steam, for Windows and Lua only at this time.
The text area is a read-only widget at this time. However, the text is all selectable, and in the future will be able to be copied to the clipboard. This widget creates two scroll bars which appear only when needed, for horizontal and vertical scrolling. The multiline text selection and scrolling was pretty difficult to implement, but the results are really nice.
I'm not goin
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
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 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
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
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
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
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
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
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
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