Josh

A 4x4 matrix does not contain euler rotations. The easiest way to get these is to call SetEntityMatrix with this matrix, then retrieve the entity's rotation.

I'm not making a poor man's unity. Things like AI, flowgraphs, and CSG are being built into the editor from the start. I don't believe in tacking on functionality after the fact. It never works as well as an integrated solution.

I will strongly consider this, since 2.5d games will be more common in L3. You can however use CalcBodyVelocity() to calculate what force you need to apply to keep bodies on a flat plane.

Lua makes a lot of that unnecessary. You can just load the scene and all Lua code for objects in the scene will be run. As for AI and gameplay mechanics, that's up to the programmer to code for whatever kind of game they are making.

Yes, but the character controller isn't really a physics body. It uses my own simple physics, so I can control it completely.

For character controllers, it's actually perfectly fine to constrain them yourself by just setting the Z position to 0. It won't hurt anything. I don't like having inconsistency like that, but if you want a solution right now, it will work. Don't do this with regular physics bodies.

I don't think I can provide as good of an experience with the editor if I am trying to code it to support a bunch of unspecified behavior. It would always have shortcomings and support less than people request, and the tacked-on functionality would not work as well as having it all built in from the beginning. I want the L3 editor to be more like 3D World Studio, in terms of design style.

Probably not. If I implemented some kind of plugin system, people would probably not be happy with whatever I did. it's easier just to decide what it should do and write it that way from the start, instead of trying to tack on additional functionality after the fact.

Leadwerks 3 (the version I am working on now) supports OpenGL 4, which has hardware tessellation. It's the equivalent to DX11.

I'm glad that worked for you. I've asked NVidia in the past to build some kind of simple web interface to let a program detect the latest available driver for any GPU. I think it would make things easier for everyone.

It's possible if vsync is disabled in the program it could be overheating your card, but that should never happen because they are supposed to slow down before they start overheating. Updating the drivers is the first thing I would do: http://www.nvidia.com/Download/index.aspx?lang=en-us

I hired a local Android developer to get Leadwerks 3.0 running on Android devices. We don't know a lot yet, other than that we have an OpenGLES renderer, and everything should be cross-platform compilable. The Android version of LE3 is using a minimum requirement of Android 2.2, which is the lowest version that supports OpenGL ES 2.0. This will run on about 75% of Android devices: As you can see here, the proportion of 2.1 devices is steadily dropping. If a linear rate of decrease is maintained, they will be all but nothing in six months: Interestingly, in the LE3 platform poll about 62% of respondants were more interested in Android than iOS support. I'll let you know when we have something more to show!

That's TF2, that's for babies. L4D is serious stuff.

I pay in Left 4 Dead 2 medpacks.

That makes sense to me. If your outlines are black, you need a fairly bright ambient color in order to retain contrast.

Uploaded.

Look who's on there: http://news.yahoo.com/leadwerks-corporation-announces-net-support-070419338.html Feel free to spread this link around. I feel kind of funny doing it myself.

Okay, it's out. New demo is up with .NET support. There will be an increase in traffic today, so please be nice to any newbies. There's a good chance you can earn a commission with this news item, so feel free to use the sharing buttons to post a URL to this page with your referral ID: http://www.leadwerks.com/werkspace/blog/41/entry-693-leadwerks-software-announces-net-support We need to get the word out to the .NET community.

Well, the VB.NET projects always come out with an 800x800 screen resolution. It appears the screen width parameter is being used for the height. I think I can fix this easily enough...

Thanks guys for your help. The updated evaluation kit is here: http://www.leadwerks.com/werkspace/files/file/232-leadwerks-engine-evaluation-kit/ I want to make sure new people who download this have a smooth experience when they create a project. I am downloading Visual C# to test it now, but if you can verify that everything works, I'd appreciated it.

Those are quite good, thanks!

I am usually very excited to read about new graphical techniques, and even new hardware approaches, even if they are presently impractical for real use. I was very interested in Intel's Larabee project, even though I didn't expect to see usable results for years. However, sometimes articles get published which are nothing but snake oil to raise stock prices. The uninformed reader doesn't know the difference, and these articles are usually written in such a way that they sound authoritative and knowledgeable. It's unfair to consumers, it's unfair to stockholders, and it hurts the industry, because customers become unable to differentiate between legitimate claims and marketing nonsense. This one is so over-the-top, I have to say something. In an attempt to stay relevant in real-time graphics, Intel, the company that single-handedly destroyed the PC gaming market with their integrated graphics chips, is touting anti-aliasing on the CPU. There's a nice explanation with diagrams that make this sound like an exciting new technique Intel engineers came up with. The algorithm looks for edges and attempts to smooth them out: It's so advanced, that I wrote this exact same algorithm back in 2007, just for fun. Below are my images from it. Original: Processed: The reason this is dishonest is because you would never do this in real-time on the CPU. It may be possible, but you can always perform antialiasing on the GPU an order of magnitude faster, whether the device is a PC, a netbook, or a cell phone. I don't think Sebastian Anthony has any clue what he is writing about, nor should he be expected to, since he isn't a graphics programmer. Furthermore, swapping images between the GPU and the CPU requires the CPU to wait for the GPU to "catch up" to the current instructions. You can see they completely gloss over this important aspect of the graphics pipeline: Normally, graphics are a one-way street from the CPU, to the GPU, to the monitor. The CPU throws instructions at the GPU and says "get this done ASAP". The GPU renders as fast as it can, but there is a few milliseconds delay between when the CPU says to do something, and when the GPU actually does it. Sending data back to the CPU forces the CPU to wait and sync with what the GPU is doing, causing a delay significant enough that you NEVER do this in a real-time renderer. This is why occlusion queries have a short delay when used to hide occluded objects; the CPU doesn't get the results of the query until a few frames later. If I made the CPU wait to get the results before proceeding, the savings you would gain by hiding occluded geometry would be completely negligible compared to the enormous slowdown you would experience! What Intel is suggesting would be like if you went to the post office to mail a letter, and you weren't allowed to leave the building until the person you were sending it to received your letter and wrote back. They're making these claims with full knowledge of how ridiculous they are, and counting on the public's ignorance to let it slide by unchallenged. So no, Sebastian, this is not going to "take a little wind out of AMD’s heterogeneous computing sails". Please check with me first next time before you reprint Intel's claims on anything related to graphics. If any Intel executives would like to discuss this with me over lunch (your treat) so that I can explain to you how to turn the graphics division of your company around, I live near your main headquarters.

I have a press release going out Monday night for the release of LE 2.5. I need to get these things in order before then, or postpone the release a week. We are switching from Project Wizard to LE Builder, but there are some problems: 1. The SDK path selection step should be removed. The SDK path should be the same directory as wherever LEBuilder is located. 2. The VB.NET and C# templates should be included in LEBuilder without having to import a new template. 3. I don't understand where the C# header files should go in the SDK directory. Version 2.5 is up right now. You can download it and see how things are laid out, and tell me what needs to change. Thanks for your help.

Yes, and it would happen all the time, in scenes that don't use either.

I'm not sure if calling those commands will impact performance or not, but that is kind of odd. The performance of Leadwerks Engine is not usually impacted by the amount of geometry onscreen. The performance tends to be limited by the screen resolution, effects settings, and the number of shader pipelines the GPU has.