Josh

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.

It's a callback that gets run when the entity is actually culled in the rendering process. Once it is determined this entity is visible, the Draw() and DrawEach() functions will be called. (The Draw() function only gets called once per render, so it won't be called again if an entity is rendered by two cameras or two light sources). This is useful for animation, because you can perform animation only when you are sure an entity is going to be drawn.

There's an object:DrawEach(camera) function you can declare in Lua. I recommend the object:Draw() function for animation, since it will only get called once per render, and DrawEach() can be called multiple times.

obj2gmf.exe "mymodel.obj" There aren't any other options.

I don't know yet. Real-time feedback would be nice, but there's also a lot of ways to produce these with Photoshop etc, that might be superior to poking around with color curves. For example, it would be trivial to make a black and white color table in photoshop, but I am not sure how you would do that with RGB curves. How frequently do you think the color grading will need to be adjusted? Is it sufficient to include a dozen or so lookup tables for the most common looks you might want to achieve?

Leadwerks Engine 2.43 ...will be released tomorrow, along with a new source distro. I've fixed a number of bugs, but I don't like compiling releases when I am tired because there's a lot of little steps to mess up, so I will do it in the morning. Leadwerks Engine 3 Optics was always my favorite subject in physics, and I've been getting some amazing results lately by modeling computer graphics after real lighting phenomena. Once I decided to make the materials system like 3ds max, everything became easy. The engine chooses an "ubershader" variation based on what texture slots a material has a texture assigned to. Creating a normal mapped material is as easy as creating a material and adding two textures. The engine will assume texture slot 0 is the diffuse map and slot 1 is the normal map, and will load a shader based on that. Predefined slots include diffuse, normal, specular, displacement, reflection, emission, refraction, and opacity maps. Of course, you can still explicitly assign a shader if you need something special. The material below was created just by dragging some textures into different slots and adjusting their strength: Cubemaps are built into the model ubershader, and there's support for reflection, refraction, or both using a fresnel term to combine them. Chromatic aberrtion is also supported, which splits refracted light into its RGB components: While I was getting into all these advanced optics, I decided to take a stab at color grading, and the results are great. You create a 3D texture (it's easier than it sounds) which gets used as a color lookup table in the post-processing filter. To make a new color table you can just run the source 2D image through a photoshop filter and save it. Color grading gives a scene an overall feel and makes colors look consistent. It's a technique that's used extensively in film, starting with 2000's Oh Brother Where Art Thou: Here's anpther example: And here's a simple shot in the engine. The original: And graded with a "cool" color table: It's more advanced than just tinting the screen a certain color, because this effect will actually emphasize a range of colors. Preparing the Asset Store Now that Leadwerks.com is hosted on our own dedicated server, I was able to create a more secure folder to store asset store files in that can only be accessed by the forum system. Previously, we had dynamic download URLs working, but the same file could still be downloaded from any browser within a few minutes before the dynamic URL changed. This will give better security for asset store merchants. According to my big flowchart, the only things left to do are to fix the side-scrolling main page and set up a merchant account with our bank, and then we'll be ready to launch. Great movie and soundtrack, by the way:

Yes, but it costs less total to buy LE2 and upgrade than to buy LE3 when it's released.

Your callback functions must use the Windows function protocol (unless you are using BlitzMax) and use the following arguments: void MessageReceiveCallback(entity:TEntity,name:Byte Ptr,extra:Byte Ptr) "win32" void CollisionCallback(entity0:TEntity,entity1:TEntity,position:Byte Ptr,normal:Byte Ptr,force:Byte Ptr,speed:Float) If you still have problems, please post a simple example I can run, in a bug report.

I do not have a console developer license, but Leadwerks Engine 3 is being developed with the eventual goal to be on the consoles.

It is possible it may be if the binding library is faster. I wouldn't be surprised if this is the case, but it's hard to perform an objective test.

The deferred renderer requires OpenGL 3.2. It is possible to make a deferred renderer with earlier versions of the API, but OpenGL 3 is designed for modern rendering techniques, has better driver support, and is much easier to use.