Josh

A mesh oriented to face the camera.

Add UpdateAppTime() to the loop.

Edit the particle vertex shader so rotation is not used. I am not sure why you are using an emitter for this, though. In version 2.31, the particle velocities will be sent to the vertex shader. This could be used to orient the particles in the direction they are moving, for sparks and things like that.

-Add your normal map and specular map to the material. There are lots of examples in the SDK of materials with a bumpmap. -Disable bloom and HDR. -Use a darker ambient light color.

For that particular scene, a nav mesh might be overkill. I do want to integrate the recast library into the engine, but it's definitely not necessary for something like this.

Version 5 files use twice as many bytes per pixel, so they have higher resolution / less lossiness.

The framework class should detect the resolution change automatically and recreate the buffers on its own.

That game is fun but extremely annoying. They don't give you enough money or time to build anything effective.

Do NOT use DXT1, ever!

That's exactly what we're doing. We have the ability to add various feeds into the html pages, so the whole site will be more interactive and interesting.

Increase the camera near range.

No, you would not have enough video memory or texture bandwidth. Directional lights are very specialized because you cannot possibly make a texture big enough to shade the whole scene, with a decent resolution. The whole challenge of directional lights is to use more pixels in the foreground and fewer in the background. The two main ways of doing this are to have several renders of the scene at different resolutions, or to render the shadow with a skewed matrix that uses more pixels closer to the camera. There's little I can do to optimize directional lights, as they are very much a brute force technique. Far Cry 2 seems to use a skewing technique that doesn't seem to have visual errors, but of course they are going to go to great lengths to hide any errors their technique produces by not using certain sun angles. If I can devise a decent skewing technique, it could mean one shadow render of the scene instead of three, but I am not sure I have ever seen an error-free implementation. Yes, but you have some additional options that will produce real time shadows at virtually no cost.

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.