Josh

That's not a supported command, don't ever use that. What other behavior did you expect?

The defaults are 0.31, 0.40, 0.70, and 1.50. I can't help you beyond that unless you post an example program I can run or a scene I can load in the editor.

The shadow distance parameter controls the distances at which the directional light stages switch to the next lowest res image. There are three stages in a directional light shadow. You'll need to play around with the values to get the result you want. The shadow offset gives a slight offset to the shadow. Actually, I think this is probably causing your problem...increase it and see what happens.

L3DT is great for this, and the free version goes up to 2048x2048. Michael Betke has also done a lot using GIS data and satellite images.

The light range on directional lights indicates the scale over which the shadow depth is distributed. A larger range will eliminate shadow artifacts that occur when geometry intersects the near camera range when the shadow is rendered. I can't tell from your images if this is the case for sure, but that's the only thing I've ever seen cause a problem.

I'd use the entity red and green colors for the UV offset.

FYI, in Leadwerks3D you can do this with all assets to load a new copy: Model* model = LoadModel("mymodel.mdl",LOAD_UNIQUE);

The engine automatically instances meshes when you load a file from the same path.

He was on a few days ago.

Thanks for finding that error.

Check in the model viewer to make sure the file contains a limb with that name. It is case-sensitive. If it's there, FindChild() will find it.

I don't see any reason it wouldn't work, but I don't know any specifics about Onlive's servers.

You're going to have to be the top 1% of indie developers to do that.

Sorry, I have seen some timing methods in C++ that were wildly inaccurate. I don't remember if clock() is one, but I know I saw some that gave results with errors of 100 millisecs or more. In C++, I use timeGetTime() on Windows. This only occurs if you call Flip(1).

They probably have some simple requirements, but I doubt there's anything much to worry about. Due to the nature of their system, I don't really see them ever opening up to indies much.

I was thinking this morning how Apple has influenced my life and the company Leadwerks. You might ask why I am talking about this, since we are only now coming out with our first product for any Apple operating system. Well, before Windows existed, back in the 1980's, this was my first computer: The first "game" I ever made was in Macintosh Paint. I drew a road from a top-down view, with barriers randomly placed on either side. I drew a race car, zoomed in the image, and used the selection lasso to cut it from the page. By dragging the selected pixels to the top of the screen, I could make the image scroll, causing the road to move beneath my car, and I had to move the mouse left and right to avoid the barriers. (I tried to forget the order I had placed them in.) I also used this machine to paint my first textures, before texture mapping was invented. I drew sides of buildings with variations with windows and doors. Although the monitor displayed only two colors, black and white, you could approximate gray by stippling pixels. There was also the option to use colored pencils once you printed out the images. I would print these on paper and then construct buildings out of paper with them, a precursor to the work we would do later with CSG modeling. My uncle also wrote some of the early Mac games, including "Save the Farm", and "Hot Air Balloon". I actually have the original apps and amazingly they run on my 2010 iMac with an emulator. Last year, as we began development of Leadwerks3D, I bought my first Apple products in my adult life, including a 27" iMac, iPhone 4, and iPad 2. I've been really impressed with the quality and design of these products, and although I am not quite sure their OpenGL 3.2 drivers are there yet, I think high-end graphics on Mac has a good future. (I had it confirmed from another developer that OpenGL 3.2 MRTs do work on Mac, so I still have some experimentation to do. I suspect the multisampled texture format I am using may be causing a problem...) Ever since I started putting out videos of our new engine running on mobile devices, there has been a tremendous response from developers, both inside the Leadwerks community and beyond. I think the rise of the iPhone as a gaming device was sort of accidental. They had a device that could run apps, then they discovered people were playing games more and more on them. However, all indie game developers should be grateful Apple developed a thriving ecosystem for third party developers, because without them I don't think we would see the resurgence of indie game development like we have. Even if you are developing primarily for Android, you have to admit that platform would not be as good as it is without the influence of iOS. In a sea of mediocrity, one man cared about his work enough to make sure that everything his company put out was a cohesive reflection of his tastes and standards. I don't agree with every decision Apple has made, but I have a great deal of respect for the way Steve Jobs had a coherent vision and brought it to life, instead of just blindly reacting to what he thought would make money. He rejected the "low quality, low confidence, low price, low effort" approach the rest of the tech industry has taken, and won. Without him I think Leadwerks would be without what I think will be our most successful platforms, and indie game developers would not have the same opportunities that are present today. We should all be grateful for that. http://www.youtube.com/watch?v=uwOjsYNcUW0

I may call the AI class an "Actor" and switch our Actor class to something else, like "Modifier" or something. Maybe the class functions would look something like this: Actor::SetTargetEntity(Entity* entity, int mode, float distance) Makes an actor follow an entity. distance When the actor gets this close, it stops following. mode: 0 - always follow 1 - move to last visible point 2 - stop when line of sight is lost 3 - stop when a line of sight is acquired (for projectile enemies) Actor::SetTargetPosition(Vec3 position, float distance) distance When the actor gets this close, it stops following. You could do all this manually in script, but my guess is there are ways I can make it more optimal if it's built into the engine, like staggering the updates or running it on a separate thread. Maybe the actor would have Lua functions like this: function actor:TargetReached() function actor:TargetLost() function actor:TargetAcquired() function actor:GotBoredAndTookANap()???

Try calling Millisecs() and see what those values give you.

That's simple? I really doubt you are asking for code like that, since I can't even make heads or tails of it. I think you just want a finished game you can play around with, which is fine. Let's just be honest about what we're talking about and call it what it is.

Regarding the AI following: Normally the player moves through a map and alerts enemies when they come within a certain range and have a direct line of sight. You don't normally have a mob of enemies chasing a player through a map. Enemies should be faster than the player, so that they are forced to deal with them as they are encountered. So what would normally happen is you would move to an area, encounter some enemies, be forced to fight them there, then move on. Since enemies would be placed around the map in different locations, they normally would not all be coming at you from one direction.

There are some rather expensive commercial alternatives. The speed doesn't really matter, at some point, because ideally the processing will occur on a separate thread and the engine won't wait for the results.

Here's what I'm thinking: -Melee enemies stop when they reach a certain distance. Zombies, anything with a sword, anything that bites. -Enemies with projectile weapons should stop on two conditions. 1. A clear line of site to their target exists. 2. They are within firing range (consider a crossbow or something with a high arc). The second type of enemy might retrace their steps to back away from the player when not firing, stopping when the line of sight is broken. This might be a good approximation for running for cover, then coming out to shoot, then hiding again.

Crowd navigation is built into Leadwerks3D. You just set a destination, and your characters will automatically travel wherever you tell them to go. I think having navigation built into the engine will give us better results than a third party add-on would. We can automatically recalculate sections of the map that change, AI script functions can be called when certain events occur, and the code to control characters is extremely simple.

That's a function of the player radius. It chooses the shortest path, so the player will come very close to corners when they go around them. The scale of the obstacles in this test scene is quite big, so the player radius is very small in comparison.

There's basically no API to worry about. You just have a command to find a path, and don't have to worry about anything else. As far as controller movement goes, I think I'll just leave that to the user, and have some example scripts. It's very easy to just point it to the next node and go.