Josh

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.

Maybe that's too big? I have experienced it just silently failing if my image did not meet requirements.

Ah, I see what you meant. Don't worry about offending me, I like to entertain all manner of suggestions. Doesn't mean I'll do it, but I like to know what people think.

This is the Leadwerks3D particle system. It may be possible to set up a new graphics module based on Leadwerks Engine 2. The particle class is just calling surface creation commands, so it's not that different.

And you're setting up terms that are less favorable to them, if they do expect to do well.

Fortunately we don't have investment bankers breathing down our necks, so we won't ever have to charge that much.

It will cost less than Unity Pro.

I first started with projection shadow mapping, but it has many problems. When the light direction and camera direction are close to matching, there's no way to skew the perspective to get everything into the view, and you get very very low shadow resolution. After playing with this for a long time, seeing the same problem in NVidia's demos, and lots of reading, I decided perspective shadow mapping is only good for academic papers, and cascade shadow mapping is much more robust, which is why everyone uses it.