Josh

Thanks.

All you have to do is create the hitbox skeleton in a modeling program, use the same names as the bones, and then load it in code and use FindChild() to parent each hitbox to the appropriate bone.

Create a skeleton for the character using simple shapes. These are sometimes called "hitboxes", and you'll sometimes see a lot of hilarious gamers criticize a game with phrases like "omg teh COD engine sux, the hitboxes are no good" (when they can't hit anything aiming with their console controllers). Anyways, your thigh object should be parented to the thigh bone, forearm to the forearm bone, etc., so that they move with the skeleton's animation and form a very low-detail approximation of the shape of the body. These meshes are used for picking. Even if the engine did vertex weighting on the CPU, you would still want to use hitboxes because it's so much faster to test a ray against simple meshes rather than a mesh with thousands of triangles.

Leadwerks Engine just displays whatever the normals in the file are. Nothing less, nothing more.

It's probably possible to set up CodeBlocks to work with Android, but we always do things the official/most common way that Google recommends. Yes, the PC market is so bad that cell phones often have better graphics performance. At least with an iPhone you've got a minimum graphical capability that is decent. I'm afraid the Android market has a lot of low-quality garbage, just like the PC market. Manufacturers want to cut costs, and so they put a cheap graphics chip in the phone, and think no one will notice. Meanwhile, Apple puts a good GPU in every phone, regardless of whether the user will actually need it. It's just like the low-end PC market. "Why would you want a GPU? Not everyone plays games. A work computer doesn't need one." My HTC Evo, for example, gets 30 FPS max (it's a known hardware design issue) and it gets 7-16 FPS drawing a single 15,000 poly model. Meanwhile, my iPhone and iPad render the same thing with no performance cost, running at the max framerate of 60 FPS. The Evo was marketed as "the iPhone killer" (for a month, anyways) and I had no way at the time to know how its graphics performance would be. If you buy an iPhone, you don't have to worry about making the right choice; everything will be reasonably good, even if there's an Android phone out there that is better in one area or another. This is why I think HP had the right idea when they acquired WebOS, but I guess all those plans went out the window with Mark Hurd's departure. I don't know what it is about PC and cell phone hardware, but it seems like pure competition destroys customer choice and quality. Maybe it's just the inability of the market to know what they're really buying. It doesn't help when hardware manufacturers obsfucate the performance of their products, like how CPU makers no longer advertise their clock speeds and GPU makers don't specify the number of stream processors their cards have. Now Intel just rebrands the same stuff over and over (yes, I know the architecture changes, but is that really that big a deal?), and they act surprised when no one is motivated to buy their processors. Even nerds have a hard time getting excited over a Clarksdale, Sandy Bridge, etc. Clock speeds aren't perfect, but at least it's an arbitrary indicator of performance.

For Android, you also have to create makefiles. But once everything is set up, it's simple to compile. The emulator doesn't support OpenGLES2, so you will want to run the app directly on your device. You can do this from Eclipse. I recommend developing your game on Windows, and then just build it on Android. Don't try debugging C++ code with Eclipse.

I hope not. Android compiling of C++ is pretty difficult. You have to install the Java SDK, Eclipse, the Android plugin for Eclipse, Android SDK, the NDK, and CygWin. Lua is a much simpler path since you don't have to install any third party compilers or SDKs.

It's not a problem. You can even program Lua on the iPad.

I got touch input and text rendering working on Android. Happily, I have not encountered any issues with different behavior on any tested OpenGLES devices, including iOS. The framerate on my HTC Evo jumps around quite a bit, which appears to be an issue with the Java garbage collector. Framerate on iOS is a solid 60 FPS, so we should be able to get this sorted out. Here's a video: http://www.leadwerks.com/werkspace/page/videos/_/leadwerks-engine-3/android-progress-r100 I also discovered that LuaJIT for ARM processors was recently released. This is fantastic because it means Lua script will run on Android and iOS at about the same speed as C# and Java. I knew this would eventually be supported, but I didn't know until yesterday it was released about a month ago. We've had a surprisingly strong positive response from developers over our support for mobile platforms, especially Android. This feedback has been coming from both the Leadwerks community, as well as other places like Google+. My estimation is there's probably ten times as many people interested in mobile game development as there are interested in PC development. Since Android especially is going to be an important platform for us to support, I've decided to implement an OpenGL 2.0 renderer, and make that a higher priority than the OpenGL 1 fallback I originally planned. Leadwerks Engine 2 used OpenGL 2.1, but this will be a much simpler renderer that just matches the functionality of the mobile renderer, so you can get the exact same pixel output across all supported platforms. Expect to see something about as capable as the Half-Life 2 engine. Of course, the OpenGL 3.2/4 renderer will still be available on Windows. At this time, Apple's OpenGL 3.2 drivers are not functional, but when they are it will be no problem to enable the OpenGL 3 renderer for Mac computers as well. (Tim Cook: Please see bug report #9896622.)

You can't automatically optimize animated models, because there's no way to tell which limbs are wanted and which are not. Just make sure you aren't doing anything crazy in 3ds max and it will export whatever you have. If you aren't sure what's going on, check the GMF file out in the model viewer.

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.