Josh

Probably the biggest inconvenience we have had was caused by relying on the serialized physics files that change format occasionally. Newton 2.20 is stable and supports everything I want, so I don't see any reason to upgrade if a newer version comes out. In version 3.0 we will have our own .phy format that doesn't change, and I don't plan on upgrading to any new versions of Newton for LE 2.x. There are only three open issues in the bug tracker right now, BTW.

What API changes have their been in the last 6 months? Entity view range changed, because the new system allows much greater distance culling optimization. The sky background color started affecting the sky in 2.32, so you can adjust the background to make day/night changes. The "Render" script function was renamed to "Draw" to match the internal functions, again a consequence of the scenegraph system (cameras have a Render() method, and all entities have a Draw() method, so you can see why this is). It's always hard to make a decision that effects existing code, but these had some significant benefits, so it was deemed worthwhile. The internal optimizations in 2.32 have made it a difficult release, so you may want to stick with 2.31 a while longer. The end result will be much better for your games, which is what I care about most. I can understand if you would feel disoriented at first, especially when 2.32 was first released with some bad bugs that had to be fixed. For the rest of 2.x, all I have planned is bug fixes and minor feature additions. Once all bugs in the tracker are resolved, I consider 2.x finished, and any features on top of that are just icing.

I knew focusing on the internal scene management was going to produce some temporary bugs with no immediate visible gain for most users, but I did it anyways because it will allow your games to run a lot better when they get big and complex. The improvements made in 2.32 are expressly for the purpose of allowing better published games. Version 2.x is not being dropped or discontinued. I just spent three months on stuff that ensures you can make large games with 2.x. I spend about one weekend a months twiddling around with version 3.0 code, and I am asking for input well in advance so I can have it available when I am ready to start.

+1 I also think an editable hierarchy (just for organization) and checkboxes would help.

Yeah, you can actually just edit the script to raise it. The only reason is it limited is that if you make the numbers too high, the slider gets hard to use.

The only difference is the amplitude and texture scaling of the effect. The second shot uses a different texture for the water normal.

There's nothing wrong with the refraction effect. If you want it to be different than it is now, you need to edit the shader yourself. It isn't hard to change the amplitude of the refraction and the scale of the refraction texture mapping, but it's your responsibility to change if you want the look to be different. I can't say when 3.0 will be available because I don't know when production will start, because there are factors outside my control.

Tessellation makes so much sense for waves. I know a way to get really fast high-quality waves, but we're going to have to find some company that writes fluid simulations and have them make the data for us.

Is the second image a photo or an in-game shot?

No. 3D waves will be implemented in version 3, using hardware tesselation.

Turn off SSAO and godrays.

I'm not sure why people think Leadwerks 3.0 will only be programmatic or point and click. It won't be just me working on it. I will probably end up writing very little of the code, and spend most of my time instead documenting how I want the programmers to write it. When you see how it works, I think you will understand how the programming, script, and design mode work together. There's the step of programming game behavior, but there is also game production, where you are setting up interactions that are unique to one level. That's a stage we haven't really gotten to, and this will make it easier to achieve that, without taking away your freedom to focus on more basic aspects.

At that point, I would probably assume you are a competent programmer, and are able to copy and paste code. The whole point of multiple scripts is for people who aren't able to understand what a block of code is doing, and copy and paste it without causing a problem. To you and me this may seem completely trivial, but if you think about the last time you looked at a wall of incomprehensible code, it makes sense. Not saying Rick is in this boat. I think he has seen systems like this in action, and they probably are fun and nice to work with. So basically this moves the burden of using copy and paste from the novice to the expert. I don't really see this script system working with class hierarchies, and I think that is okay. AI is probably the only real use of hierarchical classes I would use, and how hard is to make some basic AI functions and call them from another script? Traditional object-oriented programming is great for a game engine, but I think it breaks down in higher game logic design, and becomes more trouble than it's worth. You can get the same benefits without making derived classes.

I promise we are not gimping the engine to make a point and click game maker. The plan I have designed makes the engine easier and better for both programmers and non-programmers, and it allows them to work together. C++ programmers will still be able to write their games. Script programmers will be able to create reusable components designers can use. Designers will be able to drag and drop parts to make a game. It's about designing a cost-efficient workflow for groups of people to produce games, instead of making a game engine for idiots. Typically you would have one or two programmers designing the basic game, a handful of script programmers designing components, and a lot of designers making the game levels. John Carmack doesn't program every single monster scare in Doom 3. He just provided the basic framework, and the level designers planned the action.

That's correct.

shaders.pak\postfilters\ssao.frag.

It's been done: http://leadwerks.com/werkspace/index.php?/topic/730-video-to-texture-via-libtheoraplayer/page__p__6458__hl__theora__fromsearch__1entry6458

Adjust the "General>Order" property of each road to control what order they are drawn in. Use the "Road>Terminate" property to make them blend smoothly.

http://www.leadwerks.com/wiki/index.php?title=TFormPoint

This includes a beta of Dave Lee's the Zone scene: http://leadwerks.com/werkspace/index.php?/topic/2065-lesdk-232-r5-link/ I had to use an alternative download method due to the problems we have had recently with large downloads.

http://www.leadwerks.com/sync/engine2.3/LESDK2.32r5.exe Enter your registration key for BOTH the user name and password.

Unless you post a program that demonstrates the problem, we're all just speculating about what the problem might be.

I'm not working on version 3.0 yet. I want feedback now so I can plan the tools for 3.0. I am working on version 2.32r5 right now.

If the vertex sway effect is used, the vertex color will not be visible in the pixel color.

That's the same as what I wrote above.