Josh

Those don't look low-poly...

VS2008 is the top priority since it runs on Windows XP with no extra downloads needed, and XP may account for as much as 40% of the market, depending on who's numbers you look at. VS2012 would be the next choice probably, depending on how many resources I have to devote to it.

This is the vehicle code: Vehicle.bmx

We can support Visual Studio and not CodeBlocks. We can't support CodeBlocks and not Visual Studio. People are already asking for VS2008, 2010, 2012, 32 and 64-bit builds. With debug and release, that equals 16 different builds, just for Windows.

We use .zip format. :|

When a new Leadwerks3D project is created, Leadwerks3D copies a Visual Studio project from a template, into a "Windows" subfolder in your project folder. It does the same for Xcode and Eclipse. All three IDE projects are set up to use the same C++ or C# source code. If you double-click the project name in the list, the project folder is opened in Windows Explorer (or Mac Finder) and you can open the Visual Studio project from there.

The Project Manager lets you manage multiple Leadwerks projects. A project includes assets, scripts, code, code projects for Visual Studio, Xcode, and Eclipse, along with your game's executable. The Project Manager lets you view and switch between your different projects. Projects can be exported into a .zip file for easy sharing and archiving. You can even have Leadwerks3D scan all source code files and only include the asset files that your game actually uses. (I'm still adding the password field to encrypt them): You can import projects back from a .zip file: And of course you can create new projects, for any supported language, with multiple platforms supported by each: Here's my list of things I have either recently gotten done, or postponed for some reason: X -Window order(?) X -Convex cast app (postponed) X -Script execution X -Script SaveAs, SaveAll, New, Open, etc. X -Directional light destructor bug X -Occlusion query / octreenode bug X -Delete thumbnails when folder deleted, if in deleted folder X -Send files/folders to recycle bin instead of deleting X -Project import from zip passwords X -Project switching X -CRC32 zip password checks X -Improve project import events and process And still to go: -Add password export zip field -Animation -CSG Editing

The vehicle implementation uses a raycast approach which makes it stable at fast speeds. A multibody approach gives you more of the "bouncy shocks" feel, but can be unstable at high speeds.

We are focusing on the art pipeline and gameplay features for the initial release of Leadwerks3D, in order to provide an easy to use cross-platform game development tool. Paged terrain and 64-bit builds are scheduled for later in development.

Controllers don't actually use the real physics simulation, though. The reason for this is because the character physics have no concept of rotation. If you introduce rotation, you have to have compensating forces that keep the character upright, and those always cause unwanted effects. This is why most character controllers built into physics libraries are usually really bad. The lead dev from Amnesia/Penumbra recommended I do it this way, and it was a good idea. So it's probably safe to move a controller with the entity positioning commands.

Please file a bug report if you think that really is one. I can't think of any reason there would be a problem, but it's possible.

Do you mean lots of controllers colliding with one another? Perhaps you have collision enabled on a high-poly model, instead of using a low-poly physics shape?

You do not need to buy Unwrap3D, as the FBX converter is very reliable.

Yeah, I would render first to one buffer, then another, and then draw the first buffer's color texture onscreen wherever you want it, use it on a 3D surface, or whatever you are doing.

I think in that situation you would usually want to use an integer variable with a recognizable name like ANIMATION_WALK, but unless you are doing it hundreds of times each frame, it won't make any noticeable difference.

Correct. That is the usage the documentation will always describe. Power users may want a little more, but they're generally smart enough to not hurt themselves.

Correct, that would cause unpredictable results, which is why the "correct" way I will always recommend is Get/SetRotation(). C#'s solution for this kind of behavior is one nice thing about that language.

That's a situation where calling "x1 = cube1.position.x" seems the simplest to me, and would't require allocation of a new Vec3 and Lua table.

You would use "x1=cube1:GetPosition().x" in that situation. Of course, even better would be this: position = cube1:GetPosition() By the way, there is no point in the engine where we ever iterate through the list of all entities. It's always broken down into the scene octree.

I have some members exposed in Lua, but I would not ever use them in example programs in the documentation. I could see an argument for not having them exposed at all in Lua, since they are a low-level hardcore C++ feature for writing intensive routines.

I don't recommend setting members directly. For example, changing the position member of an entity would not have the intended result, because the 4x4 matrix and other things have to be updated. Members generally should be treated as read-only attributes. For that reason, you will never be expected to rely on members. If you want simpler code and faster performance in intensive routines, you can read them. Any members we document will be considered "fixed" and won't change. Don't mess around with anything that's not documented, because that could be subject to change. Members also gives you a little more power. For example, Material::GetTexture(const int& index=0) increments the refcount of the texture and allocates a new handle that has to be deleted (so you can safely use a texture without worrying about it being automatically deleted when the material is deleted), but you can avoid this by just reading the member with material->texture[0].

It doesn't matter, the vector won't scale well when the numbers get big. If you have 10,000 entities, this can result in 40,000 bytes being allocated or copied every single time you create or delete a single entity. The list will always add and remove elements at the same speed. The iteration speed of both will increase linearly with the number of elements. When designing systems you want predictable performance and scalability. Sacrificing scalability to gain a minute performance increase (in the lightweight scenarios where it isn't even needed) is a bad idea. What? Who said anything about maps? I like being able to access members. It's simple and convenient. It would be silly to call Entity::GetPosition() and allocate a new Vec3 object every time I need to perform some math on an entity, when I can just access the member directly. If you don't like it, don't use them, because there is a getter and setter for anything you need to access.

Yes, you can debug the Lua state of any application that is built with the debug Leadwerks3D library.

A vector is a contiguous block of memory. If you remove an element in the middle of it, everything after that element has to be copied to where the element's position was. If you add an element at the end of the vector and it exceeds the size of the memory allocated for that vector, a new block of memory has to be requested, and the entire contents of the container copied to it. Linked lists have a next and previous pointer for each element. When an element is removed, the program just has to update the memory pointers of the previous and next elements to point to each other, so insertion and removal is fast. I almost never use vectors.

Lists should be used if objects will be randomly removed from the container.