Josh

It's hard to say. I've never released a product with this much support and polish, so it's hard to me to estimate. In the past, we tried to just get something that was simple and functional out, and this software does a lot more for you, so it takes longer.

iOS runs Lua just fine. In fact, there are a couple of Lua script editors for iPad in the App Store. We use a JIT compiler to make Lua script execution fast. Now that I can see Leadwerks 3 nearly finished, the art pipeline and development process runs circles around Unity, IMO. They deserve credit for making the first entirely visual art pipeline, but we are making the first well-designed visual art pipeline.

I recently made two small improvements that make the editor much more fun to work with. A shader consists of two pages of code, for the vertex and fragment programs. I originally designed the shader editor to use tabs to divide up the two code chunks. However, this meant the shader editor could have only one shader open at a time. This made copying and pasting from one shader to another rather tedious. To improve this, I merged the shader and script editors into a single window. Multiple shaders can be opened, and they show up in the window tabs. When a shader file is selected, a tree view appears on the left hand side of the code area. This displays the different code sections, and even lets you view the code for multiple graphics modules. When you press F5, the shader is still compiled as before. Klepto2 also told me about an OpenGL ES offline shader compiler. I set the editor up to use this to compile mobile shaders, so you can test whether they compile and fix any errors without having to try it on your mobile device. Another new feature is the Object Bar. This is a vertical stack of buttons on the left side of the program window. It contains the object selection mode buttons, followed by the most frequently used object types. Although this cannot replace the drop-down boxes with parameters like number of sides, etc., it does make development much faster. Since I added this feature I have found the editor much more enjoyable and fast. Having the most commonly pressed buttons near a corner makes it easier to find them when you are pressing them over and over. (I often had to stop when using 3D World Studio and visually scan for these buttons somewhere in the middle of the toolbar.) These are just small improvements, but they make a big difference in the speed and feel of the editor.

No.

I borrowed Shadmar's terrain splatting shader. This is the result after fiddling around with it for a few minutes in Leadwerks 3. (No normal mapping yet, but that's easy to add.) Physics can be added by generating a physics shape from the terrain model. It doesn't allow heightmap editing in the editor, but I think this will serve as a good solution until our super uber mega streaming terrain system is built. Thanks to Shadmar for the assets. Klepto is also looking into a few OpenGL ES emulators to see if there is a way to test mobile shaders on a PC.

See my blog: http://www.leadwerks...-visual-studio/ And the redistributables don't work, BTW.

I distribute a static library and there is no standard format for this. It varies from compiler to compiler. Anyways, 2010 seems like the most logical choice to me.

I picked up an Intel SSD for fairly cheap and installed the Windows 8 Release Preview on it. With this configuration boots up in about 5 seconds. I actually spend a lot longer waiting for BIOS to finish than for Windows to start, which is fantastic. Anyways, it makes sense to me to take screenshots for the docs from the newest version of Windows 8 since Windows is still the dominant operating system. I couldn't find a driver for my ATI 3850, so I swapped it out for a GEForce 480. Here's Leadwerks 3 running in Windows 8. It runs perfectly and doesn't look too bad.

VS 2012 runs on Windows 7, actually.

What? Are you sure this is the Internet?!

@Roland, the debate is XP development support (2010) vs. 2012 with theoretical XP deployment that doesn't exist yet. (But in any case, XP is better for high-end graphics with OpenGL.)

If you want high-end graphics, Windows XP is the best option. OpenGL rendering is about 15% faster in XP.

Another tip: If you experience linker errors, add this to the Linker command line, and add "libcmtd.lib" to the linker input libraries: /NODEFAULTLIB:msvcrtd.lib /NODEFAULTLIB:libcmt.lib

I experienced some problems this week when I tried to create an executable with Visual Studio 2008 for deployment. On Windows 7 test machines I would get this error: I finally tracked the solution down to a Visual Studio project setting. In Project Settings > Configuration Properties > C/C++ > Code Generation there is a property called "Runtime Library". By default it is set to rely on external DLLs. Change these values to non-DLL settings (like MT or MTd) and they will include the runtime library in the executable. This makes for bigger executables, but they will run everywhere. Having experienced this problem with Visual Studio 2010, I guessed this was the same issue. I uninstalled the Visual C++ 2010 Redistributable Package from my Windows XP machine, then created a simple test program on another Windows 7 machine. First I made sure I could create the problem, by using the default runtime library. Ever seen this error?: I've seen this issue come up before on this forum. Now you know how to solve it and build Debug or Release executables that will run everywhere, with Visual Studio 2008 and 2010. Here is my test application from Visual Studio 2010, "testapp.MDd.bat" will only run if you have the 2010 Redistributable Package installed. "testapp.MTd.bat" will run everywhere: testapp.zip Since we no longer have problems creating executables for Windows XP with Visual Studio 2010, I see no reason not to move our project on to a newer version. Visual Studio 2012 currently cannot make Windows XP executables, but Microsoft claims this will be supported soon. However, even if deployment to Windows XP is supported, Visual Studio 2012 itself will never run on Windows XP. Switching to Visual Studio 2012 would mean you cannot program Leadwerks with C++ on Windows XP. What do you think? Should we make the move to 2012, 2010, or stick with 2008?

Okay, you just have to go into project properties > C++ > Code Generation, and for "Runtime Library" you choose "Multi-threaded Debug (/MTd)" or "Multi-threaded (/MT)". The reason this did not work for me before is because I had a static library for FreeType that was using the DLL runtime library. I have no idea why installing the Redistributable Package didn't work. Is the same issue as when Visual Studio 2010 executables don't work without an additional package installed on Windows XP? Can it be worked around in the same manner using Visual Studio 2010 or 2012?

When I run a Visual Studio 2008 program build with debugging enabled on Windows 7 64-bit without Visual Studio 2008 installed, I get the following error: I tried installing the Visual Studio 2008 and Visual Studio 2008 SP1 redistributable packages for both x86 and x64, restarting between each, and it made no difference. How the hell are you supposed to make a simple program run on Windows?

Hi, I contacted you via email. I cannot find any record of your email address. Please reply to my email and I will sort this out.

Yes, but I think he wants the raycast to go through undesired entities and hit the ones he wants.

There's a collision type argument you can use to do this.

Yes, this is the Leadwerks 3 editor.

http://www.leadwerks.com/werkspace/blog/1-joshs-blog/

@ChrisV I like it, but it seems disjointed.

I'm trying to keep a low profile before the launch.

The last one is my favorite. It uses the classic DA font, and the abstract horned head is very cool. A candle in the center seems kind of odd, though. The second to last with the demon is a cool concept as well, but combines a few different elements that don't look like they go together. I can't say specifically how I would improve it at this point, but I would like to see the design keep refining and evolving.

Meters per second.