Josh

This issue was recently brought to my attention. It just started occuring due to some optimizations that were made in version 2.31. It has been fixed for version 2.32. You can replace the spotlight with a directional light to see how it should work.

No program should overheat the GPU, ever. The driver should be self-limiting so that the card never gets too hot. I experienced this with some drivers with an nVidia GEForce 9800 GTX. If it continues to be a problem, using Flip(1) can prevent this, but it's really a problem with the driver, and should not be happening. If this does occur, you will know it because the screen will go black and a notification will appear in the system tray saying that the display driver crashed.

It's used for syntax highlighting in the script editor.

The explanation of the lua state refreshing was very good. You don't actually need the scilexer DLL. I would also copy the interpreter debugger (engine.debug.exe). At around 22:30, you did misspell "deferred". This is a really good runthrough of things. A lot of stuff you mention is thing I wouldn't even think to explain, but when you do I can see how it would be useful for someone brand new to game development, or at least to Leadwerks. Nice stuff!

I created a new app and have my status updates syncing. If your account is still associated, you should be able to remove that now.

I don't see any reason the GMF converter would have any problems with that. If Sketchup can export an FBX or Collada file, I don't see any problems.

I recommend using RakNet. It handles everything, and is very extensive.

I'd rather not deal with bug reports for this, but you can post any odd behavior in this thread.

Robin, if you bought the program from this site please email support at leadwerks dot com.

The framework command set is used to create a "framework" that handles bloom and other effects, so you can just switch them on and off.

That's pretty clever, but how would you blur the depth buffer of the particle image? I do like that idea a lot. It makes sense to render the shape of the volume first, and then make it look like particles after.

I don't know how XNA works, but that does not sound like what I am describing.

In the future, I want to implement a feature I am calling "stages". This will allow you to define a stage for an entity or material, and then render a camera one stage at a time, with your own code in between to handle effects. Something like this: camera.BeginRender(); camera.Render(-1);// draw skybox camera.Render(0);// draw main stuff //Do whatever post-processing stuff you want camera.Render(1);// draw transparent objects camera.EndRender(); This would eliminate the need for multiple worlds and multiple camera renders.

Leadwerks has an advanced and highly optimized occlusion system utilizing all the techniques discussed here. The entity rendering routine uses an octree, and the vegetation uses a method so advanced I can't even explain it in words. But it works and it is really fast.

Well, you should use two triangles facing each direction, unless it is a primitive that faces mostly upwards and you want backlighting through the surface.

I don't know if you will have much luck trying to make something that different with our engine. A system like that will be extremely non-optimal for most kinds of games, except for the one type they are making.

That's how Michael makes all his plants and trees. Turn backface culling back on by setting cullface=1 in the material file.

If you are really using a material with backface culling disabled (cullface=0) then the normal will point away from the camera sometimes, and the ray will think the surface is occluding itself. It will also cause lighting errors. Don't disable backface culling. Instead use real triangles facing both directions in the mesh geometry.

Look more closely at the name of your material file.

cobllestones.mat?

Are you textures in the application subdirectory?

I would call fw:Render() a second time and move the camera.

Your media files and shaders need to be within whatever abstract path you set. So it can be in the new project folder, or the old folder, or whatever. Scripts must be in the same folder as the executable.

I wouldn't use the message system. You can call functions directly from other scripts, like gun:Shoot().