Admin

Will check it out.

Leadwerks Software announced today the release of Leadwerks 3, their new development platform for building mobile games with native code. Based on the technology developed for their successful game engine for PC, Leadwerks 3 brings a totally new approach to mobile game development. While environments such as Unity and MonoDevelop use managed code...that is, code that is designed to be easily run on multiple devices...Leadwerks uses an approach called native code. Applications built with native code are optimized to work with each platform. That means games written with Leadwerks will run faster and be more powerful than their managed code counterparts. Mobile is growing rapidly, but there still exists a gap between mobile gaming and the larger game industry, which has traditionally focused on consoles. Professional game studios overwhelmingly favor native code because of its speed and flexibility. By focusing on the standard the game industry already uses, Leadwerks provides both professional studios and indie developers with an easy pathway into mobile. Games written in C++ can be ported to Leadwerks 3 without having to rewrite them in a new programming language. Leadwerks 3 brings some innovative new approaches to the table: The editor features tools for building game levels using a technique called constructive solid geometry. This streamlines the process of creating games, and makes it easier for artists to see what their games will look like as they build them. Leadwerks 3 uses automatic asset conversion. This means that images and objects can be reloaded on-the-fly, so an image file can be modified in Photoshop and the result will show up in the editor right away. This removes tedious steps from the game development workflow. AI is supported out-of-the-box. The traversable areas AI can travel within are highlighted in the editor as you build your game level. Pathfinding is dynamic, meaning that if a door opens or a drawbridge lowers, the AI is smart enough to take the new routes that appear. The script language Lua is also supported, and can be combined with games written in native code. Scripted objects can be linked together in a visual flowgraph editor. This makes it easy to set up game interactions, something that can be a challenge when working with development platforms based solely on code. Leadwerks CEO Josh said that “Leadwerks 3 is a big step forward for our company and our users. We’re bridging the gap between mobile gaming and the traditional game industry.” The product received a favorable response at the GDC 2013 expo. ”C++ is the game industry standard. Our market research at GDC 2013 revealed a huge demand for a cross-platform game engine built on native code. We found the design philosophy of Leadwerks resonates with a lot of developers.” Leadwerks 3 can be purchased from the company’s website for $199, with add-ons for iOS and Android publishing available separately. A source code license is available for professional studios. A 30-day trial can be downloaded from the company’s website. Leadwerks Software has provided game development tools to thousands of developers worldwide since 2006. It’s technology has been used in commercial games, education, training simulations, and military applications. To find out more, please visit www.leadwerks.com.

After a wild week at GDC 2013, it's nice to be back doing what I do best...writing code! A new build of Leadwerks 3 is now available. We've added light vector maps so that lightmapped surfaces can display normal mapping effects. Lightmapped materials with normal maps should use the texture "Common/lightvectormap.tex" in slot 4. (If you create a new lightmapped material, this will be done automatically.) This technique works by calculating the average light vector that influences each luxel in the lightmap. Each vector is weighted by the light's intensity and range to get an overall vector representing the direction most light is coming from. The light vectors are encoded in a secondary light map that looks like this: This effect will even work with specular reflection, as seen in this totally over-the-top screenshot: We also made about a dozen small fixes to the engine and editor. For more detail on recent issues resolved, visit the bug reports forum. Like any new software, we've had some teething problems, but it's pretty easy to resolve those issues as they arise. Bugs can be fixed as they are identified, but bad design is forever. Fortunately, I think we've got a great design and a good and stable development system.

Fixed.

Original report resolved.

It's really easiest for me if there's just one code I can copy and paste into app.cpp, but thank you. It's fixed and will be uploaded today.

Really? All we did was make the header shorter and span the entire page.

What data?

Not yet. I'm working on this: http://www.leadwerks.com/werkspace/page/gallery/_/projected-shadowmap-rd-r181

If someone would like to upload it in the forum, I have no problem with that. There's some good information in there.

You can assign functions to objects just like you can add members.

What else would they be? It's just a memory address.

What data type would you suggest, and exactly what kind of errors are you describing? I don't see anything wrong with casting to a void*, it's just a pointer that takes either 32 or 64 bits of data.

The example here has been fixed. Just cast the function pointer to a void*: http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/object/objectaddhook-r759

No extra download is needed. We just enable your key and it gets the extra parts.

Newton 3 is filled with error checks and it's quite excessive. I did a full project search and replace to get rid of these, which can occur during physics updates.

I don't understand the report.

Please tell us the steps we need to follow to produce an error.

We had some server problems last week, it should work now.

We need files to determine anything.

This is working as intended. BSP objects tend to be pretty dense in a scene. For example, if you create a flight of stairs and select all stairs, the screen will fill with almost solid lines from all the control widgets rendered. It may be a design choice you don't agree with and a better solution in the future may be possible, but it's not a bug.

Character physics are not related to shapes. The physics shape is a fixed size, due to the need to conform the the navmesh data. It may be possible in the future to manually adjust the size, or to have several navmeshes for different size characters.

Incomplete / not enough information to reproduce.

Please do. It's confusing to have to read through threads for multiple bugs.

If you post a full example we can then correct your code.