nick.ace

No, it's a deferred renderer, so it does a few things: It calculates the depth, normal, and color of the final fragments in the scene and places them in buffers (basically renders each of those into an image). A lighting shader is then used to calculate the lighting. This operates on each fragment. You can think of the lighting shader as a post-processing effect to some extent. A fragment consists of primarily: depth value, normal vector, and color value. It does not contain the UV. And this is the same regardless of whether a model is static or animated.

Those benchmarks are completely irrelevant: 1. They are testing on computationally expensive algorithms, not games. Those benchmarks aren't even labelled as gaming related benchmarks. As far as I know, using Haskell for gaming would be a horrible idea! 2. They are likely not using a LuaJIT compiler. Of course a scripting language is going to be slower without caching the results. Even comments will contribute to speed loss at that point. If Lua were so slow, why do AAA games use it? Here's a benchmark for LuaJIT: http://luajit.org/performance_x86.html 3. Lua in Leadwerks (and any reasonable game engine that uses Lua) used compiled functions from the API, so even the computationally expensive parts (like pathfinding) are only going to be negligibly slower since you are effectively calling the same piece of code as you would in C++. Also, I don't think anyone is saying that he's wrong to do something. A lot of us have a lot of programming experience and have seen people struggle trying to learn things a certain way and don't want newcomers to make the same mistakes.

I love the presentation and art direction! It honestly looks like a AAA or high quality indie game in it's current state. And the mechanics in general seem to be very polished along with the menu. Is it possible to automatically select the native resolution though at startup (unless otherwise specified)? My monitor flickers and causes all open windows to readjust, which gets kind of annoying. Maybe add some feedback as well to dragging items onto things like the campfire. I didn't really know at the time what would and wouldn't work. Looking really good though! Can't wait to see future updates!

Rick is an expert in Lua and trains people in Lua, so his advice is very valuable! I'm experienced in C/C++, but I use Lua about 99% of the time with Leadwerks. It's so much simpler and quicker to get things done and tested. Waiting for your program to compile only to see seg faults appearing isn't the most pleasant thing in the world. Handling strings and other more complex objects can also be a pain. Plus, it's easy to just attach Lua scripts to entities in the editor. If you are really interested in game dev, then starting with OpenGL might be kind of tricky (which is why people buy engines in the first place). To completely understand it, you need to have a good foundation in linear algebra, a decent knowledge of GPU architecture, and an understanding of advanced programming concepts (such as precision errors). In terms of C differing from C++, C++ is somewhat a superset of C, meaning that C code will run when compiled with a C++ compiler. OpenGL being written in C shouldn't matter, but I think the reason to teach it in C is because C++ features aren't really necessary for OpenGL. You are welcome to use C++ if you want though, and it'll probably scale better as you develop a larger OpenGL program and start using a bunch of shaders and VAOs. Classes are simpler to manage that structs with function pointers imo. There are other useful features besides classes with C++, and usually compilers are a little less stringent on C++ syntax because the standard is more forgiving. BTW, what is your background in programming? Jumping straight into C/C++ isn't usually recommended for beginners.

EDIT: Sorry Rick! I keep responding while you're responding! Oh, sorry. I misread that! You can still use an array without pointers though for an n x m matrix. It's relatively trivial to do. Every odd row could have m-1 elements, whereas each even row would have m elements. Just make a macro function (to avoid a function call) for each depending on the row, for example: topLeft=[n-1,m-1] for even row, [n-1,m] for odd row left=[n,m-1] for both Yeah, use A*. If you have a destination in mind, then A* will be faster because you use a heuristic to first estimate the shortest path and then actually do the calculations. Djikstra just computes everything in the area, which is very inefficient. I would hope that the view frustum culling is done before sending data to the GPU. If that is the case, you will be gaining nothing by animating like that, and it would even hurt performance (not by much though) if the characters already have scripts. You should just animate in the character's script.

Don't use Djikstra's. That algorithm is good for some things, but pathfinding in games is not one of them. It'll be way too slow. The run time complexities are of different magnitudes. A 35% use rate is not enough to warrant a sparse matrix imo. If you are concerned with space, these can help: Avoid a Vec3 in the struct. Use floats instead or make another struct of floats. The Vec3 class has a bunch of overhead. Storing pointers is worse than storing a 3D array. The array gives you neighbors automatically, but adding up to 26 pointers to cover all directions will cost you more. It looks like you are using a pointer graph rather than an adjacency list.0 Space for storing graph the way you are doing: 0.35 * 25,000 * (12 bytes for position + 26 * 8 byte addresses on a 64-bit machine) = 1.8 MB Space with just a 3D array: 1.0 * 25,000 * (6 levels) = 0.143 MB That's a huge difference in savings! Of course, if you have too much extra information per struct, you could just have a pointer to another struct of class with extra information. Also, using a bunch of pointers the way you are using them is bad for spacial locality, meaning that you are going to be getting a lot more cache misses, so it could slow down your program. You also would have to deference a bunch of objects which would cause even more memory lookups. In the future, other possible solutions could be to have pointers between levels, so it would be a 1D array of 2D arrays. This could be useful if each level is a different size.

This is approach is even easier imo. Just use SetKeyValue on the enemies and the player to label them as something. Also, label the bullet so that it has an owner. Then, when you are testing for collisions, you will know what you hit.

What FPS are you getting? I think the directional light is causing a performance hit, which means that you are essentially running into the bullet because it doesn't move in time. The bullet is an entity itself so you can have this issue.

I know there aren't shadows. BTW, I don't think Minecraft does shadow rendering or lighting at all. It seems to use some sort of neighborhood analysis (kind of like SSAO) to determine the lighting, which is really cheap. I thought each box was an entity until i reread your description. That means you have 256 unique entities though. That's a lot of unique entities. It's possible every frame 256 entities are coming from CPU to the GPU. You're going to run out of bandwidth at a certain point by doing that since you aren't taking advantage of instancing. I might not be right on this being the issue though.

Ok I see what you are doing. If you are using that many entities, I think you are going to have performance issues regardless. Also, I wouldn't consider 150 FPS low, especially for this type of scene. I mean, you are using a huge number of blocks and still getting that framerate. It would probably be the shadows that cause the biggest slowdown.

No, not at all. You could render scenes with millions of triangles provided you use a lot of instancing and are smart about it. Could you post the scene so we could take a look at it?

No, that's how the renderer is built. More geometry is actually what deferred renderers are good at computing. That, and a lot of lights. Deferred renders perform poorly on weak hardware because of the amount of VRAM they use. In fact, the time complexity of a deferred renderer is fairly good in comparison with forward rendering: http://gamedevelopment.tutsplus.com/articles/forward-rendering-vs-deferred-rendering--gamedev-12342 Actually, on second thought, you can kind of turn off the deferred renderer, but you can't disable the render targets, so I don't think you would get any performance gain unless the lighting shader is poorly optimized.

Hitboxes are unrelated. You would literally just make a bigger hitbox. I don't think I follow. If you are talking about the physics shape of the character controller, there are a few things you could do. One is to attach a physics shape to the controller, but this might get glitchy. Also, if it is larger than before, then the character won't be able to use pathfinding easily. You could make your own pathfinding solution, but that can be challenging if you are new to programming.

Why would it be any slower? There are many benchmarks showing substantial improvement speeds (50-90%). That's not true at all. I just looked at the spec. There is a vast amount of new material. Examples: -You couldn't multithread with OpenGL rendering, but there are ways to do it with commands listed in the current Vulkan spec. -You can assign things to individual cards. So now you could do VRAM stacking if you wanted in SLI. There should be many other uses for this too. -Compute shaders. Yes this is in 4.3, but Leadwerks right now is 4.0. -Precompiled shaders. I imagine this would improve game start-up time. Unless the drivers are magically screwed up to the point that they are functionless, I can't see how you would have worse performance. Are there any specifics as to why you think this would be the case?

Yeah you can put it in crouch mode as a cassius said. But that's about it. Let's say you have a door frame in a game. The character controller might be around 6 feet. If you have a monster that was 12 feet tall, then how do you compute the navmesh? Do you choose the largest controller? What if you want the player to be able to hide or go through smaller areas? That's the problem with this. You could make the argument though that the navmesh be generated like it is now and then have the developer deal with it.

Yeah but I think people want automatic terrain generation. Painting terrain by hand takes forever and doesn't look that natural usually.

Yeah, I guess that's true. It just seems really strange how different the sales are for Workshop stuff vs. DLC. I imagine the other stuff must be doing worse?

There seem to be artists willing to put stuff on the Workshop, and that would avoid the whole sunk cost completely. Are you thinking of closing the paid Workshop completely? I'm just wondering if there are substantial maintenance costs there as well.

I actually wrote a converter from PNGs a while back to Leadwerks heightmaps. Leadwerks does indeed use a (somewhat standard) heightmap, it's just that it has 16-bit precision instead of the 8-bit precision of a heightmap. Raiseland says it'll export to 16-bit .raw, so it should work. It looks like Roland already did it: http://steamcommunity.com/app/388820/discussions/0/541907867787316651/#c541907867787665898

Thanks! Those tutorials you wrote are super helpful! I kind of wish I saw them earlier because those are some of the best tutorials I've seen on the subject. Btw, I actually got it working yesterday. I guess I thought there was more control you could have over the shaders than just the number of subdivisions you could have and how you want the subdivisions to behave (to an extent). I was able to make shattering windows because of it lol.

It's not editable because of the navmesh. The navmesh generation actually uses the character controller dimensions to compute. It would be nice though to have the option to change it and maybe make multiple navmeshes or at least have control over what dimensions are used for advanced users.

Thanks! I found a link at the bottom of the page that explained it better. I didn't know what the outer and inner tess levels were and how they are used. I'm not interested in doing dynamic tesselation right now, but maybe I'll implement that later.

Yes, you would need an animated (or at the very least rigged) mesh. I static mesh isn't going to be very useful for this. You don't need to recode anything. You just need to call FindChild() to get a reference of them in code and set the position and rotation of each of them to the corresponding ragdoll you made in the video. The model will still be allowed to animate, you just need to not set set the position or rotation while it's doing this.

Does anyone know how to write tesselation shaders? I looked at the example, and was able to integrate it with my custom shader, but the control and evaluation shaders from diffuse-normal-specular-tess.shader doesn't really seem to do anything. I want to be able to take a triangle and subdivide it into an arbitrary amount of triangles. There seems to be a lack of tutorials online for tesselation shaders .

Yeah sure. You need to call FindChild() from your mesh, and that function takes in a string where you can specify a bone. This bone is an entity, so you can call SetPosition() and SetRotation() on it to the position and rotation of the joints of the ragdoll (GetPosition() and GetRotation()). Make sure you set the global flag to true though. You should be all set with this, but it'll end up being a lot of copy/pasting code since you have to do this with each joint.