Checking if a directory exists in pure Lua is actually not an easy thing. Lua does not have the functions to get information about the file system and directories. You can test if a particular file exists in a folder by trying to open it (but the test can fail even if the folder exists…).

One way to properly check if a directory exists is to use the LFS library. The LFS (LuaFileSystem) library works on Unix and Windows and offers functions to access the underlying directory structure and file attributes. With LFS, we can easily check if a folder exists:

function dir_exists_v1(path)
  if (lfs.attributes(path, "mode") == "directory") then
    return true
  end
  return false
end

The LFS library is available in GeeXLab. Just use the lfs library name in your Lua scripts.

In the startup demo of GeeXLab, the dir_exists() function based on LFS is used to check if the demos/ folder exists (in frame.lua) in order to display the Demos folder button:

local app_dir = gh_utils.get_app_dir()
local demos_dir = app_dir .. "/demos/"
if (dir_exists_v1(demos_dir)) then
  ...
end

 
Another way to check the existence of a directory is to use the rename function of Lua’s os library: os.rename() (based on this stackoverflow reply). Here is the dir_exists() function with os.rename():

function file_exists_v2(file)
  -- some error codes:
  -- 13 : EACCES - Permission denied
  -- 17 : EEXIST - File exists
  -- 20	: ENOTDIR - Not a directory
  -- 21	: EISDIR - Is a directory
  --
  local isok, errstr, errcode = os.rename(file, file)
  if isok == nil then
     if errcode == 13 then 
        -- Permission denied, but it exists
        return true
     end
     return false
  end
  return true
end

function dir_exists_v2(path)
  return file_exists(path .. "/")
end

This function dir_exists_v2() works fine but is slower than dir_exists_v1().

 
And just for fun, here is the Python version of dir_exists()

def dir_exists(path):
  return os.path.isdir(path)

More on os.path here.

• OpenGL 2.1 Demopack Download
  Demo: {geexlab-demopack-gl-21}/d47-zerobrane-debug-lua/main.xml
  GeeXLab 0.29.15+ is required
• GeeXLab Downloads
• ZeroBrane Studio Download
• Forum thread (EN)

ZeroBrane Studio is a lightweight Lua IDE with code completion, syntax highlighting, live coding, code analyzer, and, important thing here, it has the debugging support for Lua 5.1, Lua 5.2, Lua 5.3 and LuaJIT.

GeeXLab uses Lua 5.3.4 and the Lua engine is embedded into GeeXLab.

Question: how can we debug an Lua script that runs inside GeeXLab with an external debugger that has its own version of Lua ?

Answer: thanks to mobdebug. In a word, mobdebug is Lua lib that is loaded in any GeeXLab demo using the require command. Once loaded and started, mobdebug does a TCP connection to ZeroBrane (on port 8172). Once connected, ZeroBrane controls the target Lua script and suddenly we have the power to step into our Lua code. That’s all!

Now, let’s look at how to debug a GeeXLab demo in Lua with ZeroBrane.

Remark: GeeXLab 0.29.15+ is required to debug Lua scripts ZeroBrane (more info HERE)

 
1 – Put mobdebug.lua in your INIT script. mobdebug.lua is shipped with the GeeXLab demo and is also shipped with ZeroBrane Studio (in the lualibs/ folder). Here is a way to add mobdebug.lua in an INIT script (see THIS ARTICLE for more details on require()):

local demo_dir = gh_utils.get_demo_dir()
package.path = package.path .. ";" .. demo_dir .. "mobdebug.lua;" .. demo_dir .. "socket.lua;"
require('mobdebug').start()
...

 
2 – Launch ZeroBrane (zbstudio.exe) and start the debug server. This is fundamental because mobdebug in the GeeXLab INIT script will try to establish a connexion with that server.

You can download ZeroBrane from THIS PAGE (windows) or from THIS ONE (windows + linux).

 
3 – Open the INIT script with ZeroBrane. I put a breakpoint (CTRL+F9) at line 26:

 
4 – Everything is ready. We can now start the demo in GeeXLab and you showld be able now to step into the Lua code with ZeroBrane:

 
To add a breakpoint on a line, select the line and add the breakpoint with the mouse or, better with CTRL+F9. To run the code until next breakpoint, press on F5. To step into the code, use F10. All controls can be found in the Project menu.

 
5 – To watch the content of any Lua variable, just use the menu Add Watch Expression. In the following screenshot I added winW and winH variables to the watch window:

 
More links:

• ZeroBrane Studio homepage
• Remote debugging

• OpenGL 2.1 Demopack Download
  Demo: geexlab-demopack-gl-21/d46-lua-package-require/main.xml
• GeeXLab Downloads
• Forum thread (EN)

Lua’s require() function is like dofile(): it allows to load libraries. But there are some important differences:
– require uses a search path to find libraries
– require does caching

require uses the package.path to search for a library. package.path contains all possible folders with Lua libraries. But before loading a library, Lua looks into the package.loaded table to see if the library is already loaded: it’s the caching.

Let’s see an example. We want to load imgui.lua lib (stored in {GeeXLab folder}/libs/lua/). The quick way to load this Lua file is:

local lib_dir = gh_utils.get_lib_dir()
dofile(lib_dir .. "lua/imgui.lua")

Now the same thing but using require:

local lib_dir = gh_utils.get_lib_dir() 		
package.path = package.path .. ";" .. lib_dir .. "lua/?.lua;"
require "imgui"    

require looks into package.path and replace all ? by imgui.

imgui.lua is a Lua file that contains some global variables and functions. Now, if we want to load the following lib (mymodule.lua) stored in the demo folder (at the same level than init.lua or frame.lua):

local mymodule = {}

function mymodule.foo()
    print("Hello World!")
end

function mymodule.hello()
  return "Hello from mymodule!"
end

return mymodule

The code to load this lib would be:

local demo_dir = gh_utils.get_demo_dir() 		
package.path = package.path .. ";" .. demo_dir .. "./?.lua;"
mymodule = require "mymodule"

Remark: Lua needs a proper package.path. Each path in package.path folder must have the same convention about folder separators: either use “/” (Linux and Windows) or “\\” (Windows).
For example:

package.path = package.path .. ";C:\\temp/lua/?lua;"

won’t be appreciated by Lua.

You have to fix it with

package.path = package.path .. ";C:\\temp\\lua\\?lua;"

or

package.path = package.path .. ";C:/temp/lua/?lua;"

 
The demo:

The demo is available in the OpenGL 2.1 demopack here: geexlab-demopack-gl-21/d46-lua-package-require/main.xml

 
References:

• Creating and using Modules
• The require Function
• Lua 5.3: package.loaded

LuaJIT is a Just-In-Time compiler for Lua. It’s actually a special version of Lua that optimizes Lua bytecode and when possible, converts it to machine code (see DynASM). Thanks to LuaJIT, Lua code can be really fast!

LuaJIT support is available in GeeXLab for Windows since version 0.16.1.1 and has been added to Linux in version 0.22.1.0. I also tested LuaJIT on macOS but I didn’t manage to make it work. I will retry later.

I will add LuaJIT support to Raspberry Pi and Tinker Board as soon as possible.

GeeXLab comes with the latest version of Lua which is Lua 5.3.4. On the other hand, the current version of LuaJIT supports Lua 5.1 only. So as long as you use regular Lua code (read compatible with Lua 5.1), everything is perfect and LuaJIT works fine. But if you use some features like bitwise operators (added in Lua 5.3), LuaJIT will generates an compilation error (for that particular case, the Lua Bit Operations Module can help).

Now that you know the limitations of LuaJIT, let’s see how to enable it in GeeXLab. You have to rename two dynamic libraries:

– on Windows, the regular Lua 5.3.4 engine is embedded in the gxl_x{32|64}.dll while the LuaJIT 2.0.5 engine is linked with gxl_x{32|64}_luajit.dll. GeeXLab is linked with gxl_x{32|64}.dll. So take advantage of LuaJIT, just rename gxl_x{32|64}_luajit.dll in gxl_x{32|64}.dll. That’s all.

– same thing on Linux: you have two dynamic libraries in the dylibs/ folders: libgxl_r_linux_x64.so and libgxl_r_linux_x64_luajit.so. Just rename libgxl_r_linux_x64_luajit.so in libgxl_r_linux_x64.so.

Last thing: there is a function in the gh_utils lib that allows to know if the current Lua engine is LuaJIT:

local ret = gh_utils.is_luajit()

For any feedback or bug report, a discussion thread is available HERE.

Almost every new version of GeeXLab brings some new functions in the Lua scripting API. So it can be useful to know if a function is exposed by a particular version of GeeXLab in order to avoid crashes if your demo runs with an older version of GeeXLab.

In Lua, all functions are referenced by a global variable called _G (actually, Lua stores the environment itself in the global variable _G). So if you define a new function in a Lua script like this one:

function test_func1()
  return "Hello!"
end

You can check its presence using _G:

if (_G["test_func1"] ~= nil) then
  print("test_func1 is exposed") 
end

To check whether a GeeXLab function is exposed or not, you have to do a two-step test:
1/ check the presence of the library
2/ check the function name in this library

Let’s see an example with the gh_utils.get_demo_dir() function:

if (_G['gh_utils'] ~= nil) then
  print("gh_utils lib is exposed") 

  if _G['gh_utils']['get_demo_dir'] ~= nil then 
    print("gh_utils.get_demo_dir() is exposed") 
  else
    print("gh_utils.get_demo_dir() is NOT exposed") 
  end
else
    print("gh_utils lib is NOT exposed") 
end

If you have a recent ASUS graphics card (or motherboard), it’s highly probable that your board has some bling-bling LEDs because it’s the trend these last times. The latest GeeXLab 0.18.0.0 comes with ASUS Aura Illumination support. You can control, in Lua or Python, the illumination of all LEDs of your motherboard or your graphics card.

I coded a small demo that allows to change the color of your motherboard or your graphics card. The demo is available in the full code sample pack in the gl-32/asus_aura_led_sdk/ folder.

How to run the demo?

1/ be sure that ASUS Aura software is disabled (OFF) otherwise it will constantly try to restore the color of the graphics card / motherboard / mouse / keyboard / RAM:

2/ download GeeXLab for Windows 32-bit from THIS LINK. The ASUS Aura support is available for Windows 32-bit only and ASUS has no current plan to provide a 64-bit version of its Aura SDK (fortunately you can run GeeXLab win32 on Windows 64-bit without problem).

3/ Unzip GeeXLad and the code sample pack. Launch GeeXLab and drag and drop the demo into GeeXLab. That’s all.

Demo programming details

Here are some details about the programming of new ASUS Aura functions in GeeXLab. ASUS Aura functions are available via the gh_asus_aura library in Lua and Python.

I will limit the explanations to the graphics card. Motherboard programming is similar (see the demo source code).

In an INIT script, add the following lines:

num_gpu_light_ctrl = gh_asus_aura.get_num_gpu_light_ctrl()

for i=0, num_gpu_light_ctrl-1 do
  gh_asus_aura.set_gpu_mode(i, 1) -- Set software mode
end	

An Aura capable device can have one or several light controllers. And each light controller can have one or more LEDs. To enable software programming of the light controllers, we have to change the GPU (or motherboard) mode using gh_asus_aura.set_gpu_mode().

Now you are ready to change the color of the graphics card. If you want to change the color only once, just update them in the INIT script with the following code:

gpu_color = {r=255, g=0, b=0}

for i=0, num_gpu_light_ctrl-1 do
  local num_leds = gh_asus_aura.get_gpu_light_ctrl_num_leds(i)
    
    for j=0, num_leds-1 do
      gh_asus_aura.set_gpu_led_color(i, j, gpu_color.r, gpu_color.g, gpu_color.b)
    end
end

And if you want to change them every frame, just put this code in FRAME script. That’s all.

I used ImGui functions to make the color update ultra easy (gh_imgui.color_picker_rgba()).

Few days ago, I read a cool article about flow fields.

What is a flow field?

A flow field is two-dimensional area where each point has a different value.But these aren’t just random values. A particular point has a particular value and as you move out from that point to neighboring points, you get similar, but gradually changing values. In flow fields, these values are usually interpreted as directions. So if you map your values so they are between 0 and 360, they can be directly used as degrees of direction.

In a word, just think to the position/orientation of iron filings in a magnetic field.

The author of the article has coded its demos in Javascript in a 2D canvas. And with few lines of code like these ones:

for(var x = 0; x < width; x += res) 
{
  for(var y = 0; y < height; y += res) 
  {
    var value = getValue(x, y);
    context.translate(x, y);
    context.rotate(value);
    context.beginPath();
    context.moveTo(0, 0);
    context.lineTo(10, 1);
    context.stroke();
  }
}

he was able to render image like this one:

 
Seeing this image, I wondered how could I render this kind of image with GeeXLab. The answer was simple: using a polyline.

In GeeXLab, a polyline can be seen as a super line. A polyline is a collection of single lines. These lines can be connected or not. In our case we will use the polyline as a set of individual lines. Polylines can be coded using the gh_polyline lib available in Lua and Python.

I already played with polylines in this article.

I coded a GeeXLab demo and I tried to produce a code similar to the Javascript one, with rotate(), moveTo() and lineTo() functions. Here is a code snippet in Lua of the FRAME script:

local w2= winW/2
local h2= winH/2

g_vertex_index = 0

for i=1, g_num_lines do
  local x = random(-w2, w2)
  local y = random(-h2, h2)
  translate(x, y)
  ang = getValue(x, y)
  rotate(ang)	
  moveTo(0, 0)
  lineTo(10, 1)
  stroke()
end	

 
The translate(), rotate(), moveTo() and lineTo() functions are very simple because they only set some variables. The real work takes place in the stroke() function which uses the previous variables to set a new line with gh_polyline.set_vertex_position().

If you look at the source code of the demo, you will find the code of the previous functions:

function translate(x, y)
  g_pivot_point.x = x
  g_pivot_point.y = y
end

function moveTo(x, y)
  g_moveto_point.x = x
  g_moveto_point.y = y
end

function lineTo(x, y)
  g_lineto_point.x = x
  g_lineto_point.y = y
end	

function getValue(x, y)
  local PI = 3.14159
  return (math.sin(x * 0.007 + g_time) + math.sin(y * 0.007 + g_time)) * PI * 0.75
end  

function rotate(angle)
  local s = math.sin(angle)
  local c = math.cos(angle)

  -- translate point back to origin
  g_lineto_point.x = g_lineto_point.x - g_moveto_point.x;
  g_lineto_point.y = g_lineto_point.y - g_moveto_point.y;

  -- rotate point
  local xnew = g_lineto_point.x * c - g_lineto_point.y * s;
  local ynew = g_lineto_point.x * s + g_lineto_point.y * c;

  -- translate point back
  g_lineto_point.x = xnew + g_moveto_point.x;
  g_lineto_point.y = ynew + g_moveto_point.y;
end

function stroke()
  if (g_vertex_index < (g_num_vertices-2)) then
    local x = g_pivot_point.x + g_moveto_point.x
    local y = g_pivot_point.y + g_moveto_point.y
    gh_polyline.set_vertex_position(polyline, g_vertex_index, x, y, 0, 1)
    g_vertex_index = g_vertex_index + 1

    x = g_pivot_point.x + g_lineto_point.x
    y = g_pivot_point.y + g_lineto_point.y
    gh_polyline.set_vertex_position(polyline, g_vertex_index, x, y, 0, 1)
    g_vertex_index = g_vertex_index + 1
  end
end	

 
Once the polyline has been updated, it's rendered with :

gh_object.render(polyline)

 
You can find the demo (available in three versions) in the full code sample pack in the gl-21/flow-fields/ folder. This demo requires GeeXLab 0.17.4.1 because the demo_v3 calls a new function that sets vertex position and color at the same time: gh_polyline.set_vertex_position_color().

Here are a video and some screenshots:

gl-21/flow-fields/demo_v3/

 
gl-21/flow-fields/demo_v1/

I had the opportunity to test Logitech RGB LED lighting functions on the Proteus Spectrum mouse, which is a nice laser gaming mouse.

Here is a code snippet in Lua that shows how to change the color of the G logo:

--
-- "rgb" : mouse
-- "perkey_rgb" : keyboard
--
gh_logiled.set_target("rgb") 

gh_logiled.set_lighting(0, 100, 0) -- full green

 
and the result:

GeeXLab 0.13.0 comes with a new set of functions to deal with all of the LED backlighting and RGB capabilities of Logitech G products.

Thanks to this support, every owner of a Logitech G product can easily control the RGB lighting of its device.

The new set of functions (on Windows only) is available in Lua and Python and the documentation is available here: gh_logiled.

I tested this new lib on the unique Logitech G device I own that supports LED backlighting: the G810 Orion keyboard.

Demo – animated red color on F1..F12 keys

 
The use of the gh_logiled is simple. To set the same RGB color to all keys, just call set_lighting():

r = 100
g = 0
b = 0
gh_logiled.set_lighting(r, g, b)

 
100 is the max value. The white color is {R=100, G=100, B=100}. The red color is {R=100, G=0, B=0} and so on.

To set the color of a particular key, just call set_key_lighting():

local lib_dir = gh_utils.get_scripting_libs_dir()
dofile(lib_dir .. "lua/logitech_led_sdk_codes.lua")

key_code = LOGILED_A
gh_logiled.set_key_lighting(key_code, 0, 100, 0)

 
In Lua, the definition of all keys is available here: {GeeXLab folder}/libs/lua/logitech_led_sdk_codes.lua file. This file can be easily ported to Python if needed.

The following functions allow to play some hard-coded lighting effects:
– flash effect:

gh_logiled.set_flash_lighting(100, 50, 50,   5000, 500)

– pulse effect:

gh_logiled.set_pulse_lighting(100, 0, 10,   5000, 500)

 
If you wish to stop all effects and restore original colors, just call:

gh_logiled.stop_effects()

 
When GeeXLab is stopped, the original colors are automatically restored.

I said that gh_logiled can be used to control the RGB lighting of any compatible Logitech G products. But a keyboard with its numerous keys is different from a mouse. So to target a particular Logitech G device, there is a function:

gh_logiled.set_target(target) 

 
target can be "perkey_rgb" for the keyboard or "rgb" for the mouse. To target the keyboard and the mouse, just call gh_logiled.set_target() like this:

gh_logiled.set_target("perkey_rgb | rgb")

 
By default, the target is the keyboard.

I prepared two demos that show how to play with Logitech LED illumination functions. These demos are available in the gl-32/logitech_led_sdk/ folder of the code sample pack.

GeeXLab 0.12.1 comes with a new framework for OpenGL and Vulkan demos. This Lua framework has been created in order to have a common solution to display statistics (FPS, frame time, GPU usage, etc) in any GL/VK demo.

The kx framework is available in GeeXLab Lua libs folder: {GeeXLab folder}/libs/lua/framework_v1/.

In its current version, kx does not support OpenGL ES and Direct3D 12 demos. This support will be added later.

Let’s see how to use it in all kind of scripts. The following code snippets can be found in the samples provided in the framework folder (sample_opengl.xml and sample_vulkan.xml).

1/ INIT script

local lib_dir = gh_utils.get_scripting_libs_dir() 		
local framework_dir = lib_dir .. "lua/framework_v1/"
dofile(framework_dir .. "kx.lua") 

kx_init_begin(framework_dir)
----------------------------------------------------
-- Put your init code here





----------------------------------------------------
kx_init_end()

2/ FRAME script

kx_frame_begin(0.2, 0.2, 0.2)
kx_check_input()
local elapsed_time = kx_gettime()
----------------------------------------------------
-- Put your frame code here



kx_write_text(20, 60 + 20*math.sin(elapsed_time*2.0), 1.0, 1.0, 0.0, 1.0, "The kx framework is kool!!!")




----------------------------------------------------
local show_osi = kx_get_osi_state()
kx_frame_end(show_osi)

 
The kx_check_input() function checks the I and P keys. The I key toggles the display of all information (you can retrieve this state with kx_get_osi_state()). The P key toggles the animation (the elapsed time -kx_gettime()- is no longer updated). The default keys can be changed with kx_set_time_animation_toggle_key() and kx_set_osi_toggle_key() functions.

3/ SIZE script

kx_resize()

4/ TERMINATE script

kx_terminate()

sample_opengl.xml

 
sample_vulkan.xml

 
The main title (in the bottom-left corner) can be changed:

kx_set_main_title("My Kool OpenGL Demo")

 
If you don’t need a title:

kx_set_main_title("") -- no main title...

 
And if a function does not do what you want, just hack the kx.lua file…