Josh

Scripting support is very important in the new engine. The script implementation in the old engine was great for quickly adding animation and simple behavior to objects, but wasn't capable of supporting advanced gameplay. I've put a lot of work into our implementation of Lua script to bring it to a new level. In the old engine, if a script error occurred the program would simply crash. The new engine supports detailed error handling and will automatically open files and show you where an error occurs in a script: You can insert breakpoints in your program with the Debug:Stop() command. When a breakpoint is hit, the program pauses. You can browse all variables running in the virtual machine in the script debug pane. You can even see actual memory addresses of C++ objects in the Lua virtual machine!: Of course, you can also step through your script line by line with code stepping: You can modify object scripts, and when you hit F5 the current scene will be saved and loaded in your project. The editor launches the game as an external executable, you don't have to worry about messing up your editing session, and you can even debug the virtual machine in C++ programs. This makes the editor stable and solid, and game iteration is still very fast. By focusing on improved Lua support and really digging into the details of the language, I hope we can provide a scripting environment that is very capable and pleasant to use.

There are cell phones on the market right now that have more graphics power than your PC. Just get this: http://www.newegg.co...N82E16814130534

Use the "lua" forum tag for Lua syntax highlighting: --[[------------------------------------------------------------ This is a block of comments You can have multiple lines of comments Pretty neat, huh? ------------------------------------------------------------]]-- --This function will be called once when the program starts function App:Start() --Set the application title self.title="Darkness Awaits" --Create settings table and add defaults self.settings={} self.settings.vsync=true --Load the user's settings self:LoadSettings() --Create a window self.window=Window:Create(self.title,0,0,1024,768,Window.Titlebar) --Create the graphics context self.context=Context:Create(self.window,0) if self.context==nil then return false end --Create a world self.world=World:Create() --Create a camera self.camera = Camera:Create() self.camera:SetPosition(0,5,-10) --Load a test scene Scene:Load("Scenes\\trash.scene") return true end --This is our main program loop and will be called continuously until the program ends function App:Continue() --If window has been closed, end the program if self.window:Closed() then return false end --If escape key has been pressed, end the program if self.window:KeyHit(KeyCode.Escape) then return false end --Update the world self.world:Update() --Render the world self.world:Render() --Refresh the screen self.context:Swap(self.settings.vsync) --Returning true tells the main program to keep looping return true end function App:Pause() --Pause time updating Time:Pause() end function App:Resume() --Resume time updating Time:Resume() end function App:Finish() --Save user settings to a file self:SaveSettings() end --Load user settings from a file (not yet implemented) function App:LoadSettings() return true end --Save user settings to a file (not yet implemented) function App:SaveSettings() return true end

Here's the layout for pure Lua applications. This will run on Android, iOS, Windows, and Mac, with no third-party compilers to mess around with. And because it's JIT compiled by the engine itself, it's fast: --This function will be called once when the program starts function App:Start() --Set the application title self.title="Darkness Awaits" --Create settings table and add defaults self.settings={} self.settings.vsync=true --Load the user's settings self:LoadSettings() --Create a window self.window=Window:Create(self.title,0,0,1024,768,Window.Titlebar) --Create the graphics context self.context=Context:Create(self.window,0) if self.context==nil then return false end --Create a world self.world=World:Create() --Create a camera self.camera = Camera:Create() self.camera:SetPosition(0,5,-10) --Load a test scene Scene:Load("Scenes\\trash.scene") return true end --This is our main program loop and will be called continuously until the program ends function App:Continue() --If window has been closed, end the program if self.window:Closed() then return false end --Update the world self.world:Update() --Render the world self.world:Render() --Refresh the screen self.context:Swap(self.settings.vsync) --Returning true tells the main program to keep looping return true end function App:Pause() --Pause time updating Time:Pause() end function App:Resume() --Resume time updating Time:Resume() end function App:Finish() --Save user settings to a file self:SaveSettings() end --Load user settings from a file function App:LoadSettings() return true end --Save user settings to a file function App:SaveSettings() return true end And just for fun, here's the C++ code that makes all the calls to Lua scripts. It's more low-level than you will need to deal with, but it shows how powerful the script command set is: bool App::Start() { Int stacksize = Interpreter::GetStackSize(); //Create New table And assign it To the Global variable "App" Interpreter::NewTable(); Interpreter::SetGlobal("App"); //Invoke the start script If (!Interpreter::ExecuteFile("Scripts\\App.lua")) { Print("Error: Failed to execute\"Scripts\\App.lua\"."); Return False; } //Restore the stack size Interpreter::SetStackSize(stacksize); //Call the App:Start() Function Interpreter::GetGlobal("App"); If (Interpreter::IsTable()) { Interpreter::PushString("Start"); Interpreter::GetTable(); If (Interpreter::IsFunction()) { Interpreter::PushValue(-2);//Push the app table onto the stack as "self" If (!Interpreter::Invoke(1,1)) Return False; If (Interpreter::IsBool()) { If (!Interpreter::ToBool()) Return False; } Else { Return False; } } } //Restore the stack size Interpreter::SetStackSize(stacksize); Return True; } bool App::Continue() { //Get the stack size Int stacksize = Interpreter::GetStackSize(); //Call the App:Start() Function Interpreter::GetGlobal("App"); If (Interpreter::IsTable()) { Interpreter::PushString("Continue"); Interpreter::GetTable(); If (Interpreter::IsFunction()) { Interpreter::PushValue(-2);//Push the app table onto the stack as "self" If (!Interpreter::Invoke(1,1)) { Print("Error: Script function App:Continue() was not successfully invoked."); Return False; } If (Interpreter::IsBool()) { If (!Interpreter::ToBool()) { Return False; } } Else { Return False; } } Else { Print("Error: App:Continue() function not found."); Return False; } } Else { Print("Error: App table not found."); Return False; } //Restore the stack size Interpreter::SetStackSize(stacksize); Return True; } void App::Pause() { //Get the stack size Int stacksize = Interpreter::GetStackSize(); //Call the App:Start() Function Interpreter::GetGlobal("App"); If (Interpreter::IsTable()) { Interpreter::PushString("Pause"); Interpreter::GetTable(); If (Interpreter::IsFunction()) { Interpreter::PushValue(-2);//Push the app table onto the stack as "self" If (!Interpreter::Invoke(1)) { Print("Error: Failed to invoke script function App:Pause()"); Return; } } } //Restore the stack size Interpreter::SetStackSize(stacksize); } void App::Finish() { //Get the stack size Int stacksize = Interpreter::GetStackSize(); //Call the App:Finish() Function Interpreter::GetGlobal("App"); If (Interpreter::IsTable()) { Interpreter::PushString("Finish"); Interpreter::GetTable(); If (Interpreter::IsFunction()) { Interpreter::PushValue(-2);//Push the app table onto the stack as "self" If (!Interpreter::Invoke(1)) { Print("Error: Failed to invoke script function App:Finish()"); Return; } } } //Restore the stack size Interpreter::SetStackSize(stacksize); }

If I can make it work, 3 will use a variation of "megatextures" for terrain.

The problem is the two builds did not use the same debug runtime library. It works fine now, thanks.

I compiled Leadwerks into a VS static lib and included it in another VS project. When I simply call this in the main program, the program prints the string, but then a buffer overrun error occurs. Any ideas why this could be happening?: Print("Hello, world!"); The code works fine if I run it in a project that compiles source files instead of using a static lib.

We're getting to a point where we need to establish the final directory structure for the new game engine, and start using it. Here's what you see when you open "C:\Leadwerks" (or on Mac, "\Applications\Leadwerks"): The "Editor" folder contains the editor executable and support files. The "Engine" folder contains header files, compiles libraries, and BlitzMax include files. The "Help" directory contains local help files. The "Projects" directory is where your projects go, by default. Our development project is called "Darkness Awaits". Here's what the directory structure looks like: We think this design will keep things clean and organized, and be nice to work with.

I wish I knew, but this is the first time anyone has reported behavior like this.

I use a base Object class called "Object" and have a virtual function on the object class called "ToString". Then each derived class can have its own variation.

What's funny is we moved the default install directory out of "Program Files" for precisely this reason.

I threw down some quick zombie AI. This has a Zombie::Create() static function, and then you would just call Zombie::UpdateAll() function once per frame: zombieAI.zip It won't compile as-is but may provide a basis for your AI.

If the platform is moving with physics and has a velocity, that velocity should be transferred to the character.

There is code in the engine that specifically handles the case you are showing and adds velocity to the character. Not sure why it's not working in your video.

Does this expose the Leadwerks command set to script?

The casting in the previous example was actually unnecessary. Here's a better example I will try out tomorrow: Script.target = nil--Entity Script.distance = 10--float Script.radius = 0.5--float Script.smoothness = 0.5--float --This script will make a camera follow any entity function Script:RenderWorld() --Make sure the target entity exists if self.target~=nil then --Get the target entity's position, in global coordinates local p0 = self.target:GetPosition(true) --Calculate a second point by backing up the camera away from the first point local p1 = p0 + Transform::Normal(0,0,-1,self.entity,nil) * distance --Perform a raycast to see if the ray hits anything local pick = self.entity.world:Raycast(p0,p1,self.radius) if (pick~=nil) then --If anything was hit, modify the camera position p1 = pick.position end --Set the camera position in global coordinates local currentpos = self.entity:GetPosition(true) if self.smoothness>0 then p1.x = Math:Curve(currentpos.x,p1.x,self.smoothness) p1.y = Math:Curve(currentpos.y,p1.y,self.smoothness) p1.z = Math:Curve(currentpos.z,p1.z,self.smoothness) end self.entity:SetPosition(p1,true) end end

Here's a sample script: Script.movement=Vec3(0)--Vec3 "Player movement" function Script:Attach() print("Calling Attach() function") end function Script:Update() local player = tolua.cast(self.entity,"Player")-- cast Entity to Player class if player~=nil then player:SetInput(0,1) end end

His file should work as it is.

The detail texture layers can be blended with the base texture. Also, there is an option in the DDS converter that fades mipmaps so terrain textures will look less repetitive in the distance.

Hmm, I ran this through GMFDump and the vertex count for four surfaces is 65536, which should be the maximum number: http://www.leadwerks...le/358-gmfdump/ FILE Data starts at: 12 { 12 - Version: 1 MESH Data starts at: 28 { 28 - Matrix: 1.00000000, 0.000000000, 0.000000000, 0.000000000 0.000000000, 1.00000000, 0.000000000, 0.000000000 0.000000000, 0.000000000, 1.00000000, 0.000000000 0.000000000, 0.000000000, 0.000000000, 1.00000000 PROPERTIES Data starts at: 104 { 104 - Keys: 1 108 - Keyname: name 113 - Keyvalue: U3D_STATIC_MESH } SURFACE Data starts at: 141 { PROPERTIES Data starts at: 153 { 153 - Keys: 1 157 - Keyname: material 166 - Keyvalue: } VERTEXARRAY Data starts at: 179 { 179 - Vertices: 65536 183 - Data type: 1 187 - Variable type: 8 191 - Elements: 3 } VERTEXARRAY Data starts at: 786639 { 786639 - Vertices: 65536 786643 - Data type: 2 786647 - Variable type: 8 786651 - Elements: 3 } VERTEXARRAY Data starts at: 1573099 { 1573099 - Vertices: 65536 1573103 - Data type: 3 1573107 - Variable type: 8 1573111 - Elements: 2 } VERTEXARRAY Data starts at: 2097415 { 2097415 - Vertices: 65536 2097419 - Data type: 5 2097423 - Variable type: 8 2097427 - Elements: 3 } VERTEXARRAY Data starts at: 2883875 { 2883875 - Vertices: 65536 2883879 - Data type: 6 2883883 - Variable type: 8 2883887 - Elements: 3 } INDICEARRAY Data starts at: 3670335 { 3670335 - Indices: 390150 3670339 - Mode: 7 3670343 - Variable type: 7 } } } }

Right, but the next step is an actual HTML-based GUI. So it's not a complete solution at all, just an extra step that might lead to a solution.

I agree completely. However, I think if we simply add a command set for creating buttons, sliders, etc. the next request will be a visual designer built into the editor. Then we'll be in the position of having to go back and redo something, because we didn't do it right the first time.

I'm of the opinion that every feature we add needs to be really well thought out, and really well done. I'd rather wait on this so we can come up with something that really meets the need well.

http://www.leadwerks...dwerks-engine-2 Yes, but it's cheaper overall to buy LE2 now and then upgrade. Yes.

We're getting close. I'm trying to focus on three things with the first release of the new engine: -Support for gameplay mechanics (script system, flowgraph, integrated pathfinding) -Really good editor (built-in level design tools, easy art pipeline) -Multiplatform support (Launching for four platforms on day one) There will be some features LE2 has that the new engine initially lacks, but I already know how to do them, and they are planned for further down the road. We're progressing in the order it makes sense to develop.