Rick

I wonder if this sort of opens up a new world in voxel type games.

Would it be possible to simulate the world physics without OpenGL? Would be nice for multiplayer games that need to run on a server that doesn't have a gfx card.

If you removed the word immediate then I don't agree with this statement. Nothing is immediate we all know that, that technology supporting the growth of an ecosystem is a technology problem. One of the reasons FB got really popular is because they created a way to make FB apps. They created a technical way to support an ecosystem. It's a mindset of "If you build it, they will come". If you give a technically sound way to extend things then those 2.5% innovators will build your engine for you (to some extent). In my view it's a waste of your time to build templates. Let the 2.5% innovators do this for you. BUT, they need a standard way of doing this and they need your support and promotion (no technical needs here really just promotion stuff) of those things to gain credibility to the other groups. What could be an example of what you'd do around this? Well how about a more dynamic template system when someone creates a new game. That screen should be reading from some place online to list the templates available instead of local machine. There should be an official and community section of templates at the point of creating a new project. We should be then given a streamline way to create & publish these templates. When you create a means to do something officially, people create stuff for that. In my view your 2.5% innovators are an extension of any company. Often they are free labor because they do things out of love and learning and not profit. You've generally not empowered those 2.5% innovators for a fear of giving up some control I would think. The innovators have been marginalized because they are all doing things their own way and get no promotion or help from a framework that guides how things should be done and how users access their work. This is all about technology. This is about standard systems of game template creation/promotion and plugin type systems and standard ways to hook into LE. All which don't exist. In my view Leadwerks selling point is it's simplicity. Period. Performance just has to be there and be competitive. It's a must have, not a selling point. Leadwerks attracts noobs because it's simple to use compared to the competition. *Disclaimer: The above was just my opinion. I'm just acting as a sounding board

The current state of the Main.lua is pretty bloated honestly. It's strange Josh says he likes the simplistic one when the current one has a ton of other stuff in it. I generally comment out/delete/change the current one to my liking. I guess nothing prevents me from doing the hook idea. I'll try that out. It's just always nice when there is a general hook system so ideas/systems can be easily shared between people. That's where I go with this stuff. We still have a harder time sharing systems between each other because of this. If I have a system that needs an update and a 2D drawing part and an init sections, explaining where to put those in Main.lua is kind of a pain and could be harder for a new person. Explaining where to put them in defined hooks is a little cleaner. The LE ecosystem is still the wild west. While there are good things about that, in my view there are more bad things about that. Unity's ecosystem is simply amazing. I'm not saying their product is good, I'm saying they've created a great ecosystem and their app store reflects this. It's much easier for programmers to create systems for others to use because they have a solid structure for that. They make design decisions to support that idea. LE does not and that's reflected in the limited workshop items and if most of them even work today without some getting into the details to configure/change to make them run. In my view when you create a good ecosystem it keeps people on your platform. It's why Windows wins vs Linux in the desktop world. Much better and more user friendly ecosystem. Little to no fiddling around to get some driver to work. These are reasons why "hooks" are important. Until that idea is introduced into LE, it'll always be the wild west and devs basically create their games from the ground up. Which as we see isn't that easy because of the amount of time and knowledge required to do so for a lot of different systems. @AggrorJorn as you're seeing I'm sure there is little incentive to create some kind of system or framework to help people. Trying to integrate such things without any sort of help from the LE platform makes it difficult to integrate into everyone's projects. From a business perspective having an ecosystem/platform is what every software company tires to do these days. Every system in Unity's app store helps expand Unity at no cost to Unity itself. Being a 1 man show in LE, Josh I would think you would want this because it basically outsources work for you. You can then pick the good ones to integrate into LE if you so decide. However, it's a feeling of losing control. I get that.

Except no game closes on pressing the escape key and games need ways to set the window size and do UI updating/drawing and other game loop stuff specific to the game that you can't think of. It's nice to look at the simplicity of this but this can't be used for any real game without modification which then gets into the issue at hand. On a side note it's even easier when we don't have to see the game setup and loop and just have a handful of functions that get called.

Yeah that's true. The hook stuff should be there just for simplicity sake but not for this reason. I agree no lua files should be updated when updating a project. New projects should use the updated files though.

OK, we used this in urWorld game. Below is the code you need to manipulate the images. It's an example. In this example we had a shape of a human body as the border of the progressbar and I think it had another image as the filler. I've also included the shaders you need to have too. if BodyTemp ~= nil then return end import "Scripts/UI/UI.lua" BodyTemp = {} function BodyTemp:Create(actor, OnFreezingTick) local obj = {} obj.thermBg = Texture:Load("Materials/UI/Gameplay/stat_background.tex") obj.thermMask = Texture:Load("Materials/UI/Gameplay/stat_fill_mask.tex") obj.thermFill = Texture:Load("Materials/UI/Gameplay/stat_fill.tex") obj.thermOl = Texture:Load("Materials/UI/Gameplay/stat_border.tex") obj.thermIc = Texture:Load("Materials/UI/Gameplay/stat_icon_bodyTemp.tex") obj.thermFill:SetClampMode(true, true) obj.maskShader = Shader:Load("Shaders/Drawing/gui.shader") obj.drawShader = Shader:Load("Shaders/Drawing/drawimage.shader") obj.name = "Body Temp Stat" obj.max = 100 --obj.bodyTemp = obj.max obj.bodyTemp = 10 obj.bodyTempCheckInterval = 2500 obj.bodyTempLastInterval = Time:GetCurrent() obj.owner = actor obj.OnFreezingTick = OnFreezingTick --obj.x = 5 --obj.y = 4 obj.x = 0.0100 obj.y = -0.177 obj.ratio = obj.thermMask:GetHeight() / obj.thermMask:GetWidth() --obj.width = 48 --obj.height = obj.width * obj.ratio obj.width = 0.0700 obj.height = 0.1650 obj.anchor = ui.Anchors.BottomLeft obj.freezingInterval = 5000 obj.lastFreezingTick = 0 local k,v for k,v in pairs(BodyTemp) do obj[k] = v end return obj end function BodyTemp:Increase(value, source) self.bodyTemp = self.bodyTemp + value self.bodyTemp = Math:Min(100, self.bodyTemp) self.bodyTemp = Math:Max(0, self.bodyTemp) end function BodyTemp:Decrease(value) self.bodyTemp = self.bodyTemp - value self.bodyTemp = Math:Min(100, self.bodyTemp) self.bodyTemp = Math:Max(0, self.bodyTemp) end function BodyTemp:Update() if self.bodyTemp > 0 then if Time:GetCurrent() >= self.bodyTempCheckInterval + self.bodyTempLastInterval then self.bodyTempLastInterval = Time:GetCurrent() self:Decrease(1) end self.lastFreezingTick = Time:GetCurrent() end if self.bodyTemp == 0 then if Time:GetCurrent() >= self.freezingInterval + self.lastFreezingTick then self.lastFreezingTick = Time:GetCurrent() self.OnFreezingTick(self.owner) end end -- for pos/scale --if Window:GetCurrent():MouseDown(2) then -- if ui.pointOverElement(self) then -- ui.selectElement(self) -- end --end end function BodyTemp:Draw(context) context:SetBlendMode(Blend.Alpha) local pos = ui.getPosition(self) local scale = ui.getScale(self) context:SetShader(self.drawShader) context:SetColor(1, 1, 1, 1) context:DrawImage(self.thermBg, pos.x, pos.y, scale.width, scale.height) context:SetColor(1, 1, 1, (self.bodyTemp / self.max)) context:SetShader(self.maskShader) self.thermFill:Bind(1) context:DrawImage(self.thermMask, pos.x, pos.y, scale.width, scale.height) context:SetColor(1, 1, 1, 1) context:DrawImage(self.thermOl, pos.x, pos.y, scale.width, scale.height) context:DrawImage(self.thermIc, pos.x, pos.y, scale.width, scale.height) --[[ context:SetShader(self.drawShader) context:SetColor(1, 1, 1, 1) context:DrawImage(self.thermBg, self.x, context:GetHeight() - self.height - self.y, self.width, self.height) context:SetColor(1, 1, 1, (self.bodyTemp / self.max)) context:SetShader(self.maskShader) self.thermFill:Bind(1) context:DrawImage(self.thermMask, self.x, context:GetHeight() - self.height- self.y, self.width, self.height) context:SetColor(1, 1, 1, 1) context:DrawImage(self.thermOl, self.x, context:GetHeight() - self.height - self.y, self.width, self.height) context:DrawImage(self.thermIc, self.x, context:GetHeight() - self.height - self.y, self.width, self.height) ]] context:SetColor(Vec4(1)) context:SetBlendMode(Blend.Solid) end Shader (drawimage shader might already be part of LE and I don't think it changed but including it anyway): gui.shader SHADER version 1 @OpenGL2.Vertex #version 400 uniform mat4 projectionmatrix; uniform mat4 drawmatrix; uniform vec2 offset; uniform vec2 position[4]; uniform vec2 texcoords[4]; in vec3 vertex_position; in vec2 vertex_texcoords0; out vec2 vTexCoords0; void main(void) { gl_Position = projectionmatrix * (drawmatrix * vec4(position[gl_VertexID], 0.0, 1.0)); vTexCoords0 = texcoords[gl_VertexID]; } @OpenGLES2.Vertex @OpenGLES2.Fragment @OpenGL4.Vertex #version 400 uniform mat4 projectionmatrix; uniform mat4 drawmatrix; uniform vec2 offset; uniform vec2 position[4]; uniform vec2 texcoords[4]; in vec3 vertex_position; in vec2 vertex_texcoords0; out vec2 vTexCoords0; void main(void) { gl_Position = projectionmatrix * (drawmatrix * vec4(position[gl_VertexID], 0.0, 1.0)); vTexCoords0 = texcoords[gl_VertexID]; } @OpenGL4.Fragment #version 400 uniform vec4 drawcolor; uniform sampler2D texture0; uniform sampler2D texture1; in vec2 vTexCoords0; out vec4 fragData0; void main(void) { vec4 gui=texture(texture0,vTexCoords0); if (gui.r == 0. && gui.a > 0.) { gui.a = 0; gui = texture(texture1,vTexCoords0); if (1-drawcolor.a > vTexCoords0.y) gui.a=0; } fragData0 = gui; } drawimage.shader SHADER version 1 @OpenGL2.Vertex #version 400 uniform mat4 projectionmatrix; uniform mat4 drawmatrix; uniform vec2 offset; uniform vec2 position[4]; uniform vec2 texcoords[4]; in vec3 vertex_position; in vec2 vertex_texcoords0; out vec2 vTexCoords0; void main(void) { gl_Position = projectionmatrix * (drawmatrix * vec4(position[gl_VertexID], 0.0, 1.0)); vTexCoords0 = texcoords[gl_VertexID]; } @OpenGLES2.Vertex @OpenGLES2.Fragment @OpenGL4.Vertex #version 400 uniform mat4 projectionmatrix; uniform mat4 drawmatrix; uniform vec2 offset; uniform vec2 position[4]; uniform vec2 texcoords[4]; in vec3 vertex_position; in vec2 vertex_texcoords0; out vec2 vTexCoords0; void main(void) { gl_Position = projectionmatrix * (drawmatrix * vec4(position[gl_VertexID], 0.0, 1.0)); vTexCoords0 = texcoords[gl_VertexID]; } @OpenGL4.Fragment #version 400 uniform vec4 drawcolor; uniform sampler2D texture0; in vec2 vTexCoords0; out vec4 fragData0; void main(void) { fragData0 = drawcolor * texture(texture0,vTexCoords0); } I should really add this to the workshop and get more formal with it for people to easily use it. Maybe I'll do that this weekend.

There is a shader somewhere that helps aid in this I think. I don't think it's part of LE but might be able to find it by searching on the forums. Your green part in the image above would obviously be a rectangle (since all images are rectangle) but the shader would use a mask to define where the green part should be visible. Shadmar might have created it. I've used it some time ago. That really should be part of the LE engine itself because this is pretty common task in games.

Main.lua is pretty brute force honestly. It should be setup to have callbacks at certain points (like Gonan mentions) and then the idea being we never actually touch Main.lua but instead work in the lua callbacks for our personal code. Include a Game.lua at the top of Main.lua and have that be where we define these callback functions. If we wish to make changes that have to do with the main loop we can do it in these. It's probably cleaner for new people as well to do custom things in this file vs Main.lua. This would allow us to hook into the main loop without changing Main.lua and having update issues. Each function should be checked for nil in Main.lua and not called or defaults provided if it's expecting a return result. This would future proof it and allow more hooks to exist over time and not crash if they aren't provided. The idea then is Leadwerks never updates Game.lua. We as the developer own it 100%. If we want to take the risk of changing Main.lua we still can, else we just use these hooks. There would probably be more than these functions but the basics would be: -- something like this that returns an object that configures the window function WindowConfig() return { x = 0, y = 0, width = 800, height = 600 } end -- after the window/context/etc are setup function InitGame() end function UpdateGame() end function PostRenderGame() end -- we define how to end the game function EndGame() return false end

In an ideal world when we decide to update it would show us any conflicts (like source control) and we get to decide what to do.

Looks like variadic templates is what you're looking for? https://stackoverflow.com/questions/1579719/variable-number-of-parameters-in-function-in-c You could use macros. You could create Instruction1<T>, Instruction2<T,A>, Instruction3<T,A,S> etc etc With modern compilers using std:function might be the way to store function pointers vs the old way.

That's interesting. Wasn't aware you have to create a pre-processor. That could for sure work then. I'd use something like Destroy() or Delete() though as Reset() makes it seem like it'll go back to the values it had on map load (which might be a cool side feature to have actually).

Wow I didn’t know those details. Much respect as that took massive courage to do!

Isn't buying it from steam the only option these days?

Yes, that would be an issue. I would expect there is 1 shared pointer per actual pointer but if it doesn't work that way then this wouldn't work. The question is does that cause other issues too? It will be interesting to see if posts happen around this entire shared pointer idea on the lua side. Example showing 2 shared pointers pointing to the same underlying pointer and how reset on 1 shared pointer doesn't affect the other. http://cpp.sh/7y4sp

-- script 1 enemy.health = enemy.health - 1 if enemy.health <= 0 then Destroy(enemy) enemy = nil end -- script 2 if Exists(self.target) then self.target:Hurt(50) end This is how I would want to handle it. Exists() is a C++ function checking the shared pointer if it's valid or not. I have my opinions on which one would be easier to explain to a user. At this point I think my opinion is out there so I'll stop on this specific point.

In the script where you set the variable to nil you don't have to do an Exists() check just a simple nil check because in that script that variable is already nil. This only happens in the situation where the user shared the object between scripts. That's the point where you have to check if the object still exists or not because any of the scripts that may have access to it could have deleted it. Is that not a simple concept? It's something we wish we had in LE4 and have talked about getting it before but there was no solution this simple because of the way pointers were handled. Shared pointers gives that simple solution! Yet I don't think setting to nil and calling collectgarbage() does solve the issue. If I have a model object shared between 2 scripts and one sets it's variable to it to nil and calls collectgarbage() does the other one not still have it because it did a copy operation when it assigned it to it's local variable. That would have created 2 counts of the shared pointer so it would still stay alive would it not? Think about the tower defense situation. One tower thought it killed the enemy unit but it really didn't because the other tower still had a reference to it so it stays alive. Doesn't sound like the desired behavior in that situation or really any situation where this can happen in a game. If the fear is a user forgets to call Exists(obj) and the game crashes (again you should have checks in all calls I think) then that same fear exists today and we've dealt with it for a long time. At least with the Exists() function we have a way to deal with it that doesn't require jumping through hoops we have to do now to get this desired behavior. I personally think explaining garbage collecting to users is more complicated given that in the scenario I posted above the garbage collecting wouldn't actually delete the object because another script had a reference to it.

The real benefit you're getting though is the ability to do an if check on the smart pointer to see if it really exists or not because everything created is shared between the users code and the internal engine and you want to avoid crashes like what happens today in LE4. Smart pointers are doing great at that but they now have this side effect of keeping things around when us users don't want them around anymore. I don't get why having a Delete() and Exists()/IsValid()/whatever is a problem to fix the issue. Seems fairly logical doesn't it? Just trying to better understand why you and the other github guy don't think so unless he doesn't understand the context in which you're using his library since most things aren't as visual as a game engine where it probably doesn't matter if the thing hangs around.

This is why I mentioned the Exists() c++ function. When you reset the shared pointer you’re doing this on the c++ side of things. So you’ll probably need to check on the c++ side of things if it’s valid. So our checks on lua would be to pass our reference to the Exists() to see if that shared pointer is still valid or not. The other approach is you checking if it’s valid in all calls of using it which is probably the way to go to prevent crashes but more work for you. Not sure if that creates a side effect of the user wondering why calls aren’t doing anything so still having the Exists() function is recommended. Think of the Exists(obj) function as the if == nil check. It gives us a way to validate if the shared pointer is valid or not on objects that may be shared between scripts. A feature that in LE 4 we don't have so that's a win right there! Remember the case of the Tower Defense where 2 towers have 1 enemy unit as a target but one kills it before the other but then the other doesn't know this and tries to kill it too and the game crashes currently. We have to do workarounds to avoid that situation. With the above idea we wouldn't have to. We'd simply check if Exists(target) then. We'd only really ever need to use the Exists() function if we know the object is shared between scripts. That doesn't happen on every object we create so it's not as if we need to wrap everything in an Exists() check. 99% of the time we'd just call Reset(obj) obj = nil and be done with it. (Not a fan of the Reset() name though as it doesn't really give a good description of what it's doing from a users standpoint). I just don’t get how deleting something and expecting it to be gone is a bad idea and against user expectations. If I delete something I expect it gone.Thats the entire point of deletion and it’s how le4 works, and any other engine works so that concept itself isn’t against user expectations. I don’t think it’s just visual objects to right? Wouldn’t sounds have the same requirement of stopping before deletion?

I'm saying create this function in Main.lua but it would be cool if from C++ one could actually set the obj passed into the function to nil so that Lua will see it as nil. You'd have to think that's possible some way which would be nice. function Delete(obj) Reset(obj) obj = nil end

Maybe create a Delete() lua function that both calls the c++ Reset() and sets that obj to nil? Kills 2 birds with 1 stone then and is easy for the user. Not sure if there is a use case for calling Reset() without setting the lua side to nil. I wouldn’t think so.

Yeah, to get shared pointers working across language domains he had to wrap it, but just forgot about the object that wraps when the shared pointer should be removed. Makes sense. So he's going to fix it?

So the issue was that binding library which put a wrapper around a shared pointer?

It was just a bug I was trying to figure out as to why you could see them at the start. Just fixed it so now you can't see them at the start anymore and when you move from room to room they do go completely out of view so all good on that front.

The thing I don't like about totally black ambient is losing the top part of the walls. When everything is black those are black too and the walls look paper thin which looks odd. What part specifically are you thinking doesn't work well when you see this in action? Note, there is a roof on these that use the shader that makes it invisible but that's after lighting is applied to that the room is lit correctly and doesn't bleed outside the top of the room. Which is why when ambient is totally black the top of the walls can't be seen either.