Josh

It is possible to do what you describe with the existing command set. There's a tutorial on transparency and refraction. If you can demonstrate the issue, I will look at it, and make some enhancements to let you control the tire slippage more. No one has attempted a serious racing game yet.

I'd prefer to stick with plain Lua for now until we are certain everything is stable. But yeah, we'll add it eventually, with an option to toggle the compiled code on and off.

In many cases, once they saw what the low-end version would look like, they would suddenly lose interest. Version 3.0 will run on all computers. The reason for this is the prevalence of netbooks and cheap laptops. Although high-end hardware is getting better and better, average computer speeds are actually getting slower. In three years, the average computer will be a $99 netbook bought at Wal-mart. It seems Moore's Law is a normal curve.

My bad, it's LuaJIT version 2.0.0, and the 64-bit version is up to 102 times faster.

Use the entity collision callback.

You can have more than one terrain in a scene and modify the shader to handle the offset you want for the position. You can probably store the position in the entity color, or I can upload the terrain matrix. I didn't write it to support rotation because an extra mat4 multiplication for every terrain vertex seemed unnecessary and wasteful, and terrains have a heck of a lot of vertices.

Yeah, actually it is a lot more: 4096 * 4096 * 2 bytes = 33 mb (heightmap) 4096 * 4096 * 4 bytes = 66 mb (normal map) 4096 * 4096 * 4 bytes = 66 mb (alpha map) 165 mb for a 4096 x 4096 terrain. Two of them would break most GPUs. Paging smaller terrains would involve a lot of problems. Your terrain disappears from memory, then any physics objects out of range fall through the terrain. So now it's not just terrain that has to be paged, it's all models. Then someone wonders why a target entity suddenly no longer exists when it gets released from memory... You get the idea. Then there's issues with floating point precision. If you go much further from the terrain than what the largest terrain size allows, you will start seeing jittery motion due to floating point imprecision. Then there's vegetation. It's fast to load, but it still takes some time to populate the data structure. And considering I just got it to work without bugs, I am not keen on complicating that system right now. It's certainly possible, but I don't think right now is a time I should be making the internal workings of the engine more complicated. Now maybe if the height data was left in system memory, and just the textures were paged, and the engine was switched over to use 64-bit floats, then we might have something that could be implemented right. So I will consider this for version 3.0. You'd still be limited by other factors like the number of objects you can store in memory, and the GPU memory their textures would take. So I suppose a paging system for static entities would be needed too, and a mechanism to specify a "paged" entity...

http://leadwerks.com/werkspace/index.php?/blog/1/entry-196-lua-debugging/

There is a collision object function you can use with models. See the basic Lua tutorial.

Not cross-platform code, because that is being done in C++, but I will be using version 2.x to develop new ideas before "engraving" the code in C++ for version 3.0.

Until now, we haven't really had proper debugging info when a crash occurs during execution of a Lua script. Thanks to some previous work TylerH did with Lua, a conversation with him revealed how to easily add debugging info into the editor and script interpreter. (Incidentally, the Lua integration was Tyler's idea to begin with!) Here's a shot of the Script Editor catching an engine crash and displaying the script line the error occurs at. This is a crash that occurred in the engine, not a Lua compile error. This will make Lua a more viable alternative to other programming languages, and it will make it easier to use Lua as an extra enhancement to a C++ or other program. The integration of LuaJIT with the engine also speeds script execution up, a lot. Performance tests of the LuaJIT beta 2.0.0 reveal it to be up to 102 times faster than standard interpreted Lua. (Lumooja first told me this, and I thought he was exaggerating, but you can see for yourself.) And regular Lua was already faster than UnrealScript! In the future, I think we can look forward to having a nice display showing all the variables in your script program in real-time, and improved debugging tools.

I don't think modern hardware is fast enough to do this, but if you want to try it look at the SetColorBuffer() comamand in the wiki.

Not sure if anyone has tried it, but the functionality to do this is there: http://www.leadwerks.com/wiki/index.php?title=Buffers#SetColorBuffer

The water shader I wrote only works with a vertical plane, but it is possible to modify the shader to work with any arbitrary plane.

Are you trying to make a dynamic cubemap, or just add an existing cubemap to a material?

So few games would use this, and even fewer indie games would. STALKER and Crysis don't even need something like this. So my recommendation is to work within the constraints of the existing system to make your game. The only alternatives are to spend months writing an alternative terrain system that won't be supported and won't integrate well with our physics and vegetation, or pay me to spend 6 months working on this.

Our vegetation rendering system already renders much denser vegetation than speed tree, so I would rather just use it as a modeling program.

It's not that simple. Then I have to add support in the editor for multiple terrains. Each of the largest terrains requires about 50 mb of texture data on the GPU. Okay, now times 9, that exceeds the GPU memory of almost all cards. So a paging system would be needed, but that is no small task.

I hope you make use of physics like Penumbra. That would be perfect. Hurry up and make this game, I want to play it! B)

If someone makes an awesome game with a AAA engine, and the company really likes it, I'm sure they'll find a way to work something out. That's always been the case. Counterstrike is another example. However, it's very hard to make a total conversion mod starting with an existing game. That's why a lot of people prefer using systems that are designed exclusively to be general-purpose game engines.

The simplest thing you can do is set the meters per tile to 2. That will still give a good resolution, and you will quadruple your area, if it is set to 1.0 right now. Making an infinite/paged system is perfectly possible, but the problem is it would severely restrict the engine for every game that wasn't designed to do that...which is the majority of games. It would involve a lot of constraints for the user, and there's not enough people who want to make a game like this enough to pay a lot extra for such technology. So I could devote all my time to designing a beautiful infinite system that would be really awesome, but I'd go broke doing it. The terrain shown there is 1/4 the max terrain area, by the way.

Just call SetBuffer() and render.

Awesome model.

I think it's neat. We've always had "free" mod SDKs available for the big engines since the days of Quake 1. Tripwire published Red Orchestra using the UT2004 engine, with no licensing fees paid up front to Epic. It's always been an option for developers, but we've always had users who come to us for a simpler more straightforward solution. However, I think 100,000 free users over four months isn't much to brag about. By the same logic, Leadwerks gained 15,000 users in two weeks, because they downloaded our free demo. I'm not too keen on a free SDK version for two reasons: -It isn't free to us. It costs us resources for supporting the free users and the increased demands on our site. I'd rather use these resources to improve the product for you, the paid user. -It devalues the paid user's experience because they get surrounded by a lot of low-quality users. This is all a result of console technology. Because the large companies are restricted to console hardware, which is much lower-spec, but more profitable for them, that leaves the high-end PC market to people like us. Now they are getting worried. They don't want to pursue the high-end PC market, but they also don't want us doing it. B)

He may in fact be a registered developer. I only have forum names for about 3/4 of the orders on record.