Josh

The NDK C++ tools are pretty awful. No debugger, so I don't recommend developing your app on Android. Just develop it on Windows, Mac, or even iOS, and compile for Android for distribution. It's obvious to me that whoever supports pure C++ the best will be a winner. I have a lot of C++ criticisms, but the way I see it, Java and Objective-C are just as poorly designed, and have the additional disadvantage of not being widely supported. You also get the benefit of weeding out the more amateurish programmers. We all end up using C++ anyways to bypass these "wrapper" languages. So if Android eventually moves to pure C++, preferably with integration in MS Visual Studio, that will be a good move for them. If Nintendo wanted to make a big comeback, they would make a C++ SDK for free or cheap and have an online store like the App Store. I mean, for years all the console devs did the exact same thing with a highly restricted SDK, and the first thing that comes along and does the opposite blows them out of the water (iPhone).

It would be hard to set up a game without having the new API to code with, but I think you will be able to port Lua games with Leadwerks Engine very quickly to the first beta of Leadwerks3D.

After some initial difficulty, Leadwerks3D is now running on Android, with the exact same code that runs on iPhone, iPad, Windows, and Mac. A big thanks for Aria for all his help and expertise with the Android platform. This means Leadwerks3D is now running on all platforms we intend to support at launch, and it can be easily extended to support new ones. To celebrate, here's another cartoon I drew:

Lua will run on iOS and Android. C# should work as well, although I have not tried it yet. You don't have to touch Objective-C unless you want to. We just use it as an entry point, and then execute our C++ code.

I got word back from our Android programmer about the likely cause. It's great to have someone around who is a counterbalance to my strengths and weaknesses as a programmer.

You could always put two enormous bodies on either side of the plane you are interested in allowing, and constrain objects that way.

In Leadwerks3D you can assign any script or more then one script to an entity. In Leadwerks Engine, you will need to select the script code you want to copy, type Ctrl+C and then open the other model's script and press Ctrl+V.

For bullets I would perform a raycast each frame, and use AlignToVector to orient the visual mesh.

Please file a report in the bug tracker if there is a reproducable problem.

It's a built-in Lua command, not C++.

Here's the code: Print("context = "+GetObjectAddress(context)); Print("Graphicsdriver: "+GetObjectAddress(graphicsdriver)); Print("GetGraphicsdriver: "+GetObjectAddress(GetGraphicsDriver())); Print("ActiveGraphicsDriver: "+GetObjectAddress(ActiveGraphicsDriver)); Print("context->graphicsdriver: "+GetObjectAddress(context->graphicsdriver)); Print("context = "+GetObjectAddress(context)); Here's the output, running on an iPhone 4: context = 0x06921400 Graphicsdriver: 0x0694e800 GetGraphicsdriver: 0x0694e800 ActiveGraphicsDriver: 0x0694e800 context->graphicsdriver: 0x0694e800 context = 0x06921400 Here's the output, running on an HTC Evo 4G: 08-30 11:34:02.319: INFO/LEAndroid(8250): context = 0x00270168 08-30 11:34:02.319: INFO/LEAndroid(8250): Graphicsdriver: 0x0026f0d8 08-30 11:34:02.319: INFO/LEAndroid(8250): GetGraphicsdriver: 0x0026f0d8 08-30 11:34:02.329: INFO/LEAndroid(8250): ActiveGraphicsDriver: 0x0026f0d8 08-30 11:34:02.329: INFO/LEAndroid(8250): context->graphicsdriver: 0x30203a72 08-30 11:34:02.329: INFO/LEAndroid(8250): context = 0x002704dc On the Evo, even printing out the object hex address twice will result in two different values: Print("context = "+GetObjectAddress(context)); Print("context = "+GetObjectAddress(context)); Nothing else to say at the moment. Will let you know when I find out what is going on. B)

This is not possible.

From terrain.frag: float slope = asin( worldNormal.y ); slope = 90.0 - slope * 57.2957795; You may have to fiddle around with it a little for rads/degrees.

Sorry for the fierceness of my earlier posts, I've been very irritable lately due to some technical challenges. I'm more inclined to do this kind of thing for the Leadwerks3D documentation, because it's planned to last for a long time.

The position of a joint is the point where it rotates around. If you want the child joint to swing around the parent, the joint position should be the same as the parent's global position.

Yes, don't let my positioning of it as a "visual game design tool" scare you. You've still got an API-oriented engine under the design layer. I'm just adding a layer of control designed for people who don't want to program. Who knows, you might even find it useful for some tasks. I think C++ is the best language to document things in, because it is a standard everyone can follow along. I can't really write syntax descriptions in Lua since all variables have no type. It's easier to convert a C++ examples into C# or Blitz or Lua than it is to go from another language to C++.

That makes sense to me. It's kind of silly to have a full page of code just to demonstrate Entity::SetMaterial or something like that. If you look at the Vec3 operators, I made small examples that aren't entire self-contained programs. Sometimes I need to stop being so pedantic about everything.

Find the mesh's topmost parent, or the first parent that is a model.

Wikis are much easier to edit. The table of contents is handled automatically, and internal links can be added just by surrounding a work with [[brackets]]. It probably would take three times longer to edit all that HTML, and every change would be painful. Plus, people want to be able to search them and not everyone will think to use Windows search (I think they messed it up in recent versions, too...one more reason I prefer XP. ). I would have to create all accounts manually. Apparently there was at one time a bridge for IPB and MediaWiki, but I am not sure if it works. Then there is the issue that I have to be able to answer all questions about these docs, and if it's something a user added, I might not be up to date on that knowledge.

Lately I've been talking a lot about making non-programmers happy, so here's something for the coders. B) For Leadwerks3D documentation, I considered three possibilities: -IPB-based docs -Wiki -Offline CHM files Each has their own strengths and weaknesses, as always seems to be the case. IPB A bit slower, harder to organize, harder to edit, looks really good and consistent with the site, search requires quite a few clicks to get where you want to go, missing table of contents is a bummer for long pages. Wiki A target for spam, doesn't match the main website, user-written docs cause fragmention and a mix of official and unnofficlal information, nice table of contents, good searchability. Offline CHM Fast, doesn't require internet connection, easy to edit, Windows-only. I dismissed offline docs simply because we wouldn't be able to post a link to refer people to a certain page. I decided on a wiki because of the better search functionality, table of contents, and ease of editing. Here's what I have in mind for the docs. Because Leadwerks3D is written in C++, we're able to document members, constructors, operators, and other stuff we haven't had access to in the past. Best of all, almost everything works exactly the same in Lua, including function and operator overloading. http://www.leadwerks.com/newwiki/index.php?title=Vec3 I'm also a big fan of the ease with which we can add internal links. For example, the Vec3 members in the AABB class documentation link straight to the Vec3 class page: http://www.leadwerks.com/newwiki/index.php?title=AABB#Members To avoid spam, and to make sure I can answer any questions about the contents of the wiki, it's going to be read-only. Community tutorials have been very useful in the past, and we're going to continue that going forward, either through a subforum or database for Leadwerks3D tutorials. I think having one page per command and an example for every single command has been more redundant and time-consuming that we have needed. I want to list the syntax for each command only once, like this: http://www.leadwerks.com/newwiki/index.php?title=Entity#SetPosition Instead of making a lot of redundant examples (Do we really need a page of code for Entity::SetPosition() AND Entity::SetRotation()?) I hope to provide more comprehensive examples showing how to actually do something, and how the functions can be used together to do interesting things. In general, I want to go into much more depth with the Leadwerks3D documentation, on all aspects of using the program, because I plan for this iteration of our technology to have a pretty long life. If you have any suggestions, just let me know.

What you're complaining about is the size of the Leadwerks community and the number of people writing documentation. I do not have any control over that at this time and can't provide that. I could lie and say "sure, I will think about doing that" but I don't have time and it's not going to happen any time soon. I try to stick to what I can do a good job of, and build off of that. Writing tutorials about 3ds max is beyond the scope of what I provide. So far, you have sent me an executable that won't launch, a password-protected zip file with no password, and another corrupted zip file. I'll help you identify where your bottlenecks are, but you need to give me something to look at on my machine. Some of the issues you point out are why I eventually want to have a Leadwerks modeling program, so we can have control of the entire art pipeline. As it is, writing documentation for 3ds max would only assist a fraction of our users.

I know enough about how it will work, it's just a matter of hard work.

I don't have a password for your package. I don't have the resources to write a blog about how to use 3ds max. Most people don't even use that program.

Fewer materials is better. Fewer polygons is better. Lower resolution textures are better. Fewer entities are better.

There is no formula for making models that will result in optimal rendering. There's a lot of ways a scene can be made slow. Generally, you want to keep your entity count to a minimum, so eliminate any entity hierarchy from your models unless it is needed. Turn full statistics on in the editor and post screenshots. I tried to run your executable, but it won't launch.