Pixel Perfect

Is the end result of a CreateBuffer command in Leadwerks an OpenGL FBO or does it equate more to a Renderbuffer Object attached to an FBO? I need to know so I can match some external OpenGL rendering code to a Leadwerks buffer.

No, FOV is set using CameraZoom

Ah ok, thats a shame. Sounds like a bug to me. There have been several problems in the past with the pick structure population that were subsequently fixed. You might want to log that one!

I'd have a look at engine.log initially for any warning entries where the engine has not been able to load items for one reason or another. It might just be an abstract path issue. As I don't use LUA at all you might be better waiting for someone who's a bit more familiar with it replying but the LUA object scripting side should run transparently. So anything that works in the editor should be loaded and executed in the code. That's as far as the LUA implementation goes as far as I'm aware. It's not currently possible to expose and use your own functionality written in C/C++ to LUA or run LUA scripts independent of the current LUA framework without implementing that yourself.

I used CamStudio for the full screen videos of my navArea Editor (the first 3) and it seems to work pretty well. It’s not as fast as fraps on the game play side but fast enough if you don't have too much going on! Fraps is the best but as far as I'm aware still only captures the game rendered part of the screen. Is camtasia not up to the job then, it seems to have the best reputation out there for desktop recording?

The TPick structure returns the surface that the raycast has intersected so I'm guessing you could use this along with the surface commands like GetVertexTexCoords to retrieve info on the UV coords. Never tried it myself but that would be my first approach. Hope this helps.

I also think it would be great to be able to load these things from memory

I kind of know what you're saying NA as my system too is a hierarchical based system and I too can split the search down into smaller zones but at the end of the day the node density is determined by the density of objects that need to be avoided and that doesn't neccessarily imply that high density areas are going to be small as you were suggesting, that is really down to the level design and the game's environment. The node numbers have to grow with increasing geometry density. The shape as you say is pretty irrelevant! I understand you wanting to test your system against others but what is more important from my findings is the type of tests you do rather than just comparisons between different A* systems. Because they will all perform well against simple search paths. Anyway, good luck with your testing. I've tried searching for any available executable systems that might be useful to you as a comparison and failed to find anything. There seems to be very little out there! It does sound like an interesting system you have there and I'm looking forward to seeing more detail when you release your tutorial. I didn't bother optimising mine much as it runs more than fast enough for my own needs but I'll be interested in seeing how you've approached this.

That might be true for low density geometry scenes but how are you going to find your way through many floors of densely populated buildings for example full of obstacles?

I don't know of any exe progs you can download and just run but you could quickly knock something up using micropather in C++. If you have already existing node data it should be pretty easy to populate this. I have no idea how fast this is though! To be honest I suspect your routines are already fast enough, I wouldn't worry about ensuring its faster than everything else out there! So long as it can resolve paths efficiently for structures similar to the diagram underneath (green is start position, red is target) then it should be fine. You would of course be using a lot more nodes than the diagram grid.bmp

This is why I've completely igored LUA so far. I would like a scripting language to use in the traditional sence of simply using it to code game play and NPC behaviours but will probably write my own LUA implementation for that exposing all my lower level functionality like the state machine and pathfinding/AI routines. Trying to write a game engine using LUA as it currently stands is a complete non starter for me! I've already made my feelings known about the depreciation of previously existing functionality to force users down the LUA route! I guess its 'horses for courses' ... it really depends on what people want to do. The current LUA implementation is great for object scripting and so long as you keep the scripts simple then the lack of a professional IDE and debugging tools is not such a problem.

Exactly, the public variable will be visible to both so can be set by the callback and read by the main loop. Conversely, you could encapsulate your main loop within a 'game' class and have it reference a member variable. The member variable could be set by a public member function in the class which is called from the callback passing the value as a parameter. In this case the pointer to the 'game' class would be a public variable ensuring it's scoped to the callback function.

could you be a little more specific Mumbles

Could we have a simple YES/NO answer on this one, why should people have to keep bumping the thread! This was initially requested over 6 months ago and seems to be a quite reasonable request. If requests are simply ignored where's the incentive for people to keep using the mechanism.

Looks great. Will try it when I get home from work. Thanks!

Sorry, but this is quite simply wrong! You will be six months into your basic game engine design before you have any need for high poly characters believe me, if you're planning on making a serious game engine that is. Not saying that you don't need to keep in mind the fact that you will be upping the poly count eventually but there is absolutely no need initially for high quality finished characters. A simple low poly animated character is all you need initially and yes ... even an cube will suffice in the early days! What's more, it makes more sence to leave the purchasing of the final quality assets to near the end of the project as this might well be several years down the line, if it's a serious title, and the technology never stands still!

Either way it suggests its not finding them. Here is a link to the OpenGL FAQ where the issue is described: Getting Started Do a find on: unresolved external symbol __imp__glViewport@16 and read the section it references on setting up your compiler/linker Hope this helps!

That's a really interesting project. Looking forward to seeing more. The funny thing is, when I initially saw the photos I thought 'That looks just like CombatHelo' which I guess says a lot for Flexman's modelling and level design

Just going by the error message I'm guessing that the linker is failing to find the library in which the symbol is defined and judging by the symbol name it's probably one of the openGL libs like opengl32 or glu32. You probably just need to tell your project where to find these in the linker options.

I'm not at all sure what it is you are attempting to do in this line of code. If players is an array of structs then you appear to be assigning this particular struct in it's entirety to some value readbyte(0) as you are not referencing any member of the structure in your assignment. players[playerid] will simply point to the start of that instance of the structure in memory. Is this really what you are meaning to do? Without seeing the struct definition and the rest of the code it's not easy to determin if this is valid or not.

and the most beautifully rendered pile of junk you have ever seen! Tomorrow it's a cluster of galaxies, the day after an epic landscape, then a ...... Leadwerks ... only limited by your imagination

Yes, I'm using a slightly modified version of the original C++ Framewerk code. Excellent, that's really good news. Thanks for your advice, I'll have a play with this.

I've seen code in the past (from Masterxilo I seem to recollect) which allowed the use of openGL commands to write to 2D and 3D space but from recollection this appeared to be writing to the backbuffer and normally took place after all the Leadwerks rendering had taken place. Is it possible to write to any buffer using openGLcommands? What I'm looking to do ideally is write a texture created in memory to the background world and create a series of textured triangles to be rendered over it at this stage. Basically integrate in an already existing openGL sky rendering system. So I need access to Leadwerks framewerk buffers via openGL. Any advice/help would be appreciated.

I think you can still use GetMaterialKey and SetMaterialKey for this but I know in the past that SetMaterialKey didn't work for all standard properties in the material file. For instance 'castshadows' couldn't be set programatically. Both Masterxilo and myself requested the full set be implemented on separtate occations but I'm not sure this ever got implemented ... I just gave up asking in the end!

3DWS should work with bitmaps so I'd maybe try using something else to convert them from jpg to bmp as it maybe just an issue with the particular bitmap file format your converter has produced that 3DWS doesn't like. I personally wouldn't use bmp as, like jpg, it has no alpha channel so cannot support transparency. I have traditionally used png but dds would be a good choice too. However, as I don't know what engine you are exporting to maybe bmp is a requirement.