Josh

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.

I use this in Xcode and VS all the time, and it's a great feature. I don't know if it will make it into the first release, but I agree it's very useful.

The saved files are located in "C:\Program Files\3D World Studio\maps" by default.

Ah, matrix math. That matrix looks right. Line 1: The local x axis points at 1,0,0 Line 2: The local y axis points at roughly 0,0,1 Line 3: The local z axis points at roughly 0,-1,0 So the object is pointing down, which makes sense with a euler rotation of 90,-180,180. That's where gimbal lock sets in, so the yaw and roll are a little funny. The scale should be 1,1,1 and it's only because of floating point imprecision that it's not. That happens all the time and isn't a problem.

It's the old ease-of-use vs. quality of results conflict. I think you guys will be happy with how I worked it out. I am coming from a programmer's point of view, but realize the market probably values a visual art pipeline above anything else.

Really, I'd like to play a 3D game on the iPhone that doesn't suck. Something like Mario64 would be really fun. If there was a game like that available I would buy it.

You have to have the texture somewhere in the Leadwerks Engine SDK directory. You can change the path the tools use to load assets from in their settings file. LE3 uses a more drag and drop approach.

That seems counterintuitive, because assets are reusable and scenes are unique.

It took a while to figure out, but I was able to get drag and drop interaction working on OSX. (Thanks to Seb Hollington for helping with the coordinate transformation stuff.) Now the editor lets you assign textures by dragging them onto texture slots, just the same as on Windows. There's one last step before the editor code becomes totally platform-agnostic. A file system watcher needs to be implemented on Mac. On Windows, this was fairly straightforward, because there is a built-in API for detecting all files events. OSX has something called FSEvents, but they only detect changes to a directory; they don't actually tell you what file changed, or how it changed. QT has a file system watcher, but from what I can tell, it looks like it doesn't detect new folders that get created. I think this is something I am going to put off for now and slowly research it. As can be expected, OpenGL support on OSX Lion has some issues to be worked out. I haven't actually had a confirmed bug where the driver's behavior is violating the specification, but there are some weird things. Due to the difference between Mac and Windows file paths, I was accidentally not attaching any shader objects to a shader program, yet it successfully linked! This actually does not contradict the OpenGL specification, but ATI and NVidia drivers would have raised an error. The commands for MSAA textures are working, but the highest supported multisample level is one, meaning no multisampling. Again, this is all in accordance with the OpenGL specification, but the GPU in my iMac is capable of doing 16x MSAA textures. I got around a few issues and sent Apple a demo of LE3 running on Lion; The rendering flashes on and off every few seconds, and I have no idea why that could be, but there's nothing more for me to do on it since it's not raising any errors. I think Apple is moving in the right direction, and they'll eventually get things worked out, but I would not recommend buying a Mac for high-end graphics just yet. I met with an Android developer yesterday about getting LE3 running on Android devices. Since we already have it running on Windows, OSX, iPhone, and iPad, adding one additional platform should not be too hard at this point. Compiling C++ for Android is a pretty complex task, so it makes sense to have someone else work on this area while I focus on the core engine and editor. Once we have it running, the "platform milestone" for LE3 will be reached, with support for all platforms we intend to target at launch.