Josh

I am not sure what you are trying to do, but the math will be easiest if you give the mesh dimensions of 1.0 when it is scaled 1,1,1. I assume you are trying to make a mesh span from one point to another.

You just perfectly described the process of how road creation works. I would just use the road system with a modified script to build one node at a time in order.

The short answer to your question is that orthographic views are not presently supported in Leadwerks Editor (although orthographic rendering is supported by the engine command set).

Leadwerks Engine SDK 2.31 is now available. A new SDK installer in the download area allows you to download different versions of the SDK. You must have an activated Leadwerks account to download the new SDK installer. New features include lighting optimizations for point and spot lights. You can read about this feature in detail here. Another new feature is character controller crouching behavior. Note that the origin of character controllers has been moved to the very bottom of the controller, instead of the vertical center. In addition, particle emitters will now store the particle velocity in the first texture coordinate array of the surface. This allows the implementation of directional particles, for elongated sparks or other non-circular particles. Shadow updating can be a bottleneck in rendering. To make matters worse, point lights require a total of six passes when its shadow is refreshed. We solved this problem by only redrawing shadows of objects that moved. The shadow is then combined with the rest of the cached shadow buffer, to make the final shadow map. The net result is fully dynamic point light shadows using a proper six-sided shadow map, with less rendering cost and better quality than dual parabolic shadow maps.

Raise the decal by a tiny amount, like the road is, and use the overlay setting.

Yep, that's fine to point out.

Maybe I can upload it to CNet. This is the first I have heard of any problems.

Although I agree caution should be exercised, and do not have a good opinion of Bobby Kotick, inflammatory language and negativity without explaining your position will be moderated. You can say the same thing in more precise and less emotional terms, and make your point better. If you have a reason to distrust Activision, you are welcome to explain exactly why. What I want to avoid is threads where people throw loaded terms around with no real discussion.

LoadScene() DrawImage( Loadingscreen ) Flip() Why would you expect anything to show up when the game is loading with that order of commands? It's probably just displaying whatever random bits are in the video buffer. DrawImage( Loadingscreen ) Flip() LoadScene()

Flashlight batteries are another good idea. It wasn't clear to me how I was supposed to acquire the shotgun, or where I could pick up ammo or food. You have a really great concept here that can be made into a unique strong game. I suspect you are listening to the wrong people due to the way you turned the visuals down so much by default, and in the video. I am really excited about the possibilities you could have with the lighting in this. Leadwerks Engine is really good at drawing a lot of shadow-casting lights. Use it to your advantage and make something no one else has. With the recent improvements in lighting, your game will be drawing an order of magnitude fewer polys to render shadows, and all you have to do is adjust a couple settings in the editor:

This is great. -I love the whole zombie barricade thing. The objects hold well enough to stop the zombies, yet they can push through at a reasonable rate. It's pretty scary when your barriers start breaking down and they come for you. -The cursor is very hard to see until it turns red. I can't really see it when I move it around, and I just have to wave the mouse until it shows up on a zombie. -The day time is at least twice as long as it needs to be. -It's not worth offering a 64x64 shadowmap resolution. Use 256 as the minimum. -I'd turn shadows on by default, and show them in your video! You want the first impression to look the best. Graphics are a big part of your game, so you need to do more to show them off. If you cripple the visuals by default, then you just have poor visuals and limited compatibility with hardware. -Add a directional light during day time and make it brighter. I didn't realize at first there was any difference in the lighting. -I think you should place a few lights in the scene, so the player will naturally be drawn to those "safe" areas where they can see well. That might improve the mechanics a bit, and you would constantly be looking around to see when the zombies were going to jump into your circle of light. Then you could control where the player was supposed to build barricades, and place the advantageous spots under a streetlight or something. As it is, it's hard to see where the player is, and we never really see him lit. A few lights in the scene would really make a huge improvement, in both graphics and gameplay. I mean, the user would be scared to venture into the dark areas after night. The static shadow map options and light optimizations in version 2.31 will help a lot with this. -There's a lot more with lighting I think you can do. Make it integral to the gameplay. You can have flares, lights in the scene, campfires, flickering strobe-like lights, headlights of a vehicle, lights the player has to do something to enable, like turn on a generator. You have a zombie game with lighting features no one else has, so have fun and take advantage of it!

I want something flat.

Use blend=1 instead of the alpha test shader. Also set zsort and overlay to 1.

I can hardly see the screen in your video, because it looks like it has been lightened somehow. I think you should add a layer of a randomly positioned noise texture over the screen (in a shader) and post a video. Sometimes it's easy to be too critical of something when you are working so hard on it, and you notice things other people wouldn't even think about.

I'm looking for a device to view movies and images. The iPad is one choice, but it's not going to be out for a while, and it is pretty expensive for what it does. I'm also considering this tablet/laptop: http://www.frys.com/product/6125499;jsessionid=2rWVLFU7YWsIWEDxHqXz8g**.node3?site=sr:SEARCH:MAIN_RSLT_PG I don't see any difference between a tablet that just came out, and one that is several years old, as long as it can play a video file, so I don't need the "best". Any other recommendations?

It won't.

I don't think anyone will notice. In fact, I recommend disabling shadows when you render the CCTV image. I'm surprised it wasn't designed this way from the beginning.

What was happening before is you were doing all these expensive renders on buffers the size of the window, and then downsampling them onto your small buffer. I think the way this should be done from the beginning is to perform a simple render for your CCTV pass. It's not worth having all those post effects just for a little screen that will probably have some television noise effect. To continue as you were, use a buffer the size of the graphics window. This is not an efficient approach, but it's not much more inefficient than what you were doing before.

The only thing I can think of is that the renderer uses the current buffer instead of the back buffer to see if the rendering dimensions have changed. if Render() is called when the current buffer does not match the dimensions of the stored dimensions, the renderer will re-create the buffers at the new size. The reason this was done was so that the engine can render to buffers bigger than the desktop resolution.

I dabbled in a lot of little things recently, like GUI code and networking, just to make sure things would work the way I want in the long run. The lighting optimizations weren't planned to come out yet, but were moved to the front due to one user who is finishing up a commercial game. I've also been helping Pure3D a little bit, but I can't say anything about that right now. Of course, our website is still in progress, and that will hopefully come together by the end of the month. We'll have some cool stuff for you guys at the GDC. If you happen to be going, speak up now! There are two big things I want to complete in the next two months. They are: Art pipeline enhancements. The plan is to have a model viewer and editor integrated into the main editor. There's lots of little things like normals, binormal/tangents, physics, and the mesh hierarchy that can be difficult to export properly. This tool will give the user more control over their assets, and make it easier to import content from a variety of sources. Vegetation system improvements. Some parts of the vegetation rendering routines will be rewritten for better speed with large numbers of layers. I'll also add collision, while I am in there.

Link?

If you sync your installation, there's a small update. -Fixed spotlight shadow update bug. -Editor class tree no longer expanded automatically. -Double-clicking on object in editor opens properties. -Ctrl key + right click in editor duplicates selection and positions it at the picked position. -Ctrl key + left click in editor positions selection at the picked position. -Double-click on object in editor opens the properties editor.

They were posts asking why the thread was moved. Please stay on topic.

These are the values to edit: #define raycasts 4//Increase for better quality #define raysegments 6//Increase for better quality #define aoscatter 1.0 float raylength = 0.5;//*dist*1.0*50.0; The edge artifact is probably due to the half-size buffer that is used for rendering the effect.

You might need to restart the editor, since the class script has already been run. Or just create a new scene (or reload the one you have). If you still need help, post the relevant files so we can see for ourselves.