Tim Shea

If you aren't using a GUI framework, you can use a plane with texture coordinates to accomplish this. Any decent framework will have this option though. Leadwerks has a graphics engine, but no GUI functions built in, so you have to decide how to accomplish that.

Probably. I think the Math::Curve function does the same kind of thing. I just never noticed that function, so I rolled my own.

This is a good idea. The diffuse map from a terrain could be a good source as well. You definitely don't want a second view, since the minimap is not a view into your real time scene, it's just a component of your GUI.

No, you can't make the model a child of the pivot, because it will inherit all those little bounces from its parent. You have to manually copy the smoothed transform. My position code is sort of complicated because of some other objects, but this is how I smooth the camera orientation. Variables prefixed with an m are member variables. // Calculate the mouse movement Vec3 center = Vec3(context->GetWidth() * 0.5, context->GetHeight() * 0.5, 0); Vec3 delta = Vec3(window->GetMousePosition().y - center.y, window->GetMousePosition().x - center.x, 0) * mLookSpeed; mAngularVelocity = delta * mSpringFactor + mAngularVelocity * (1 - mSpringFactor); mOrientation += mAngularVelocity; mOrientation.x = Math::Clamp(mOrientation.x, -mPitchRange, mPitchRange); mCamera->SetRotation(mOrientation + mAngularOffset);

I have never played a game with a fully rendered minimap. That would be jarring I think. What you typically would want is just a sprite pane in your GUI system, with icons for each of the objects you're interested in, and a prerendered (probably stylized) image for the static map.

If you watch the value of the y coordinate for your character controller, you'll see that it is bouncing very slightly on the ground. This is common for many physics engines, although most will have a damping property that can reduce the effect if it's undesirable. Since we don't have a damping property, we can implement our own by using a pivot for the actual character controller and then applying a smoothed transform to the model. Obviously, the model should then have no physics shape itself. You will have to play with the smoothing factors, but it is possible to have a perfectly smooth first person or third person controller in Leadwerks. For my characters, I'm smoothing both the character controller motion and the camera offset, because the mouse pitch bypasses the character and can cause unappealing stutter as well. Edit: In fact, on a more general note, smoothing out just about any parameter will tend to give nicer looking results, from physics to animations to sound. In real life, everything happens over time, so things that occur without any transition in games tend to stand out.

I think buildings (and dynamic obstacles which do not themselves navigate) are intended to use the Prop collision type. Props should not affect the NavMesh, but they are dynamically handled when generating paths (at least, this is my understanding). I also would love to see the navmesh and character controller fleshed out (or even just exposed so they can be overridden) but given what you have to work with I think your best option is to manually avoid assigning destinations inside dynamic obstacles, and then just use the baked navmesh. Collisions between units are always an issue with A* pathfinding. You can google for some interesting solutions, e.g. crowd steering, but it isn't something that can really be addressed in the pathfinding algorithm itself.

I can't comment so much on the rendering aspect, but this week I was doing some profiling for the Wings project and I was able to get about 20 animated characters on screen, all with real time AI, perceptions, full physics, navigation, etc. at around 70 FPS on my laptop (nVidia 620m). This was an encouraging result for me, since we haven't even begun to profile in detail or really optimize. I haven't tried to push it to the upper limit.

Are you sure it's done that way is commercial games? Because I think if you just draw a line it's going to look wonky with a uniform thickness. As far as I can see from a quick search, it is not a line: https://www.google.com/search?q=resident+evil+laser+sight&espv=210&es_sm=122&source=lnms&tbm=isch&sa=X&ei=zaT3UsW-HY_poASa3YLADg&ved=0CAkQ_AUoAQ&biw=1360&bih=643#q=resident+evil+laser+sight&tbm=isch&imgdii=_ It has diminishing thickness, and a sort of noisy transparent texture applied.

Make sure you also include all the preprocessor definitions: WINDOWS;WIN32;OS_WINDOWS;PLATFORM_WINDOWS;DEBUG;_DEBUG;OPENGL;_WIN_32_VER; _NEWTON_USE_LIB;_LIB;_NEWTON_STATIC_LIB;DG_USE_NORMAL_PRIORITY_THREAD; %(PreprocessorDefinitions)

You don't have to link the dependency into your library, you just have to set the headers correctly. The end user of your library then links your .lib and any of its dependencies. We are currently using this techniques successfully for the Wings project on both 3.0 and 3.1.

There was some debate later in the thread about whether this was necessary. I'm not sure what the final decision was. In the event it doesn't get added, you could probably throw some JSON into a property and then use a parser if you have a complex format.

Switching to static didn't fix it, so I tried looking at the shaders. I noticed that the issue only occurred with the diffuse+normal shader, not with the diffuse only, so I started playing with my normal maps. I'm not sure if the .tex files were somehow corrupted or what, but opening each of the normal maps and re-saving them fixed it. Thanks! I kept fiddling with settings but didn't think to try the textures themselves.

This problem has been bugging me for a while, and nothing I can find seems to fix it. The illumination from all the point lights in my scene seems to be skewed to one side of the actual light. I have tried adjusting the range and spot light direction settings, to no avail. I've also seen old references to a point light shadow offset property, but I can't find this in the editor. The two screens show basically default settings (only diffuse color modified). I can replicate the issue with a brand new point light as well. In the first image, the light is clearly skewed to the left. In the second one, the skew is different on one surface than another. The scene has no directional lights, just ambient and point. Does anyone have an idea how to resolve this?

Unfortunately this isn't something that can be done "very basic" and from scratch. There are several, moderately complex components involved in developing almost any kind of three dimensional character control scheme. Think of it like cooking, prepackaged stuff will make it easy, but has to hide some of the detail.

This is a snippet from a post regarding the Leadwerks 3.1 beta, I'm not positive because I don't really use Lua, but I think this may be the source of your issue: I believe Josh had to disable direct file I/O for security.

Hmm, I tried playing with the view distance setting and I think I broke something, because now my shadows fade out when the camera moves away from them, regardless of what value I choose.

The last properties tab in the editor when you select a lamp is called "Light" and includes a range property. Increase the second value of the range property.

Also, as described in this question (http://gamedev.stackexchange.com/questions/46150/swaying-camera-when-walking) a better model for head bob is a cycloid. So you could use, for example: dt = Time:GetCurrent() - startTime bob = amplitude * abs(cos(dt * frequency)) y = height + bob Edit: Sorry, it just occurred to me that this was wrong. You want the delta from the time when the player started walking, so instead of previousTime, startTime, and only set it when they first press the key.

Because Time:GetCurrent() could be arbitrarily large, it is totally obliterating your phase parameter whenever you start. You need to use a time delta instead. Also, it seems like your frequency parameter is in radians, which doesn't make sense.

This would actually be pretty useful for general gameplay programming, not just cut scenes. This is the type of behavior that is typically provided by custom scripting engines when they are developed for games. For instance, for programming "smart" animations, where the animation automatically generates particles, does damage, plays sounds, etc. during playback, this system would be very useful. If you'd like any help working on this, I'd be interested.

This worked for me, but I could never get the actual default value to function. --The Lua Script Script.MyColor = Vec3()--Color "My Color" // Retrieving the value in C++ Vec4 myColor = (Vec4)entity.getObjectA("MyColor");

On my laptop, Leadwerks and Leadwerks games have to be run with the discrete GPU, even though the Intel HD 4000 supports OpenGL 4. This means finding the executable and selecting a checkbox for "Run with High Performance GPU" in the properties.

Actually, if you have the Indie Edition the zombie/monster/crawler whatever guy has a melee attack. You can look at the code for that (e.g. how it is animated and how the hit is calculated) and reverse engineer it for your player. Then you just have to get the monster to play the "get hit by something" animation and lose some health when the player whacks him.

Cassyblanca, the decimal was in the correct place. The limit of 16 million square meters corresponds to 16 square kilometers (or a 4 km by 4 km square) which is probably roughly the size of the main map in Oblivion or GTA: Vice City (i.e. much larger than a small studio is probably capable of filling with quality content).