Pixel Perfect

I guess you have to do the math. If you know the size of your rectangle and the position and orientation you should be able to calculate the center edge positions for every edge on every rectangle. This is static data and can be calculated up front so there is little cost in looking this up in real time.

I suspect you could do a very nice job using Leadwerks. Plenty of other people have expressed interest in doing exactly this! Just bare in mind the graphics card requirements for the engine, however this is becoming less of a problem as time goes on and SM3 cards become more of a standard low end component.

I'd say that’s about right Rick, how you store the navmesh nodes and the linking data is pretty much up to you. So long as you can feed it into an A* routine to get your final node traversed list and then retrieve sufficient information to ascertain the mid points of the connecting faces then the simplest route is done. You can apply math to curve through these angle changes if you want to make them slightly more natural but that’s another level of refinement. You can go on then to apply heuristics/costs to apply bias to the path finding. So if an enemy is known to be in a certain area and you want to avoid them or if you wanted to represent traversing high ground as less desirable than low ground then applying values to these areas would make the A* routine less likely to pick them. It's not always about the shortest route If you're looking for a generic A* solver take a look at MicroPather

A lot of people say a lot of things, I've learnt to disbelieve most and discover for myself. Welcome aboad, you will find the community very supportive if you are prepared to learn Have fun!

As in theory all nav mesh nodes are walkable I think the next phase having returned the list of nodes you need to walk through is to produce curved path through them so it looks natural (its referred to as string pulling I think). Again, I've not worked directly with nav meshes so I'm trying my best to remember what Chris had described when talking about his implementation. My system of navAreas is more akin to the old 2D grid system so I have fixed sized nodes. I suspect it doesn't help to allow your nodes to extend beyond a certain maximum size or as you say you will be needing to pathfind through the nodes themselves

Yes, that's why its a special case. In the square grid it's assumed each tile is linked to the 8 surrounding tiles (or nodes).

As far as I'm aware Rick A* is still used to find your way through the nodes. The navmesh polys represent individual nodes and A* iterates through the list of linked nodes. Chris will probably give you a much fuller explanation. In terms of do they need to touch, I'd say probably not so long as your logic links them where its deemed appropriate ... such as the steps on a flight of stairs for instance. If an area of nav mesh is totally isolated from the main section, such as on top of the roof of a container, then that may be also quite valid as although there is no way to link to it as your NPCs couldn't jump that high, they still might fall of a building and land on it. A* in theory should work with any number of dimensions, the traditional 2D square grid is just a special case.

The only advantage I see is the fact that realistic ballistics come into play, so you can have parabolic movement as gravity pulls the bullet down over distance, realistic transmission of momentum into hit objects and also true rickochet (which would be quite tricky to simulate without using a real object and the physics engine). Personally ... I'm just using raycasts.

I'd agree, there is no reason why a game couldn't be written using BlitzMax, in fact it's a good choice for people new to programming (which in no means undermines BM as it's a very capable language). The differences between C++, BlitzMax and C# are much closer. But your statement fascinates me, are you saying that you have your entire engine written in both languages and are able to run benchmark tests between them? How much processing time is taken up by your code on average per game cycle, min and max values would be a good insight if you have these figures? Do you use multithreading or any other processes devised to average out peak processing demands over multiple game cycles? You are far closer than most of us to having a completed game and some feedback on this would be really useful.

An interesting approach .. what sort of speed are you getting for plotting paths over reasonable distances?

It's already logged as a feature request here: holy-****-there-is-no-undo-button-in-the-editor and has been many times before in the previous forums.I honestly thought we were getting it in the 2.3 Editor!

To put it simply .... the more your game has to do in code, the more difficult you will find it to fit that in between each frame render in order to maintain a decent frame rate. This is where the raw speed and performance of a language comes into play; before you get to that point you will see no difference. Most people have relatively little or no code executing between frame renders at the moment so they see little or no difference between any of the languages. This is simply because they have not really started to tackle what is really needed in a game engine to make a game. If you intend making a very simple game then you will get away with using LUA (which at times may execute 50 times slower than C++ for example) but if you intend making a modern day contender for a FPS, RPG etc then basing your engine design totally on LUA would be impractical. Well written routines in C++ will execute the fastest of all the languages mentioned with BlitzMax and C# falling in between and LUA trailing well behind at the end. Lua can be combined with other languages successfully and used with serious engine designs but in this case it is normally relegated to a scripting language carrying out high level logic with all the clever and tricky stuff being done underneath in faster code, as Josh was highlighting above. It's all a question of choosing what is right for your game but also listening to those with experience, because unless you have been there before these things are not always obvious at the beginning but will hit you hard later on if you get it wrong.

The actual rendering side (the graphics) will run pretty much at the same speed using any of the languages, it really depends on what you are looking at doing between rendering frames. If you are planning lots of complicated AI for instance you probably would benefit from the raw speed of C++, otherwise any are a valid choice imho. You can of course mix and match either C++ or BlitzMax with LUA. Just don't do anything that's very intensive in LUA. There is also C# too, but I have no experience of using that, but I'm sure its an equally valid option too.

All good core improvements .. thanks

Cool, thanks

What format are the samples in Gimpy73 ?

Very impressive, thanks for the link Niosop ... downloading the source code now!

I am quite happy to pay for significant upgrades from time to time but do not in anyway agree with the inference that chargeable upgrades will necessarily bring about better upgrades. I personally have little need for LUA but have had to upgrade in order to not be left stuck with a static unsupported version. I agree with Michael that a plug-in type system for anything other than core API upgrades would be a fairer system with people purchasing on a 'as needs' basis. A 'bolt on' LE augmentation system would be a great way to go!

Gets my support if it's fairly easy to do, having to specifically convert models to obj format all adds to the development time.

Delighted

Yeah, working fine on my nVidea (spec as below). The water and sky effects are both really very good. The HDR seems a bit fierce and I'm getting occasional issues with what might be clipping planes but the water is top notch. I particularly like the foam on the water ... that looks completely natural. The only water I have seen that betters this uses FFT for all those cascaded wave frequencies that make it look totally realistic. Very impressive!

It crashes on my ATI Machine with an unhandled Fatal Error just after loading nodes for the forest. I'll try it on my nVidea PC and report back.

Now that's very effective ... nice one!

I don't think cocopino is having collision issues at all, I think he was just answering your question. Collision is not currently supported on objects placed using the Vegetation Layer function, its fully supported with anything else.

I don't think I've seen NoOdle in the forums since before Christmas. The question that comes to mind though is how did they check the quality of the conversions if they didn't have a password?