Einlander

Check if to see if it has sync(true) that's vsync

http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/context/contextsetscale-r728 I wanted to scale my GUI using the setscale command and found some of the drawing commands do not function correctly. The drawrect command works properly. The plot command does not scale at all. The line command does not work properly in straight lines horizontally or vertically, but it does diagonally. Hear is code to test and explain: --This function will be called once when the program starts function App:Start() --Initialize Steamworks (optional) --Steamworks:Initialize() --Set the application title self.title="MyGame" --Create a window local windowstyle = window.Titlebar if System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+window.FullScreen end self.window=Window:Create(self.title,0,0,System:GetProperty("screenwidth","1024"),System:GetProperty("screenheight","768"),windowstyle) --Create the graphics context self.context=Context:Create(self.window,0) if self.context==nil then return false end return true end --This is our main program loop and will be called continuously until the program ends function App:Loop() --If window has been closed, end the program if self.window:Closed() or self.window:KeyDown(Key.Escape) then return false end --Update the app timing Time:Update() self.context:SetScale(2,2) -- everything should be twice as big self.context:SetColor(self:rgbatovec4scalar({255,255,255},255)) self.context:DrawRect(0,0,200,200) -- This is the size the line squares should be at self.context:SetColor(self:rgbatovec4scalar({100,100,100},255)) for y = 1 , 200 do -- this should make a solid square, not rectangle self.context:DrawLine(5, y , 205, y ) -- draw square at an offset so you can see its dimensions in a relative manner end self.context:SetColor(self:rgbatovec4scalar({80,100,100},10)) for x = 5 , 205 do -- this should make a solid square also self.context:DrawLine(x, 5 , x, 205 ) -- draw square at an offset so you can see its dimensions in a relative manner end self.context:SetColor(self:rgbatovec4scalar({255,0,0},255)) self.context:DrawLine(0,0,200,200) -- the line is off from actuall 0,0 by a few pixels but it is the size self.context:SetColor(self:rgbatovec4scalar({0,255,0},255)) self.context:Plot(200,200) -- this should actually be at the edge of the white box but its at real cordinates 100,100 --Refresh the screen self.context:Sync(true) --Returning true tells the main program to keep looping return true end function App:rgbatovec4scalar(rgb,a) return Vec4(rgb[1]/256,rgb[2]/256,rgb[3]/256,a/256) end As long as this is does not function as intended, my gui will have to be put on the backburner.

I see where the confusion is. I have a class: class "SGUIWindow" That defines the window container. All gui componets have something like this. In each gui component i have a Draw method: function SGUIWindow:Draw() --Draw from bottom to the top --draw window body local WindowDraw = new "SGUIDraw" WindowDraw:PaintPolygon(self.objectshape, self.properties.x, self.properties.y, {self.properties.color.windowbody[1],self.properties.color.windowbody[2],self.properties.color.windowbody[3],self.properties.color.windowtransparancy}) --Draw Window Contents --Draw Window Chrome end This would draw all the window itself. Instead of any of the components calling the leadwerks drawing features, It calls the class SGUIDraw. In SGUIDraw all the drawing is done. To draw a line, I would use this code function SGUIDraw:Line(x1,y1,x2,y2,ColorAsRGBATable) --In Leadwerks to not inturupt the set modes you need to remember it, change it, then set it back --This method should not cause any problems in other engines local TempContext = Context:GetCurrent() local tempblendmode = TempContext:GetBlendMode() local oldcolor = SGUIDraw:GetCurrentColor() SGUIDraw:SetColor(ColorAsRGBATable) TempContext:DrawLine(x1,y1,x2,y2) SGUIDraw:SetColor(Vec4(oldcolor.r,oldcolor.g,oldcolor.b,255)) end If I were to move this to another engine that would be the only function that I would change. So to condense it all, Each gui object is a class, that has its own self draw method, which uses an abstracted drawing command, which is mapped to the engines drawing command.

It's been a while since I last posted an update on my lua based GUI. That was the second time that I have rewrote it. Now I'm on my third rewrite. This time the reason is that I am using the Lua OOP module Averice has made available. My GUI was already object oriented but it was messy to code. Now it looks sensible and has much less code. I have no pretty images to show but I will detail some of the major structural changes and concepts that i have employed. I no longer use the require keyword. I use the import command now since it plays better with the lua sandbox and can be used in the workshop games Window Manager Changes If you have followed the development of this gui, you may already know that there is a window manager that controls all the states of the windows. This was so that programmers can have multiple window managers that have different interfaces (think game menu gui, and in-game computer interfaces). Now there a window manager manager (collect all the things!). This allows the programmer to have a system that will manager and update all of the window managers autonomously if they so choose. Drawing Before, each component (windows, buttons, etc..), did their own drawing. This was fine for the most part, but this limited me to the Leadwerks line and box command. Now I use 2d polygons to allow me to draw whatever shape I want to. There is an almost negligible performance hit, since it has to process the shape and scan-line draw the image. This will also allow me to use the point in polygon algorithm to select items, creating the possibility of selecting non square objects with the mouse. Abstraction Along with changing the drawing, I have abstracted all drawing to a single class. This class contains all the drawing and text commands that the gui uses. This makes the gui more portable and if Leadwerks changes something there will only be one location to change them instead of multiple places. The rewrite should take substantially less time, and with the new class system adding components should be easier and faster.

While coding my lua GUI I found that I needed to be able to fill many 2d polygons. After looking at quite a few algorithms (I am very bad at math), I found one created in lua and felt that I needed to share. It was converted from the Corona lua which was in turn converted from PSP lua. I have modified it to work without change in Leadwerks See here for examples on how it works: http://forums.coronalabs.com/topic/8084-drawing-a-polygon-with-a-fill/ function rgbatovec4scalar(rgb,a) return Vec4(rgb[1]/256,rgb[2]/256,rgb[3]/256,a/256) end function paintPoly(poly, xoffset, yoffset, rgba) -- [url="http://forums.coronalabs.com/topic/8084-drawing-a-polygon-with-a-fill/"]http://forums.coronalabs.com/topic/8084-drawing-a-polygon-with-a-fill/[/url] local math_floor = math.floor local math_min = math.min local math_max = math.max local polyGroup = {} local n = table.getn(poly) local minY = poly[1].y local maxY = poly[1].y for i = 2, n do minY = math_min(minY, poly[i].y) maxY = math_max(maxY, poly[i].y) end for y = minY, maxY do local ints = {} local int = 0 local last = n for i = 1, n do local y1 = poly[last].y local y2 = poly[i].y if y1 < y2 then local x1 = poly[last].x local x2 = poly[i].x if (y >= y1) and (y < y2) then int = int + 1 ints[int] = math_floor((y - y1) * (x2 - x1) / (y2 - y1) + x1) end elseif y1 > y2 then local x1 = poly[last].x local x2 = poly[i].x if (y >= y2) and (y < y1) then int = int + 1 ints[int] = math_floor((y - y2) * (x1 - x2) / (y1 - y2) + x2) end end last = i end local i = 1 while i < int do polyfillcontex = Context:GetCurrent() polyfillcontex:SetColor(rgbatovec4scalar(rgba,rgba[4])) polyfillcontex:DrawLine(ints[i] + xoffset, y + yoffset, ints[i + 1] + xoffset, y + yoffset) i = i + 2 end end return polyGroup end

any chance we can see it in action in a video?

Don't forget the vita, ps4 and xbox one all support Unity.

Create a 1 meter cube in leadwerks. Export as obj, import to 3ds. Then figure out the scale. If memory serves me, you need to scale up by 1000 to get to meters. Read post below.

This is an awesome script. Is there a way to make all the classes local to the lua file instead of maintaining a global list of classes?

This drives me crazy too. And I know under what conditions it happens too. If it is a single mesh with a named root node. Leadwerks will preserve the name. If it has any hierarchy it will give it a different name. It gets worse when you mass import models and you need to rename everything.

Is this the problem you are having? http://www.leadwerks.com/werkspace/topic/10060-errors-loading-fbx-with-embedded-textures/

Um, Tesseract does have GI. It's in the video on the site and in the text under the video. "The new rendering features include fully dynamic omnidirectional shadows, global illumination, HDR lighting, deferred shading, morphological/temporal/multisample anti-aliasing, and much more." PBR is still new so very few engines have it.

How does it work when you set it to debris?

Also take a look at the tesseract engine or it's fork Octaforge for the version that supports lua. Tesseract has everything real time.

Does this work in lua?

So far it looks like an Nvida issue. Anyone on AMD card having this issue?

I totally forgot that the import command plays better with the Leadwerks lua sandbox than require. I need to recode a few things now.

In the Leadwerks editor it use to have the bottom console visible by default or hidden if you hide it. Now its always hidden when you load the editor regardless of what you set it at previously. Many times I start the editor and load my map and miss all the red text telling me things are potentially wrong. I would request an option or the ability to keep the position of the editor console constant between sessions.

root mass to 0 and object mass to .1. The engine still exhibits drag/friction with no gravity. Things set in motion eventually stop, you may seg fault or run out of space before it does though. You can check this out by making in a flat surface to walk on, a prop with weight, and the fps creator. Set the gravity to 0 and walk into a movable object. it will move and eventually stop. You can walk off your walking surface and you will not fall off. Oddly you can still walk around without ground.

That fix is fine to get the window working, but if you have dark levels, its a no go.

Congratulations!

This is beautiful!

Leadwerks does not seem to load the repeated textures in fbx files. Since your uv is simple I remade it. BuroGeb1.zip

Do you mind posting the .shade file here? I have Shade 3d 14 and can take a look at it.

This would need a better script editor than we currently have. One that is capable of understanding variables strings and resources.