Josh

Here's what I am looking into now: http://msdn.microsoft.com/en-us/library/x98tx3cf%28v=vs.80%29.aspx

It turns out GetProcessMemoryInfo() is almost useless for debugging. The Windows heap manager allocates chunks of memory at a time, and the results of GetProcessMemoryInfo() mask memory leaks. If you purposely create a leak allocating a little bit of memory at a time in a loop, it won't show up until a certain threshold is reached, and then memory usage will increase by a lot. How can I get the actual memory usage of a C++ program, to detect memory leaks?

I am using a static lib with Leadwerks3D and BMX on OSX. It's probably possible on Windows, too.

Function reloading from script files works, even with arguments attached to connections! This means you can dynamically edit scripts, and see the result immediately when you save, even if they are in use in the flowgraph. The code behind this is pretty complex, but I don't see any way to write clean and neat code to do such a complicated task. I think the trick here is to test, test, test, and make sure there are no mem leaks. I try to keep the convoluted stuff in the editor, where no script is actually executed, and then it's easier to keep the engine code clean.

Yeah, if I skipped on docs, I might as well not do anything. They're important, and the design of Leadwerks3D makes it easier for me to say "this is the way to do x".

Yep.

There's really no logic to the function names, and they don't do anything. They just display the correct number of arguments.

No, but the script has a slight offset. However, it should behave the same in your program as it does in the editor.

Here's another shot showing it actually working. The argument count is being loaded from scripts, and the functions can be specified as an argument or an execution function.

It's 1.45, but that's not going to make any difference.

Add LOD models with fewer bones and that framerate will go up.

Of course.

Here's an example of how setting a debug hook in Leadwerks3D from a BlitzMax program saved me a lot of time stepping through code to figure out where something went wrong. When the engine encounters a fatal error, the hook is called, giving control back to the main program. I can even step through the BlitzMax debugger and see which call to Leadwerks3D produced the error: And it works with all supported languages. Little things like this make programming with Leadwerks3D very enjoyable.

The properties editor in Leadwerks3D is a live dialog. Your changes are shown instantly in the editor. If multiple objects are selected and their properties do not have the same values, the property interface will show an "indeterminate" state until the value is changed: When an indeterminate value is changed, the new value is applied to all selected objects. Since they now have a matching value, it is now shown in the dialog. You can use this to move objects along a single axis, without making their other axis positions match: The program console now displays loading and deleting of assets in blue and purple, so you can easily see every file the engine loads. The interface is extremely customizable; every element can be moved around or popped off into its own window: Did I mention extreme UI flexibility?:

Please be polite to each other. Our community is awesome, let's keep it that way.

Virtual IS needed. IMO, you should always make all your class functions and destructors virtual, all the time. Forgetting to do this when you need to will cause some problems that are very hard to track down. While we're talking about C++ rules, please ALWAYS initialize pointers to NULL, ALL THE TIME. I've wasted more time as a result of uninitialized pointers than anything else in C++.

The plan in Leadwerks3D is to build networking into the engine so you only have to expose an entity to the network, and it automatically gets updated and handled. This way physics can be synced over the network without you doing any extra code. I'm saving this for some time after the initial beta release, since it's not critical for most games, but it will be much more supportive than the basic network commands in LE2. I've already prototyped a system like this and it's easy to code multiplayer games with.

Ah, I think I know what is happening. Unnecessary ray casts or collision tests are slowing it down, I bet. Let me look into it further...

I don't think so, the controller-controller test is very simple. It's possible maybe the collisions are being discarded after the test? I don't think so, but that sounds like a possibility. Let me know the results when you use LoadMesh.

Your character models have a physics body made out of a high-poly mesh. If collision is being tested against those it will be very slow.

I'd like to see what your physics geometry looks like in the scene.

To answer the OP, no firm release date has been set but we are shooting for some time this summer.

And here it is on Mac:

I don't like people comparing their idea of a product they have never seen to something else, and speculating which is better. I'm not keen on releasing too much information yet why Leadwerks3D is significantly better for mobile development, but there are some big reasons why we will win in that space, among a big portion of users. There are some huge missing pieces no one is providing for mobile right now. Please wait until you see the actual program before making a judgement.

You could do that with any engine, couldn't you? Well, if it had an API design, which I guess isn't that common.