Jump to content

Lua and Gui's

Einlander

2,839 views

Gui's at the moment seem to be all the rage on the Leadwerks forum. We have the recent release of the noesisGUI, Patrik's showing of his gui's progress, and tjheldna's release of tjui and probaly many others. I also decided to try my hand at gui creation.

 

Coming from a BASIC background (started with qb 1.0), I don't have the proper skills to use a third party gui without malloc errors or segfaulting everything. That, and my game is a lua game. Taking inspiration from Tjhldna's gui I started off making something similar in pure lua.

 

After 2 days I managed to create a window manager and the windows themselves.

 

It's a good start but a lot of things still need to be worked out.

 

blogentry-7960-0-38843300-1400726325_thumb.gif

!!ANIMATED, CLICK TO VIEW!!

 

 

Frontfacing code to make the demo:

function Script:Start()
-- Load Module
lwgui = require "/scripts/lwgui"

--Create Window Manger
self.windowmanager = lwgui.WindowManager()

--Create Windows
self.window1 = lwgui.Window(200,200,300,300,windowcallback) -- window1 callback
self.window2 = lwgui.Window(280,200,300,300)
self.window3 = lwgui.Window(480,180,300,300)

-- make the window see through
--self.window.SetTransparancy(100)
self.window2.SetTransparancy(100)
--self.window3.SetTransparancy(100)

--self.window.SetCallback(windowcallback) -- you can manually set a callback

self.window1.SetTitle("Einlanders' Leadwerks Gui Window")
self.window2.SetTitle("Einlanders' Leadwerks Gui WIndow 2")
self.window3.SetTitle("Einlanders' Leadwerks Gui WIndow 2")

-- set window color
self.window2.SetWindowBodyColor({0,0,255})
self.window3.SetWindowBodyColor({0,30,0})

--Add Window To Window Manager
self.windowmanager:AddWindow(self.window2)-- type checked 
self.windowmanager:AddWindow(self.window1)-- type checked 
self.windowmanager:AddWindow(self.window3)-- type checked 

--self.window.testwm()

end

function Script:UpdateWorld()
-- update title
self.window1.SetTitle(self.window1.GetX()..":"..self.window1.GetY().." Einlanders' Leadwerks Gui Window:"..self.window1.GetDepth())
self.window2.SetTitle(self.window2.GetX()..":"..self.window2.GetY().." Einlanders' Leadwerks Gui WIndow 2:"..self.window2.GetDepth())
self.window3.SetTitle(self.window3.GetX()..":"..self.window3.GetY().." Einlanders' Leadwerks Gui WIndow 2:"..self.window3.GetDepth())
local window = Window:GetCurrent()
-- remove a window
if window:KeyHit(Key.Q) then
self.windowmanager:RemoveWindow(self.window1)-- type checked 
self.window1 = nil
collectgarbage()
end
end
--This function will be called after the world is rendered, before the screen is refreshed.
--Use this to perform any 2D drawing you want the entity to display.
function Script:PostRender(context)
--process all logic inside the windows and window manager
self.windowmanager.Process()
-- Render all windows
self.windowmanager.Render()
end
function windowcallback(e) -- window 1 callback
System:Print(e[1])
end



5 Comments


Recommended Comments

Looks like a good start! Eventually I will have to tackle GUIs as well and I only have Lua (so I can't use tjheldnas :( ). I will keep track of your progress (if you post updates on this) and learn from your learning!

Share this comment


Link to comment

I would think the following should be in UpdateWorld() instead of PostRender():

 

self.windowmanager.Process()

 

 

When storing the callback you might want to consider allowing for script level functions instead of global functions. In your example windowcallback() is global to the entire game which means if you use a GUI in another script and have the same function you are overwriting the function based on which script was read in first.

 

The way to do this is to first allow your SetCallback() to accept 2 parameters. The first one would be the script object and the second the script function. So usage would look like: SetCallback(self, windowcallback).

 

Then we would define our callback inside these entity scripts like:

 

function Script:windowcallback()

end

 

In your library just store the obj and function in variables. When it's time to call you can call it like:

 

func(obj)

 

This calls the script function and passes the script object. In Lua this is what gives you the 'self' variable (it's hidden and done behind the scenes).

Share this comment


Link to comment

Go to http://www.lua.org/cgi-bin/demo and copy paste the below in and you'll see that it calls the Script level function as the callback.

 

-- this table will store our callback script object and script function
callback = {}
callback.obj = nil
callback.func = nil

-- function like yours to set callback
function SetCallback(obj, func)
  callback.obj = obj
  callback.func = func
end

-- simulate how the scripts work
Script = {}

function Script:Create()
  local obj = {}

  -- this copies the object Script function to this local table
  local k,v
  for k,v in pairs(Script) do
     obj[k] = v
  end

  return obj
end

function Script:Start()
  SetCallback(self, self.MyCallback)
end

-- user defined script level function
function Script:MyCallback()
  print("Inside MyCallback")
end

-- create an instance of this script and call it's Start(). LE does this behind the scene for us but this is just to show
testScript = Script:Create()
testScript:Start()


-- this is how you would call the callback from your library.
callback.func(callback.obj)

Share this comment


Link to comment

Thanks Rick, helped alot. Is the callback script is supposed to change to the modules scope right?

Share this comment


Link to comment

Not sure what you are asking. You would put this callback table inside your GUI library and expose the SetCallback() function from your GUI library as well for us to set what script function we want to assign as the callback. Then when you need to call it from your GUI library you would do that last line of code. That's all you'd really need to do. All the other stuff in there was just an example to show that.

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 0
      A new update is available for beta testers.
      Terrain
      The terrain building API is now available and you can begin working with it, This allows you to construct and modify terrains in pure code. Terrain supports up to 256 materials, each with its own albedo, normal, and displacement maps. Collision and raycasting are currently not supported.
      Fast C++ Builds
      Precompiled headers have been integrated into the example project. The Debug build will compile in about 20 seconds the first run, and compile in just 2-3 seconds thereafter. An example class is included which shows how to add files to your game project for optimum compile times. Even if you edit one of your header files, your game will still compile in just a few seconds in debug mode! Integrating precompiled headers into the engine actually brought the size of the static libraries down significantly, so the download is only about 350 MB now.
      Enums Everywhere
      Integer arguments have been replaced with enum values for window styles, entity bounds, and load flags. This is nice because the C++ compiler has some error checking so you don't do something like this:
      LoadTexture("grass.dds", WINDOW_FULLSCREEN); Operators have been added to allow combining enum values as bitwise flags.
      A new LOAD_DUMP_INFO LoadFlags value has been added which will print out information about loaded files (I need this to debug the GLTF loader!).
      Early Spring Cleaning
      Almost all the pre-processor macros have been removed from the Visual Studio project, with just a couple ones left. Overall the headers and project structure have been massively cleaned up.
    • By Josh in Josh's Dev Blog 6
      An often-requested feature for terrain building commands in Leadwerks 5 is being implemented. Here is my script to create a terrain. This creates a 256 x 256 terrain with one terrain point every meter, and a maximum height of +/- 50 meters:
      --Create terrain local terrain = CreateTerrain(world,256,256) terrain:SetScale(256,100,256) Here is what it looks like:

      A single material layer is then added to the terrain.
      --Add a material layer local mtl = LoadMaterial("Materials/Dirt/dirt01.mat") local layerID = terrain:AddLayer(mtl) We don't have to do anything else to make the material appear because by default the entire terrain is set to use the first layer, if a material is available there:

      Next we will raise a few terrain points.
      --Modify terrain height for x=-5,5 do for y=-5,5 do h = (1 - (math.sqrt(x*x + y*y)) / 5) * 20 terrain:SetElevation(127 + x, 127 + y, h) end end And then we will update the normals for that whole section, all at once. Notice that we specify a larger grid for the normals update, because the terrain points next to the ones we modified will have their normals affected by the change in height of the neighboring pixel.
      --Update normals of modified and neighboring points terrain:UpdateNormals(127 - 6, 127 - 6, 13, 13) Now we have a small hill.

      Next let's add another layer and apply it to terrain points that are on the side of the hill we just created:
      --Add another layer mtl = LoadMaterial("Materials/Rough-rockface1.json") rockLayerID = terrain:AddLayer(mtl) --Apply layer to sides of hill for x=-5,5 do for y=-5,5 do slope = terrain:GetSlope(127 + x, 127 + y) alpha = math.min(slope / 15, 1.0) terrain:SetMaterial(rockLayerID, 127 + x, 127 + y, alpha) end end We could improve the appearance by giving it a more gradual change in the rock layer alpha, but it's okay for now.

      This gives you an idea of the basic terrain building API in Leadwerks 5, and it will serve as the foundation for more advanced terrain features. This will be included in the next beta.
    • By Josh in Josh's Dev Blog 1
      Here are some things I did in the last couple days to fix a computer that was basically unusable.
      It seems that Superfetch was rebranded to "SysMain" in an update and automatically re-enabled. If your computer is grinding away either the CPU or disk usage while doing nothing, this is the culprit. Disable it in Windows services.
      The XBox games bar is suspect. I recommend disabling it now that FRAPS supports Vulkan.
      Some features in Visual Studio are making it unusably slow.
      In Project settings > Link > Debugging, set "Generate Debug Info" to "DEBUG:FASTLINK" (in the debug build only) for faster linking.
      Disable these two settings in the general program Options:
      Enable Diagnostic Tools while debugging Show elapsed time PerfTip while debugging
×
×
  • Create New...