Josh

I can tell you right away what the problem is. It says about 3000 batches are being drawn! Just opening one model, we see extreme inefficiency here. Lots of unnecessary entities, and lots of unnecessary surfaces on each. This turns what would have been about four batches into about 40: I ran the gmfprocess tool and then the map had less than 500 batches, and the framerate more than doubled: http://www.leadwerks.com/werkspace/files/file/140-gmf-optimizer/

If you want super-realistic driving mechanics, you will probably want to implement vehicles with Newton yourself. If you want to make a driving game that isn't a realism simulator, the built-in vehicles will work fine.

C++ code is identical, and like the engine itself, a "Projects" folder will be created, within which a subfolder is created for every platform, i.e. "MyGame/Projects/VS2010", "MyGame/Projects/iOS", etc. In each of these a project for XCode, VS, Eclipse, etc. are created from a template. Lua projects are simpler, since no compilers or SDKs have to be set up.

The editor will have a "Publish" dialog where you can create packages for supported platforms.

I helped Vetal with his problem. It's usually very easy for me to determine what's wrong, but I haven't seen your scene uploaded, unless I missed it. 315 entities is not a lot at all, but it's all just speculation until I take a look at your demo and the actual scene in the editor.

I just noticed you are using occlusion on a lot of objects. The occlusion test itself has a cost, so you only want to use it when the savings will be significant...by default, only animated meshes and lights use occlusion testing. You should disable this on little things like this, because each tested object requires a single-pass draw call. During development of the Zone scene, we already dealt with all the bottlenecks you are experiencing. If you follow my tips, you will be able to get optimum performance for this fantastic scene.

Okay, first of all the scene looks great. I love how you blended the cliffs with the terrain, and the coloring and use of coronas is great. Your flickering light script was the main culprit. Replace the Update() function with this: function object:Draw() local r = self.random and self.random or 0 --if math.random(1,1.5) == 1 then r = object.light:GetRange()-r else r = object.light:GetRange()+r end --object.light:SetColor(r) --if self.maxrange~=nil then -- if object.light:GetRange() > self.maxrange then object.light:SetRange(self.maxrange) end --end --if self.minrange~=nil then -- if object.light:GetRange() < self.minrange then object.light:SetRange(self.minrange) end --end end The second thing that jumps out at me is the high entity draw count. It's drawing almost 4000 entities each frame, which is more than our Zone stress test. Some of your models have a lot of redundant surfaces. This model, for example, has six surfaces and it only needs one. That means if you would otherwise be drawing 200 instances for this object (just an arbitrary number) with the extra surfaces, you are now drawing 1200 instances, and six times as many reference surfaces! Fortunately, we have a little tool to make this easier, but be careful because this will collapse all models: http://www.leadwerks.com/werkspace/files/file/140-gmf-processor Finally, building scenes out of lots of individual parts is less efficient than loading bigger chunks of scenery. I understand that it is easier to work with, and you might be able to get away with it if you collapse your models like in the previous point I made, but just keep in mind more entities overall = slower: BTW, that time of day script is looking fantastic. It's come a long ways since the videos I first saw.

It's because people who want script don't actually want to code, they want trial-and-error game making with some premade templates. That's the plan. There's the scripts for people who want to work at that level, and it can be used without interfering with direct programming. Remember when I first implemented Lua and people didn't understand how it could work together with C++, and then it turned out really simple? It's like that.

It doesn't have thousands of bones, or something like that does it? You should post the model in question.

Welcome to the not so wonderful world of garbage collection. Remember, it makes programming easier! In BlitzMax, you have to call FreeEntity() AND set all variables that refer to the entity to Null, in order to delete it entirely.

http://www.nvidia.com/Download/index.aspx?lang=en-us

The NDK C++ tools are pretty awful. No debugger, so I don't recommend developing your app on Android. Just develop it on Windows, Mac, or even iOS, and compile for Android for distribution. It's obvious to me that whoever supports pure C++ the best will be a winner. I have a lot of C++ criticisms, but the way I see it, Java and Objective-C are just as poorly designed, and have the additional disadvantage of not being widely supported. You also get the benefit of weeding out the more amateurish programmers. We all end up using C++ anyways to bypass these "wrapper" languages. So if Android eventually moves to pure C++, preferably with integration in MS Visual Studio, that will be a good move for them. If Nintendo wanted to make a big comeback, they would make a C++ SDK for free or cheap and have an online store like the App Store. I mean, for years all the console devs did the exact same thing with a highly restricted SDK, and the first thing that comes along and does the opposite blows them out of the water (iPhone).

It would be hard to set up a game without having the new API to code with, but I think you will be able to port Lua games with Leadwerks Engine very quickly to the first beta of Leadwerks3D.

After some initial difficulty, Leadwerks3D is now running on Android, with the exact same code that runs on iPhone, iPad, Windows, and Mac. A big thanks for Aria for all his help and expertise with the Android platform. This means Leadwerks3D is now running on all platforms we intend to support at launch, and it can be easily extended to support new ones. To celebrate, here's another cartoon I drew:

Lua will run on iOS and Android. C# should work as well, although I have not tried it yet. You don't have to touch Objective-C unless you want to. We just use it as an entry point, and then execute our C++ code.

I got word back from our Android programmer about the likely cause. It's great to have someone around who is a counterbalance to my strengths and weaknesses as a programmer.

You could always put two enormous bodies on either side of the plane you are interested in allowing, and constrain objects that way.

In Leadwerks3D you can assign any script or more then one script to an entity. In Leadwerks Engine, you will need to select the script code you want to copy, type Ctrl+C and then open the other model's script and press Ctrl+V.

For bullets I would perform a raycast each frame, and use AlignToVector to orient the visual mesh.

Please file a report in the bug tracker if there is a reproducable problem.

It's a built-in Lua command, not C++.

Here's the code: Print("context = "+GetObjectAddress(context)); Print("Graphicsdriver: "+GetObjectAddress(graphicsdriver)); Print("GetGraphicsdriver: "+GetObjectAddress(GetGraphicsDriver())); Print("ActiveGraphicsDriver: "+GetObjectAddress(ActiveGraphicsDriver)); Print("context->graphicsdriver: "+GetObjectAddress(context->graphicsdriver)); Print("context = "+GetObjectAddress(context)); Here's the output, running on an iPhone 4: context = 0x06921400 Graphicsdriver: 0x0694e800 GetGraphicsdriver: 0x0694e800 ActiveGraphicsDriver: 0x0694e800 context->graphicsdriver: 0x0694e800 context = 0x06921400 Here's the output, running on an HTC Evo 4G: 08-30 11:34:02.319: INFO/LEAndroid(8250): context = 0x00270168 08-30 11:34:02.319: INFO/LEAndroid(8250): Graphicsdriver: 0x0026f0d8 08-30 11:34:02.319: INFO/LEAndroid(8250): GetGraphicsdriver: 0x0026f0d8 08-30 11:34:02.329: INFO/LEAndroid(8250): ActiveGraphicsDriver: 0x0026f0d8 08-30 11:34:02.329: INFO/LEAndroid(8250): context->graphicsdriver: 0x30203a72 08-30 11:34:02.329: INFO/LEAndroid(8250): context = 0x002704dc On the Evo, even printing out the object hex address twice will result in two different values: Print("context = "+GetObjectAddress(context)); Print("context = "+GetObjectAddress(context)); Nothing else to say at the moment. Will let you know when I find out what is going on. B)

This is not possible.

From terrain.frag: float slope = asin( worldNormal.y ); slope = 90.0 - slope * 57.2957795; You may have to fiddle around with it a little for rads/degrees.

Sorry for the fierceness of my earlier posts, I've been very irritable lately due to some technical challenges. I'm more inclined to do this kind of thing for the Leadwerks3D documentation, because it's planned to last for a long time.