Josh

I think what happens is, by the time you have coded to that level, it's beyond the ability of new users to do anything with it. Instead of modifying and using your beautiful code, they will just end up asking for a lot of features to be added, and then you're coding someone else's game for them. That's why I am trying to make the new engine have a lot of high-level functionality built-in. On top of that, you have the issue that 3 or 4 main languages are being used by the community, and any language you target will only be relevant to a fraction of the users.

One thing that really surprised me when I started with 3D was how unusable most of the free 3D stuff on the internet was. I had no idea how much more care it took to produce good real-time 3D models.

This is a very Zen-like question.

The entity type will be terrain, but we should add something like a vegetation index so you can tell better.

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.