Flexman

Great 3rd person animation. I'm quite jealous of that, one of those things on my to-do list I keep putting off and might drop. That looks pretty slick.

It's the shadows that are expensive with point lights. Don't use shadowing with your point lights unless you need them, or simply turn them on when they are in a useful range. Combined with point of interest light sources (ones used to generate shadows or effects) you can mask the absence of shadows from every light source well. Game programming is all tricks. We use dozens of the things every frame and they perform great (and these are moving).

It's a single plane that follows the camera around. If you need to have separate bodies of water what we did was make a mesh and apply a water surface material to it. But this prevents the use of buoyancy physics unless you're OK in your level design to change it when you get close to one of these water body entities. Fiddly.

I'm not allowed to use my Mac anymore, the kids took it over to play World of Warcraft :/ I too had a heck of a time sorting out the provisioning on the device and getting the certificate accepted. I aim to put together a simple 3rd person on-rails tank shooter for LE3 mobile, have the assets ready to roll out for that one. Little bit more complex than a spinning cube. I put together a little test in Unity that allows you to change play styles (weapon mode) by changing the screen orientation, hopefully this event will be available to LE3 but it's not a big deal. A cool thing to do with your cube is to get some audio sampling done and blow to spin it.

Generally for single applications using SLI you need to run in fullscreen (some driver hardware combos will work for windowed applications). But you're trying to do something different as understand, use a single GPU per application instance. As far as I'm aware OpenGL lacks control over things like this. The NVAPI might help out. I saw an extension that is supposed to set GPU Affinity in OpenGL (DirectX can do this).... http://www.opengl.org/registry/specs/NV/gpu_affinity.txt You might also want to have a skim through nVidia SLI Best Practices document... http://developer.download.nvidia.com/whitepapers/2011/SLI_Best_Practices_2011_Feb.pdf

Understandable. The techniques however are solid and used in other engines (OpenScenegraph, Infinity and Outerra) and games (FSX, X-Plane) all these are referenced in the text. Elliptical clip-maps and camera relative rendering (they call it Rendering Relative to Eye) is used in all manner of simulations where any large scale world is required. What's new are the techniques to do it on the GPU and code you can play with instead of read about in research papers. But if you're looking to create some really advanced terrain that can go from ground zero to outer space this is a good place to get a broad view of how it's done in Google Earth and NASA World Wind. I know some of the references used in the book, we were in negotiation with one source, small community. I dare say it could all be optimised and improved for even better game performance. Google Earth runs fine on the iPhone so it must be pretty efficient. On the whole, it would be nice to to choose what kind of terrain rendering to have, like Ogre3D, might be an option. From SimpleTerrain to VoxelTerrain to LargeTerrain supporting elliptical worlds, huge co-ordinate systems and streaming. We get all the benefits of the Leadwerks pipeline and code the way we want. Just something to consider since everyone seems to have their own ideas on what they want to do. Not everyone needs terrain so a separate plugin/DLL, this would reduce the disk footprint too.

I'd like to be able to plug in a terrain system that deals with scale and accuracy issues. Like the one dicussed in this book... http://www.virtualglobebook.com/ Slideshow presentation... http://www.virtualglobebook.com/Under_the_Hood_of_Virtual_Globes.pdf Example chapter... http://www.virtualglobebook.com/3DEngineDesignForVirtualGlobesChapter1.pdf I've been playing with some of the example code and it's very efficient. Itching to try some flight physics with this.

Indeed. It's good for consoles and the design tools are excellent but resource wise Leadwerks is way better having used both.

Silverlining Cloud/sky rendering by Sundog software... http://sundog-soft.com/sds/

Where's my 3D monocle when I need it? Pretty snazzy the way you can take existing data and re-visualise it. I love that kind of stuff.

Whoops, just saw the original post date Well it's good to just chit-chat once in a while.

Presentation is everything. I reckon you could make a pretty compelling game of PONG if you disguise it well enough. Look at Angry Birds, tell me what ancient game that is dressed up? Turn Pong into a small planet or moon with low gravity, the ball is a nuke or grenade that 'heats up' and cools making it possible to kill your opponent in amusing ways. Take a simple idea and throw progressively more stupid ones till you find one that sticks and motivates you. With Leadwerks you can put together a simple tower defence or RTS, or even a 2.5D platformer as all mentioned above. The HARD part is finishing, no matter what game you decide to make, you get to about the 80% completion mark and then you find the other 80% of polishing work left to do. Just my 0.02 euros.

Such a cool extension, had to tweet that one.

Well if you have a mesh for the head, go one step further and add a bone for the jaw then experiment moving that bone to get your head to 'talk'. I've seen a few commercial products for doing this. I remember something for DarkBasic called DarkVoices that was a system for creating lip-sync files, there's a video showing how the model was created, this might give you a head-start on how to approach this. http://www.thegamecreators.com/?m=view_product&id=2107

At first I thought you meant Morph

Question, does it need to run on 3 different display devices? I use a 3840 x 1024 split over three monitors using the Matrox Digital TrippleHead2Go which makes the video card think it's plugged into one large physical display device. The Matrox device splits it into 3 DVI signals. Combined with display software that can warp your screen output to match the geometry of any curved screen... Well here's a video of a guy who built his own collimated display using reflective mylar shaped by a vacuum... He's using the Matrox Tripplehead on 3 projectors.

One of the elements in the DirectInput DLL I made is a feature that detects the OEM flags of a device using GetDeviceInfo(DIDEVICEINSTANCE) The reason for this is that I need to support some some LED features on the device. A small OEM library is provided to support these. The code snippet below is just an example of how to pull out some manufacturer info for a specific device instance (joystick). CONST DWORD VID_LOGITECH = 0x046d; CONST DWORD VID_MICROSOFT = 0x045e; ... DIDEVICEINSTANCE device; /* MUST set these for any DI structure before use or bad things happen */ ZeroMemory(&device, sizeof(device)); device.dwSize = sizeof(device); if (FAILED(hr = joystick->GetDeviceInfo(&device))) { return hr; } ... ... DWORD vidPid_ = device.guidProduct.Data1; this->vid = LOWORD(vidPid_); this->pid = HIWORD(vidPid_); if (VID_LOGITECH == this->vid) { /* do some OEM stuff here */ if (PID_G940_THROTTLE == this->pid ) { /* the product ID matches special hardware so do something here */ } } I don't have a problem per say, I'm more in deed of reassurance and guidance. The extras library for LED control is provided 'as is' by Logitech and compiled using Visual Studio 2008 however since I'm working with a more recent (VS2010) editor I get the LNK4099 error. Now I can get it to link by changing the project options [ LINKER > Debugging > Generate Debug Info = "No" ]. I think it's complaining that the object data in the supplied library isn't in a format VS2010 likes. It seems to work OK and I can set all the special lamp switches, LED colour and all the joystick functions no problem. Even multiple devices (I have 3 HOTAS systems plugged in at the same time, that about 1,000 UKP worth of flight simulation controls). And I'm not seeing any problems functionally. From the online searches I did on this error most people say DONT without explaining why. Can it seriously be that big of a problem in a release build? Logitech don't supply the source to rebuild the library, it's provided 'as is'.

That's pretty cool. You could use that for the build-up of crud/mud and other things on a car body or window. For bullets, damage and fire effects you might want to look into "Glyph Bombing" http://www.yaldex.com/open-gl/ch10lev1sec6.html I haven't tried an implementation in LE yet.

Blimey. The best thing since sliced bread for scene loading. What is?... IntPtr CreateCubemap(int width,int height)

It will be nice to have easy access to a variety of scene stats for rendering and memory usage, profiling on these devices can be important.

Yes, that's how I did it originally, pivot points all over. In practice it doesn't work out too well. When players have tripple-head devices (or even 5 screens with Eyefinity setups) things can still get clipped. What looked good on one setup was clipped on another, it became a pain adjusting things to work on different display sizes. You're dealing with objects that have vital buttons arrayed around the outer edges where any form of clipping renders the instrument near useless. So yes good in theory, practice not so much :/ For tutorials it's handy to be able to script "show me this instrument" or "this switch panel" and not have to setup camera positions, just add the object name.

That might work in a blank scene like an editor. The problem is that the camera is in a busy cockpit. The goal is to have a hotkey move the camera to quickly look down at different parts of the cockpit up close. My chosen method is to dolly the camera backwards until two (or more) objects, in this case two screens, fill the viewport. The solution should be is a simple triangle problem. targetAABB = combined AABB volume of required entities. bboxW = (targetAABB.w * 0.5) / tan(game.scene.camfov * 0.5) ; bboxH = (targetAABB.h * 0.5) / tan(game.scene.camfov * 0.5) ; dollyZ = max(bboxW, bboxH) ; The camera is positioned at the centre of the TargetAABB volume and dollied backwards by "dollyZ" camerapos = Vec3(targetAABB.cx, targetAABB.cy, targetAABB.cz - dollyZ); For the most part that works if the screen resolution/aspect ratio is square. HOWEVER... I need a third step, adapt it for the current aspect ratio. This is where it falls down. If the screen is 3840x1024 pixels with a camera FoV of 120 degrees (a letterbox shaped screen) the top and bottom of the objects are off screen. Like this... I'm scratching my head on how to cram the aspect ratio into this. Changing the FoV to solve this is not allowed. *update* OK. Seems if I fudge the following... aspect is screenwidth / screenheight bboxW = (targetAABB.w * aspect) / tan(game.scene.camfov * 0.5) ; bboxH = (targetAABB.h * aspect) / tan(game.scene.camfov * 0.5) ; dollyZ = max(bboxW, bboxH) + 0.05 ; It seems to work. 0.05 is added as a little extra. The result for our near worst case looks like this... Now I have to hide the joystick as it's getting in the way of the virtual cockpit raycasts.

We'll find a way to drain that suckers battery in minutes, just you wait Unity iPhone has a lot of dead weight attached too, it will be nice to work on some of the the parked mobile projects we had. I don't see having an extra texture conversion step for iOS as a problem at all. DDS is an n stage process so running a different tool for iOS seems like 6 of 1 and half a dozen of the other.

I was wondering if any of you smart chaps have an idea on how to position a camera so that two entities (or more) are always visible? Taking into account varying screen resolutions. In 3DS MAX this would be a "zoom to extents of multiple objects".

Red Ocktober. Well done, that works brilliantly. I hope Metatron (always makes me think of Zone of the Enders) can help you update it, that would be a really nice thing to do.