Pixel Perfect

Yeah, that's OK Rick. I have to do the same balancing act all the time. Would be handy if you manage to find the time at some point though, just so we can finally make some knowledgeable statements about the performance of Lua in these situations rather than the guestimates we currently tend to use and better advise people. I know Soamp wrote a lot of code in Lua initially and was experiencing some major performance issues, I don't recollect what the outcome of that was if indeed he ever told us?

The usual method is to have a health value which is decremented each time the NPC is struck. Once zero health is reached your code would trigger the death animation and remove the NPC as an active character in the game.

Did you ever get round to trying this Rick, some comparison stats would be nice to see!

Very impresive Mika, nice work!

wow ... thats a great looking character! Nice work NA

ok, thanks Josh

ok, I guess I will have to work it out empirically

Does anyone know how this matrix is constructed (as per SetEntityMatrix and GetEntityMatrix). What is the order of the four TVec4 vectors? The wiki seems to mention 3 ... position, rotation, and scale ... so whats the forth and are they in that order? I'm reading in the vegetation binary data and trying to interpret it.

I loved Battle Chess when that first came out, I see its being brought up to date: battle-chess

Some nice improvements Rick (can't hear the sound just now as I'm at work!)

As I think you're discovering LE2 is more of a game engine API than an actual game engine. You need to write the game engine in order to bring life to the levels you design within the editor. Yes, Lua can be used for object level scripting and quite effectively. However, the Lua implementation will not talk natively to C++ classes and methods as Lua does not support that as of itself. You can either implement one of the many library solutions out there (Luabind, ToLua to name but a few) for doing this, or provide C Style function wrappers for the functions you want to interface with.

I agree, whilst the overall comic style effect is a good one, its 'color chaos' in these scenes and it does very much distract the eye from easily mapping the structure and contours of the geometry. DaDonik's and Franck's comic shader examples looked a lot more effective given a more toned down color balance. Interesting to see you working on a new game though NA and an episodic one! What’s happened to Hidden Dawn though, I remember you indicating that was complete a long long time ago?

Provide good inherent functionality in the Editor for everything you think is important by all means ... but you will never provide everything that people want though Josh. A plug-in architecture can make up for that and empower community inventiveness. Yes you'll get good and bad plug-ins but people are pretty good at differentiating between the two and discarding the bad! I would seriously give consideration to a plug-in architecture as I think it opens up a lot of possibilities.

The problem with this statement is that when you want to do something in the remaining 1% your going to find yourself pushed for time. This is exactly where speed and efficiency comes in and what makes the difference in the end as to whether you can get the performance you want or not. The remaining 99% you can do little about as it's someone else's code

All game play is smoke and mirrors Mika ... it matters not how you achieve the illusion, just that you do

Sorry Mac, I must have missed your question. It was the nVidea 260.99 64 bit driver. First noticed it when trying Aggror's MAGIAM game entry but it would occur on other Leadwerks apps too. Upgraded to a 270 version and no further issues

It should be quite possible to code pretty much a whole game using Lua so long as any intensive routines are done in a faster language, C being the obvious one as it interfaces directly into Lua. If it's a simple game then I'd say there is probably little risk. There is however a lot to be said for using the faster languages, and in particular C++ Whether people like it or not it is still the “de facto” language for game development and as such will stand you in good stead within the gaming industry. You are unlikely to run into speed problems as a result of the language itself (poor design is more likely to be the issue) but development will be slower. You will have easier access to more professional tools and libraries using C++ then any other language, which may well speed up development. Its cross platform nature C# and BlitzMax are both very capable languages though and represent good choices for anything but the most demanding of games. Out of interest, I've had A* pathfinding running on a 200x200 grid (40,000 nodes) with 30 NPCs in C++ with an average max path find time of around 2mS but generally much less. That would obviously rise on a slower machine! I would hate to run that in Lua though! Putting it onto the gpu would conciderably speed that up too ... to probably sub millisecond! I seem to recollect Naughty Alien doing just that using cuda or OpenCL.

Looks great Rick. Looking forward to seeing how this progresses.

Leadwerks uses OpenGL so no, I doesn't support DirectX11. btw, I had the exact same issue with a previous driver!

Looks great .. nice work!

The C framewerk code (the source code version of the framework) is available in older versions of LE2 but was no longer distributed after version 2.31 (I think). Either way it has not been maintained for some time and is missing some of the later features. However, I believe that the framework is still distributed as source code for Blitz Max.

Why couldn't the extra rendering pass be made conditional. i.e one route for current rendering setup, another for the additional rendering pass conditionally selected by the programmer. That way apart from setting up the additional buffer, those that don't require it would simply not enable it! In theory the programmer could further reduce the hit by analyzing the presence of objects in the camera frustum and conditionally switching it based on that analysis.

This as I understand it is a framework issue and requires another rendering pass to make it work. As this has been an issue for a long time I don't understand why the framework is not modified to accomodate this as a switchable option so that people who want to use it and take the hit can do but those who have no need of it can opt to simply not use it. That way it's a win win situation!

I could well believe that NA That's why Josh shouldn't be and to my belief never has been totally driven by artists demands. However I agree with Roland on this one, the programming access is good enough and I'm sure josh will maintain that but a lot of trivial everyday tasks associated with level design could and probably should be automated. I have faith that Josh will get the balance right in LE3.

Excellent progress ... congratulations!