Josh

That image was posted by me using the admin account. Of course the wheels in your model have nothing to do with the actual location of the tire ray cast, so make sure that is inside the physics body of the chassis. You posted another video showing vehicles with very high spring constants, causing them to jump all over. Those spring values are very important and vary based on mass and spring length. Adjust those values until you get something that is loose enough to not jump around, but tight enough to hold the chassis up. Beyond that, I suggest posting a demo so we can see the behavior for ourselves.

I don't have any plans to ever force this on the user.

File Name: Texture Tools File Submitter: Josh File Submitted: 15 Jun 2011 File Category: BlitzMax Source code for Leadwerks Engine 2 texture tools. Click here to download this file

Yes, it's not meant to be used multiple times with different resolution buffers or different settings. If you change settings it will have to recreate buffers twice each frame. Use regular plain rendering with just lighting, no shadows, for your low-res reflection passes.

No info yet, unfortunately.

That is a really clever idea.

3d world studio 6 will share a lot of code with the leadwerks engine 3 editor. It's in development.

The Lua implementation in LE3 goes into a lot of detail with code stepping and debugging. It makes things very transparent: http://www.leadwerks.com/werkspace/blog/1/entry-658-lua-and-c-debugger/ http://www.leadwerks.com/werkspace/blog/1/entry-655-tools-and-stuff/ I don't think supporting five different scripting languages through a third-party JIT compiler that may or may not match the original language behavior 100% is going to provide as good a result. I'd rather choose one script language and put all my effort into that. LuaJIT also makes Lua about as fast as C#, and I can turn it off and on with a single command.

That spring constant looks WAY too high, and would result in the bouncing behavior you see here.

You can pack model scripts into .pak files but I recommend leaving scripts that get included by other scripts as either the origjnal .lua files, or .luac if you want encrypted precompiled byte code.

Lua has features that make it ideal to work together with a flowgraph, so i am not changing it. Plus it's used in World of Warcraft, Crysis, and hundreds of other games.

We use Lua for scripting, and the implementation is finished.

Getting back on-topic, I don't see myself switching the editor over to C# or C++ at any time in the future. There's no compelling reason to. We'll hope future versions of all supported operating systems remain backwards compatible as long as possible, which I think should be good for another ten years. Yes, you are right that the majority of projects of interest come from the BlitzMax coders.

If it's using GDI to draw custom widgets, then how can that be considered the standard GUI? By that definition anything is the standard GUI, as long as it's drawn on a Windows window with GDI.

It's similar to Windows, but you're blind if you think this is the standard Windows GUI: Code::Blocks gas a lot of redraw bugs when the panels are resized. You'll get a big chunk of the window grayed out because it didn't redraw right. On top of that, wxWidgets has the absolute worst command design possible. Every single widget you create is its own class! It's ridiculous.

Reverse the polygon order or disable backface culling glDisable(GL_CULL_FACE); or glFrontFace(GL_FILL,GL_CLOCKWISE/COUNTERCLOCKWISE) //something like that, off the top of my head

That's a complete lie. If wxWidgets used the native GUI, wxWidgets applications would be unrecognizable as being such. wxWidgets applications are easily recognizable and full of bugs. This is why I say it's like talking to a wall whenever I bring this up. I just mention it, and everyone has to post a wall of text defending their favorite language.

Java doesn't have a cross-platform native GUI.

Please post an example showing what you are trying to do. Otherwise it is very hard to guess what might be happening.

I don't know yet if I will add a BMX subforum. Since the BMX API is just the C API, there's not going to be a lot of BMX-specific issues like in LE2. It would be good to put any BMX-specific issues in a forum on blitzmax.com, if BRL allows it, because otherwise there isn't going to be an active discussion there. Having an active discussion on blitzmax.com is good because that will attract more blitzmax programmers. I've tried for a long time to think of a way to get them over here, and it's very hard because the only remaining customers there have brand loyalty like crazy, and generally aren't interested in anything that doesn't have the word "blitz" in the title. An active subforum on blitzmax.com is a way to make LE semi-official for BMX, without stepping on Mark's toes or asking him to get involved in distributing LE3 licenses. As for the editor, I don't know what else I would use, because nothing else has a cross-platform native API, and it's like talking to a wall when I point this out to C# and C++ programmers. Eventually I would like to have our own version of MaxGUI written in C++, so it can be used with whatever language.

Call this: glSetMatrixMode(GL_MODELVIEW_MATRIX) Before your code and see if that helps.

No, because That won't work. It would be just the same as if you had applied a material outside the render call.

See the "Introduction to Materials" lesson in this package: http://www.leadwerks.com/werkspace/page/Documentation/LE2/tutorials/_/programming/cpp/leadwerks-c-tutorials-r25

I'm leaning towards PhysX 3.0. Couldn't really find a big differentiator between Bullet and PhysX.

These are not supported in LE2.