Josh

Try this: http://www.leadwerks.com/werkspace/page/Documentation/le2/_/tutorials/rendering-lights-r384

Some of the colors seem way too neon, but then some of the ground textures have really nice and sharp details. I'd like to see more of this.

Yep, we just store color in the unused fourth column of the entity's 4x4 matrix when it's sent to the GPU.

I won't promise that because you might have the android version you can use yourself by then, but I am certainly interested in testing performance.

It might be difficult to separate the renderer from the rest of the engine. It might be possible to do this once, but I would not want to continually update it with features I add to the engine. We compiled for android with no code changes needed, so I think you will find it builds pretty easily for ps3 or whatever else. I can't say for sure, but it's on four operating systems already.

You'd get a TOUCH_UP event with index 1 (it starts with 0) and know the second finger left. The next finger down would become the second, because that would be the first empty slot.

I had a little fun with iMovie with this one. Don't be a hater.

I've implemented multitouch input on iOS, and gave Aria the information he needs to do the same for Android devices. Multitouch is an interesting input method. Each "touch" has a beginning, some movement, and an end. To handle multiple touches, they need to be persistent; you need to keep track of which touch is which. This is a little weird if you're coming from a mouse and keyboard paradigm. On iOS, you have a pointer to a UITouch object, and on Android it's a jObject object (I think). I opted to make touches correspond to fingers...the first touch is touch 0, the second is 1, and so on. I set it to handle up to five touch inputs simultaneously. (Interestingly, there doesn't seem to be any limit on the number of touches a device can handle at once. At least, I tried ten, and ran out of fingers to test any further.) Touches emit an event which you can get through the event queue, or you can supply an event callback hook. Alternatively, you can just call GetTouchDown(), GetTouchHit(), GetTouchX(), etc., which work the same as mouse input. The only difference is you need to supply an index for the finger number. To implement zooming, I just checked to see if finger 0 and 1 are touched, then found the distance between the two fingers. I'll have to write some detailed tutorials about this, but until then here's my code: while (PeekEvent()) { Event event = WaitEvent(); Print(event.Debug()); switch (event.id) { case EVENT_KEY_DOWN: if ((event.data)==KEY_ESCAPE) { return false; } break; case EVENT_WINDOW_CLOSE: if (window==event.source) return false; break; case EVENT_TOUCH_UP: numTouches--; break; case EVENT_TOUCH_DOWN: numTouches++; Print("Event.data = "+String(event.data)); Print("Event.X = "+String(event.x)); Print("Event.Y = "+String(event.y)); Print(""); touchposition[event.data].x = event.x; touchposition[event.data].y = event.y; dx = touchposition[0].x - touchposition[1].x; dy = touchposition[0].y - touchposition[1].y; touchdistance = sqrt(dx*dx+dy*dy); break; case EVENT_TOUCH_MOVE: if (event.data==0) { if (numTouches==3) camera->Move(-(event.x - touchposition[0].x)*0.01,(event.y - touchposition[0].y)*0.01,0); touchposition[0].x = event.x; touchposition[0].y = event.y; dx = touchposition[0].x - touchposition[1].x; dy = touchposition[0].y - touchposition[1].y; d = sqrt(dx*dx+dy*dy); if (numTouches==2) camera->Move(0,0,-(touchdistance - d)*0.01); touchdistance = d; //Print(touchdistance); } if (event.data==1) { touchposition[1].x = event.x; touchposition[1].y = event.y; dx = touchposition[0].x - touchposition[1].x; dy = touchposition[0].y - touchposition[1].y; d = sqrt(dx*dx+dy*dy); if (numTouches==2) camera->Move(0,0,-(touchdistance - d)*0.01); touchdistance = d; // Print(touchdistance); } break; } } And here's the result in action:

The first object that happens to be in the list, which is random, will be turned first. However, both will be called before the UpdateWorld() functions exits, so when rendering occurs they will both have the same progress completed.

If you want to enable terrain shadows, just call EntityShadowMode() with the terrain entity.

I can't tell. My HTC Evo is capped at 30 FPS and gets 7-16 FPS with 14,000 ploys. My iPhone gets 60 FPS with the same, the max framerate. I think this is going to vary wildly depending on hardware.

I didn't set out to to that, but I can't think of any reason different platforms would have any trouble communicating over a network. Kind of scary that you could play on your cell phone against someone on their PC. I'll have to look closer at how network communication works on mobile devices.

idk!

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.