Josh

That seems like a pretty reasonable price, if you have a finished game and are ready to publish.

Maybe. This is the kind of optimization you can't really predict ahead of time. You just have to start using the system, find the bottlenecks that arise, and then solve them. The best part of this is you get proper six-sided point light shadows, at a cost that is similar to hacks like the dual parobaloid technique, without the visual errors.

DXTC3 might be the same as DXTC5, with a 1-bit alpha channel. Not sure, though. Don't ever use DXTC1, the compression artifacts are awful.

If this does indeed work, the Lua commands don't need to be declared at all in the header.

I think a sci-fi version would be even cooler. You could have laser beams that appear between two points you set, turrets, mines, blast doors, etc: http://www.youtube.com/watch?v=4B4-nCVwMbA

This tutorial is an in depth explanation of our Lua implementation: http://www.leadwerks.com/files/Tutorials/Lua/Getting_Started_With_Lua.pdf

Just comment them out of the header and try it.

Crouching behavior will be included in 2.31. It will detect whether the player can stand up or not, so it will be 100% good and usable.

In theory. The C++ instance of the Lua library might have some memory allocation it uses that is separate from the engine's instance of Lua, so I am not sure it would work. If the end user can just use the engine's Lua state with their own initialization of Lua, that would certainly be the most straightforward approach.

The entire Lua API is not exposed in the DLL yet. Eventually it will be. I have just wrapped one function at a time as they are needed. You can retrieve the engine's global lua state variable. I am not sure if a separate instance of Lua you initialize yourself will work with that Lua state, but it's worth trying. If not, the entire Lua API will eventually be exposed..

I think we can all agree that yes this is needed, and yes it will be awesome.

I like it. Here's a tip for making videos: When you are recording a video, you often feel under pressure to move the view around, because you are worried the viewer will get bored looking at the same thing. But when you go back and watch the movie later, you wish the camera would just stay in one place so you can focus on what you are watching. That's what I have found, from recording lots of movies.

I am not aware of any memory leaks. If you find one, please let me know.

What's wrong with local networking? That's how I would do it. I think some OSs won't even let you use shared memory hacks. You can also use the command line and console output, if it is a start/stop kind of operation.

SetBlend().

One surface using one texture is faster than four surfaces using four textures. However, I don't think there is any significant difference, and you should use whatever makes things easier for you. I can't imagine it would be easy trying to make a big image containing all your different textures.

Inno setup is good and highly customizable.

Directional lights usually have to be recalculated every single frame, because the camera is usually in motion. One technique I want to try with directional lights is one of those skewing techniques. They are glitchier than cascaded shadow maps, but if something with reasonable results can be implemented, it will only require one render of the scene, instead of the three that CSM requires.

In Leadwerks Engine 2.3, two rendering paths are used for point lights. One uses a depth cubemap (for shader model 4 hardware). The SM3 fallback uses an unwrapped cubemap on a flat texture. On SM4 hardware, a depth cubemap was used because it allowed a point light to be rendered in one pass. However, when implementing my double-buffered technique for point lights, some problems arose. As a result, I changed the renderer to draw point lights as a series of six pyramidal volumes. This is how S.T.A.L.K.E.R. drew point lights, at least in Clear Sky. There was also a problem with NVidia cards not being able to read from a color cubemap unless it had mipmaps. Think for a moment about that, and you can probably guess where I am going with this... Now SM3 and 4 cards will use the same render routine for rendering point lights. SM3 hardware may be a bit faster, because the unwrapped flat cubemap texture coordinates took a lot of logic to figure out, but I don't think it will make any significant difference either way. I talked earlier about separating geometry into "static" and "dynamic" objects, and how the engine gained massive savings by only redrawing dynamic objects, unless otherwise needed. I took the concept a bit further, and decided to allow a light to cast shadows from static or dynamic geometry, or both. Consider the image below. The fan is in motion, but only about 1000 shadow polys have to be drawn to update the shadow: The large spot light projected through the fan blades is the dominant light, but the point light above the fan also casts shadows. If you look carefully, you may notice the oildrum in the foreground is not casting a shadow from the point light. The point light is set to only cast shadows from static geometry, so it never has to be redrawn (unless you move a static object in the editor). Because there are more dominant lights in the area, the viewer probably won't notice this technical error. This allows you place extra point or spot lights throughout a scene to create more detailed static lighting. The shadows will never be redrawn, and you can use them together with fully dynamic lights to create more lighting detail, without the cost of rendering more shadows.

or... require("scripts/class") local class=CreateClass(...) function class:CreateObject(model) local object=self.super:CreateObject(model) object.model:SetCollisionType(COLLISION_PROP) end

There is no official support for Python. However, I think some people have used Python with our engine. I recommend you look into Lua, as it is easy to use and effective.

This is a forum for discussing Leadwerks Engine.

Use Curve(), and have a lower threshold for the minimum distance the step can be.

Normally you think of baked lighting as, you have a long processing step that is done before the game runs, then you display the results and it is fast. You think of dynamic lighting as, okay, it will be slow because it has to update each frame, but it looks good. It's interesting that our approach has turned into, "display the results each frame, and only update it when it is absolutely necessary".

You can create a 2-triangle mesh (a quad) and use an alpha-masked material. The "sprite" will even cast shadows on the ground. Alternatively, you can simply draw the image on the screen with DrawImage().