2D UI layout library & example project

[Anonymous]

Hi guys. Recently I was working on a project which involved a custom from-scratch UI. Some friends asked if a portion of the code from it could be factored out for reuse as a library. Last week I had some time to do it, and yesterday I published it on GitHub: https://github.com/randrew/layout

It calculates the bounding rectangles of 2D user interface elements. It uses a box-stacking model, which you should be familiar with if you've used any standard UI toolkits such as GTK, Win32, etc. Stack boxes horizontally, stack boxes vertically, align or grow to fill empty space, you get the idea. It can also handle wrapping. However, it's not a full UI toolkit. It has no notion of widgets, it doesn't handle user input, and it doesn't draw anything to the screen. It only calculates layouts. It has a simple lightweight design, using a single CPU cache-friendly buffer and (mostly) sequential memory access.

It's fast and lightweight enough that the layout of a complex user interface with hundreds or thousands of elements can be completely recalculated every frame, without needing any kind of tedious invalidation. A typical UI layout will take only a few microseconds. This makes it nice for use in a game, where UI elements may change in size or position every frame.

It uses integer coordinates by default, but it can be built to use floating point instead, if you need fractional coordinates. (But keep in mind that most DPI-independent user interfaces are usually laid out using abstract 'points' anyway, and you probably don't want fractional points when aligning UI elements!)

It builds as C99 or C++, tested with msvc (VS 2015) and gcc (mingw64). In addition to working as a native code library, it can also be built as a Lua .dll module. I haven't played with Stingray or Scaleform Studio in a while, but I remembered that it lacked a UI layout solution. To test the library out as a Lua module, I've put together a simple example Stingray project which uses Scaleform Studio and the Layout library to create an example fake user interface. I've included a binary build of the Layout library as Lua module .dll with it. You can get the example project here: https://github.com/randrew/layoutexample

 
Keep in mind that Stingray/Scaleform Lua code which uses this library will probably spend more time in Lua overhead than performing the actual layout calculations.

Make sure to read the notes on the project page. Before the project will run correctly, you will need to manually edit a string in a script file with the path of the project on your disk so that it is able to find the layout.dll module.

This is my first time creating a Lua module, and I've probably made some mistakes. Let me know if there is anything I should change, or if there are any features you would like to have added.

[Anonymous]

I've updated the example project files for Stingray 1.3. Somehow I missed that 1.3 had been released. The project files were previously set for 1.2.5, which would cause an upgrade/migration warning to appear when opening the project in 1.3.

[_robbs_]

Really cool!

I tried it out and it works perfectly.

Nice work!!

[Anonymous]

Thanks! Do you know if it will be possible to make Stingray plugins or have a way to bundle Lua modules into projects? I have more utility things like this that I could make available for Stingray (stuff for first-person controls, motion graphics, etc.), but there's no way I know of to make it easy to distribute/bundle, make it filesystem-location-insensitive, and make it cross-platform or work with project packaging.

[_robbs_]

For Windows, you can make the deployer package up your DLL automatically.

http://help.autodesk.com/view/Stingray/ENU/?guid=__stingray_help_creating_gameplay_scripting_with_lu...

Basically put your .dll into the folder that contains your engine executable, and then add it to the package.manifest file that you'll find in the same directory. Then, when you deploy, it'll get copied automatically to the export directory.

Also, if you do it this way, the `require` calls in your Lua script don't need to reference any paths on your machine -- just require 'layout' ought to do it.

The downside of keeping the module in with the engine executable is that when you want to distribute the project source you'll have to accompany it with the modules and instruct the person using the project to copy the module DLLs to their own engine folder and update their manifest file.

[Anonymous]

Cool, thanks! But yeah, ideally I would be able to keep the .dlls inside of the project directory, that way there are no problems with different projects having different versions of modules and that sort of thing (and requiring admin privileges to write into the Stingray bin directory).