Lunarovich

When created, every entity script starts with a code like this: --[[ function Script:Start() end ]]-- --[[ function Script:UpdateWorld() end ]]-- --[[ function Script:UpdatePhysics() end ]]-- -- etc. Now, according to PIL, a common trick to comment out a block of code goes like this --[[ print(10) -- no action (comment) --]] If we add a hyphen to the first comment line, we get this: ---[[ print(10) --> 10 --]] Unfortunately, with a LE current default comment, we cannot do this. That's because the author of the default script was thinkng of Lua comments in the vein of C++ /* and */, which is, however, a wrong approach, since Lua comments do not function in that way. So, if you add a hyphen, you'll get this: ---[[ function Script:Start() end ]]-- --[[ function Script:UpdateWorld() end ]]-- --[[ function Script:UpdatePhysics() end ]]-- -- etc. and that's obviously unwanted and error-generating result, since Lua does not know what to do with ]] part of the ]]--. So, please correct this, so we can quickly comment out entity functions. Thanks.

I would like to download docs myself in an official package. For now, you'll have to use an internet site downloading tool. Those come with a possibility to restrict a depth level of downloaded links as well to restrict the download to the domain in question. The easiest thing would be, in my opinion, to start from the API index and simply download one level depth links. If you are using Linux, then wget is an excellent tool to do that. Otherwise, you can try this nice tool for Firefox.

An object script as a class concept does alleviate a need to use classes extensively. What I like about LE is the fact that, unlike Unity for example, you can have a script which is totally unrelated to any game object. What is more, you can "import" or "require" it from Main.lua script or from any object script. That said and if you keep in mind that in Lua functions are first-class citizens, you can hava a simple table of useful functions and dynamically assign them or remove them from entities via "self.entity.func_name = global_table_name.func_name" or "self.entity.func_name = nil". That's quite a duck typing, kind a strange to c++ only users, but it's a great technique for game development, IMO. In this way you can have a "multi-class" entity or make entity dynamically change class. Really neat, if you ask me

Just as the title says, I would like to be able to use those two functions in Lua. For now, I have to use undocumented Buffer methods (plus Context:Plot) in order to draw on a texture, and I would like to use only documented things. Thank you!

You're welcome! Just for the record, in order to "require 'middleclass'", as specified in docs/tutorial on github, you'll have to uncheck "lua sandbox" in the options.

In fact, according to this chapter in PIL, Lua is designed explicitely to cater for classes creation. The point is, Lua gives you the tools to create classes and lets you design the class system to your likings. Situation is somewhat similar as in JS (as far as I know prototype-based languages). You could try this excellent Lua class implementation. Of course, there are other implementations as well...

I agree with this one totally. As far as I can see, LE users are more or less computer graphics savvys that like to do things in a simple way. This things include low level as well as high level aspects. An LE is nice because you can do low level and high level model or texture manipulation. For me, this is the most important aspect of LE and a reason I'm using it. Another nice thing is that a swinging door, for example, does not come as a black box, but as a model with a script attached - a script that you can read and modify to your likings. My point is that something like a swinging door is not built into LE. Rather, it's easily constructed thanks to LE's design. OK, sorry for not talking about PBR and SD. An SD support would be a really nice thing and would not harm the aforementioned design principles. On the other hand, for people that want rather simple but powerful way to create procedural textures, there is an excellent free NeoTextureEdit. Unfortunatelly, it seems to be no longer developed. Nevertheless, I use it all the time for my textures.

Well, I understand and approve the idea to go for the simplicity and the most common use cases (the post-processing, here). However, I like LE precisely because it manages to couple simplicity with generality. A vertex manipulation (normals, uvs), for example, gives us a low level access to the mesh and empowers us to do wonderful things with a procedural geometry. And yet, it's very simple to use. Likewise, I use buffers for procedural textures. I generate a texture directly in a custom shader (insted of using Context's Plot function) and render it to the buffer. For example: -- Save the ref to the current shader & buffer. local context = Context:GetCurrent() local defaultShader = context:GetShader() local defaultBuffer = Buffer:GetCurrent() -- Specify a TEXTURE size. local textureSize = 128 -- Although we can use Context::Plot, -- we rather use the custom SHADER to draw a texture in the GPU. local customShader = Shader:Load("Scripts/Custom/drawimage.shader") -- Create a custom BUFFER to draw a texture to. -- static Buffer* Create(const int width, const int height, const int colorcomponents=1, -- const int depthbuffer=1, const int multisamplemode=0);//lua local customBuffer = Buffer:Create(textureSize, textureSize, 1, 1) Buffer:SetCurrent(customBuffer) -- must be called after Buffer:SetCurrent() context:SetShader(customShader) -- DRAW the texture and store it in the local variable. --context:SetBlendMode(Blend.Alpha) local texture = customBuffer:GetColorTexture(0) context:DrawImage(texture, 0, 0) -- Restore previous buffer and shader. Buffer:SetCurrent(defaultBuffer) context:SetShader(defaultShader) I would be very disappointed to see the possibility to do something like this removed, only because the use of buffers was meant as a hack to enable post-processing. For me, the possiblity to directly manipulate buffers is as essential as a possiblity to directly manipulate vertices.

Thanks. Just for the reference, here is the offical doc on FBOs. While we're at it, I find the use of FBOs one of the top features of LE. Is the absence of official docs the sign that the feature or its interface might change, or is it just a question of priorities?

A quick question: does LE Buffer class refers to/wraps this OpenGL object (Renderbuffer object). Thanx.

Emacs has quite steep learning curve. I've been using it for various purposes for years now. If you want some quick and decent solution, I can only recommend Atom.io It's a modular editor based on package system. There is a nice package for Lua (you install it from the editor) which does syntax highlighting and auto-indentation. There are also packages for auto-completion and similar programming necessities.

You got right. I am kind of stupefied by this data:

Thanks. Since OSX consumes a large part of the market, it would be a wise decision to add an export as soon as possible.

Sorry to bump this up, but I can't find nowhere a clear answer to this question: Is it possible to publish a game for Mac OS X at the moment? As far as I can see, it was possible to do it before. But can I do it now, with a current LE version?

I'm using Emacs. With settings that I've made, I have the following features: Auto-complete. I've added a custom-made dictionary file with LE classes and methods. Lua snippeting. I've made several snippeting templates - for generic loops, method definitions, etc. Syntax highlighting and auto-indentation. The latter is very, very useful: it's enforced and you can easily detect missing construct parts. On the fly syntax error checking - so that even before running a LE game, I can tell if there is anything obviously wrong with my code. Plus, in the opposite window, I'm always keeping open a Lua console, so I can easily test various LUA constructs I'm not sure about.

Agree. I'm making some procedural textures ATM. It would be impossible to do such a thing without the use of buffers. And being able to do procedural textures is a top priority for me ATM.

I vote for this one. We definitely need buffer docs!

Thanks! That was quite helpful. I suppose that somewhere down the pipeline we convert materialflags back to bit mask by multiplying it with 255.

Thanks. That makes things a bit simpler. Anyway, I'm still curious about all those lines of code, so an explanation or hint would be appreciated. I'm currently compiling my own notes in regards to how one uses shaders in LE. Maybe I'll put them on blog here, as a newbie guide someday.

Leadwerks recently changed the way the application starts. The entry point of the game was App.lua. Now it's Main.lua. API doc does not yet reflect that change and continues to give examples using App.lua. That said, you can simply create an App.lua (named exactly that way) script in Scripts folder (should be exactly in that folder) and copy paste examples from API doc pages. They should work instantly. Namely, if LE finds App.lua, it treats it as an entry point for your game, for the backwards combatibility sake. Anyway, create App.lua file, copy paste example in it and you should be fine for now. You can tweak the examples in order to understand better how LE works. Hope that helps...

Thanks for this clarification. Then again, models shouldn't be selected by default... And their selection state should not be reflected in any way during the runtime... Anyway, in the default shader, for example, in the vertex part, I see these lines: ex_selectionstate = 0.0; if (vColor.a<-5.0) { vColor.a += 10.0; ex_selectionstate = 1.0; } As far as I can see, the alpha value of the entitymatrix[3][3] (I refer to the entity.matrix[gl_InstanceID]) encodes the selection state of the object. Am I right? I mean, vColor.a is fed with value via vColor=vec4(entitymatrix[0][3],entitymatrix[1][3],entitymatrix[2][3],entitymatrix[3][3]); So, here comes the puzzling part. If this value is less than -5, than we add 10 to this value. Why do we want to change it? I see that ex_selection "boolean" gets the value of 1, which I understand (or I think I understand). Anyway, in the fragment part of the shader, one can read this: int materialflags=1; if (ex_selectionstate>0.0) materialflags += 2; fragData2 = vec4(0.0,0.0,0.0,materialflags/255.0); According to this post, material flag 1 stands for ligthing enabled and 2 stands for decals enabled (reserved; btw, why reserved? what does it mean?). So, if we add 2, material flag will be 3. What does it mean for materialflags to be 3? And finally, if we divide materialflags by 255, even when it's 3, we'll have a value so small that it is barely (if at all) visible to the human eye. What's the point in all this?

Thank you! Finally, the problem was in fragData2. Here is a version of the fragment shader that gives correct results: #version 400 // Outputs out vec4 fragData0; out vec4 fragData2; void main() { fragData0 = vec4(0.0, 1.0, 1.0, 1.0); fragData2 = vec4(0.0,0.0,0.0,0.0); } According to this post, fragData1 stands for normals and specularity, and fragData2 encodes emissivity and something called material flags. As far as I can see it, my material was, for some reason unknown to me, emitting the red "light". I've turned it off by setting every value of fragData2 to 0.0. I've made some tests with fragData2 and it does affect the final color of the model. What I see as a design flaw is this: if you do not specify some color value and material needs it for some reason, the default value should be set to no particular value (black in our case) or to some neutral value (white, in the case of tinting, for example). The default value should not be some idiosyncratic color like red.

As far as I know, there are no hidden docs here. The site has been undergoing significant changes lately. That's why there are some dead links.

Hello! I have this minimalistic quad model: local model = Model:Create() local surface = model:AddSurface() surface:AddVertex(-0.5,-0.5,0, 0,0,-1, 0,0) surface:AddVertex(0.5,-0.5,0, 0,0,-1, 1,0) surface:AddVertex(0.5,0.5,0, 0,0,-1, 1,1) surface:AddVertex(-0.5,0.5,0, 0,0,-1, 0,1) surface:AddTriangle(2,1,0) surface:AddTriangle(0,3,2) surface:UpdateAABB() model:UpdateAABB(Entity.LocalAABB) model:UpdateAABB(Entity.GlobalAABB) In order to shade it, I create a simple material and give it my custom minimalistic shader. Here is the vertex shader #version 400 #define MAX_INSTANCES 256 //Uniforms uniform instancematrices { mat4 matrix[MAX_INSTANCES];} entity; uniform mat4 projectioncameramatrix; //Attributes in vec3 vertex_position; void main() { mat4 entitymatrix = entity.matrix[gl_InstanceID]; mat4 entitymatrix_ = entitymatrix; entitymatrix_[0][3]=0.0; entitymatrix_[1][3]=0.0; entitymatrix_[2][3]=0.0; entitymatrix_[3][3]=1.0; vec4 modelvertexposition = entitymatrix_ * vec4(vertex_position, 1.0); gl_Position = projectioncameramatrix * modelvertexposition; } And here is the fragment shader #version 400 // Outputs out vec4 fragData0; void main() { fragData0 = vec4(0.0, 0.0, 0.0, 1.0); } Now, you should notice that I do not give any special color to the model, material or vertices, and that I set fragData0 to black, so normally, it should be black (and since the background is black also, it should be invisible in this particular case). However, it is red: If I change the relevant line of code to, e.g. fragData0 = vec4(0.0, 1.0, 0.0, 1.0); I get a greenish mix of green and red: Or with fragData0 = vec4(0.0, 0.0, 1.0, 1.0); I get purple, as expected... How can I get rid of this basic red tint? Why is it there in the first place? Thank you!

Ok, here it is, an absolutely minimal model shader... It will output a green geometry... Vertex shader: #version 400 #define MAX_INSTANCES 256 //Uniforms uniform instancematrices { mat4 matrix[MAX_INSTANCES];} entity; uniform mat4 projectioncameramatrix; //Attributes in vec3 vertex_position; void main() { mat4 entitymatrix = entity.matrix[gl_InstanceID]; mat4 entitymatrix_ =entitymatrix; entitymatrix_[0][3]=0.0; entitymatrix_[1][3]=0.0; entitymatrix_[2][3]=0.0; entitymatrix_[3][3]=1.0; vec4 modelvertexposition = entitymatrix_ * vec4(vertex_position,1.0); gl_Position = projectioncameramatrix * modelvertexposition; } Fragment shader: #version 400 // Outputs out vec4 fragData0; out vec4 fragData2; void main() { fragData0 = vec4(0.0, 1.0, 0.0, 0.0); fragData2 = vec4(0.0, 0.0, 0.0, 0.0); } For the explanation of attribs, uniforms and inputs/outputs see this link.