TylerH

Can't disagree with the matrix updates and spline interpolation, but if I recall Aggor's game I thought it used something with friction and forces, but it was more than a year ago so my memory is hardly reliable.

You'd have to use clientside vector prediction and CalcBodyOmega / CalcBodyVelocity to achieve the desired movement. Calling the other "AddXXX" commands directly just gives you addititve physics, which is the complete opposite of what you want. Optionally, you could use a simple spring to dampen the movement after you use AddBodyTorque or something similar; insanely high friction works as well.

It really isn't hard for us to maintain our custom lib against the official versions of the engine. It is only about 1 hour of work per update since Josh will most likely not be adding any new features. The only thing is that it requires some Blitzmax source files for Lua functions and some modules that we don't have access to.

Been pretty caught up in school guys, sorry about that. Umm, there was a standing issue with the shadow color modes because the engine.dll that we compiled against was not 2.4, therefore the shadow color stuff will not work until we copy our code base onto the 2.4 engine source.

Are you utilizing our custom engine DLL, or the one provided with the SDK?

2: Use this using block: using (Engine.Globality) { // Get/Set position, rotation, scale, etc. } If you use that, it is global, otherwise everything is local.

Get/Set PreferredMaterialName have been added to the DLL.

boost::string is useful in some cases...

All of these and more have been implemented in our custom engine DLL.

You don't have dynamic, per-component get/set accessors in any other language except Blitzmax.

Can and more! A lot more...

The handles exposed in the DLL are actually memory pointers, integers.

If Autodesk bought them out, it is probably now a piece of stuff. It was hardly usable back when I messed with it in Reality Engine. I mean, it worked great, but the process and pipeline was insane.

Ah, the garbage collector has a generation list of objects, but it isn't publicly visible. It is a private internal member in the GC class.

We exposed a set method in the engine.dll The order for the Matrix 4x4 or Vec16 structure is: I Vector: Position X, Position Y, Position Z, Color R J Vector: Rotation X, Rotation Y, Rotation Z, Color G K Vector: Scale X, Scale Y, Scale Z, Color B T Vector: Translation X, Translation Y, Translation Z, 1 (Identity)

Since when has it been an Autodesk product? Kynapse was created by kynogon.

There will be. We are trying to tie into getting the TLists stored in the world object, if that doesn't work, we will store a hashtable of created objects, or maybe a more efficient container.

There are open source APIs that work called OpenSteamworks, as well as OSW (same name, different project)

I think it would be great if Leadwerks, as a company, could approach things how Epic Games has, trying to get things like Steamworks, Windows LIVE, etc. available for indie developers through middleware integration.

I find myself perfectly capable of making a full-blown game that could rock some socks; however, I keep finding myself having to go back and code up frameworks and things lower level, thus never completing anything that you would ever actually see, play, or otherwise be demonstrated. Loads of tech demos in code sitting on my hard drive, completed; yet, I would never publish them because they are aimless on their own. In due time...

Wait until right before your flip commands, set the world, render it, set back.

The only way would be to have the commands in the engine to get/set the camera's matrices exposed. Get/Set CameraProjectionMatrix Get/Set CameraModelViewMatrix Get/Set CameraModelViewProjectionMatrix Feature Request

True, in reality it is just adding more to the art pipeline, but since it is optional, there really is no disadvantage to it.

It is simply the beginning of some options and alternatives for people using the engine. You are not forced to use it, but the option to utilize the middleware is there, tested, and proven. Just like with Torque and pureLight, you don't have to use it, but they have support, and that's what counts; same thing applies to the model formats supported by the engine, you don't have to use FBX or Collada, but there is support for them. I personally think if Josh continues to do this with other middleware and such, the engine would have quite a lot of scalability and possibilities.

You would have to utilize the OpenGL API to modify the GL_PROJECTION matrix.