Rick

Yeah, but navmeshes are supposed to be faster right? Since you have less quads than you would waypoints. I would think the bigger your area gets the way worse performance it has with waypoints vs a navmesh. This is good, don't get me wrong, but it seems currently today most games use navmeshes.

I thought navmeshes were the way to go with pathfinding these days?

Yes! I'm in desperate need of this for my component editor. Thank you so much for figuring this out!

Actually "girl with massive sword" is all you have to say

I just remember using real-time raycasts for terrain decals (was probably doing something like 20+) and the fps was a very noticeable drop. Doing ran in a shader would be the best way to do it, but making shaders is a pain and it seems not many people can do it.

That's companies buying other companies (or software) which isn't exactly the same as venture capitalist. Venture capital is used in tons of startup businesses. For every 1 bad story out there around this, there are hundreds of good stories. So many people said Josh needs more people, that he can't do it all himself, but when the opportunity comes up to get that and he turns it down (or doesn't pursue it) everyone says good idea? It's pure fear oriented. It would be in the best interest of Leadwerk users if he did this. When it's just a 1 man show, he could die or get critically injured tomorrow and this all ends instantly. At least if it's a company with employees Josh could die or get hurt and yet LE would continue on. Do you think if the guy(s) who created Unity would die that Unity would close it's doors for good? No way. There is a staff and the company is greater than 1 person. That's more secure for the users. I remember when Josh had back surgery, I think it was, he didn't even want to tell us about it in fear that people might freak out in the thought that he wouldn't come out of it OK. Frustrating that the opportunity is there for the taking and it's left on the table.

Yes, use C++ if you already know it.

I think this can be approached like a game or any other software. You write the detailed tech design (detailed non programming language description) and then it doesn't really matter who programs it as long as they know the language and API's you require for the project, and they follow your design. Why would you want to program this? It's a waste of your time really. It sounds more like you don't have the details worked out of what you want and that's why you want to program it. So when you hit the design holes you can then come up with a design on the fly to fill that hole. Given that I can see why you wouldn't want to take the risk, although I think the solution would be to make the detailed tech design instead of programming it yourself. You are like a Sid Meier. There comes a point where your time is better spent designing instead of programming. The design is what you bring to the table for LE. If you detailed your design, then any programmer who knows the language and API can make it come true for you. That's my view on it anyway. If you program this in a language you aren't familiar with the chances that you do something incorrectly or hacky will be much greater and can have negative impact on the engine in the long run. This doesn't mean you have to take the full 10 million however, but much less to start with to get just the few programmers required to get your design working.

And a ton of free time to let that process It'll be interesting to see in practice.

256 MB?? I don't even want to think about how long it would take to run that many raycasts to make that much data!!

So I assume that means the accuracy of rain and it's colliding with things would depend on the resolution one picks?

So you are going to release 2.4 and then go on vacation? Ouch. Not that the vacation isn't well deserved but you should release 2.4 after you come back so you can answer and fix issues, because like any piece of software there will be issues for weeks after it's release, especially if you are doing some lighting stuff that hasn't been done by anyone before. As far as you coding in C++, as you come across design ideas it might be helpful to ask the C++ community on on certain things could be done. There are a millions different ways to do things in C++, so finding the best one first can help the code be more solid right out of the gate. I just picture the Lua deal where it seemed like you might have only talked to a fwe people or thought of your own to make the multiple instances instead of the one. It could have saved time up front if that question was put to the community up front before you did any of the coding. I also think that you are letting fear take over your decision about the investment chances. The amount of resources and things you can do with 10 million is huge. Sure get that money doesn't equal a great engine, but you equal a great engine. You are the asset of LE and having 10 million isn't going to change that. Sure you might have to hire people and they won't all think like you, but that's where you have to turn into the boss and make them think like you. Make them see the goals you have and if you have a clear plan they will deliver. When I read your comments about why you don't want to do this, they seem more based on fear than anything else.

From my experience raycasts are far from fast, so I'm thinking the precalc is going to be required. I have to wonder how fast it would even be to make this heightmap for raycasting. Are you thinking of casting a ray for every possible point and store off the height at which that ray hit something? I would think that would take a long time to compile such a heightmap.

I have seen the tutorials. I have used them to get networking working. If I'm able to get it working anyone can, trust me. You will get more out of RakNet than LE's current networking API. I thought RakNet was overwhelming at first too, but one you see how BitStreams work, it's very simple actually.

What game do you have?

Very nice. 1) What are you using to make these? Everything runs and sounds very nice. 2) You should do a tutorial in auto-tune. T-Pain style Keep up the good work!

Use RakNet. Seriously, you won't regret it and there is good documentation around it and it's really not hard.

Would 1 sided planes that always face the player (only along the Y axis though) be more efficient than cubes? The planes could have a transparent image of a rain drop type.

Looking at buying a Dell Studio laptop that has a 1GB ATI Mobility Radeon HD 4650. Am I safe to assume this is enough to run LE? Just want to make sure I can work in LE before getting this thing.

Only 1 monitor?? How can you function like that

Well, really we would do the same thing in C#, but just with interfaces since you can have multiple interfaces inherited.

Sure it could. Make another interface called MatrixChange that has a pure virtual method for the callback. Then derive your class from that class (you can have multiple inheritance). Then make the C function callback for the matrix changed and do the same thing. That should work for every callback that LE has. One thing you can do is also pass the first entity to the member methods in case you have multiple LE entities inside your class, you can then check which one was collided with or matrix chagned or whatever. With multiple inheritance you can cast the entity to any of the "interfaces" you derived your object from. class MatrixUpdate { public: virtual void OnUpdateMatrix(TEntity ent)=0; }; void _sdtcall MatrixCallback(TEntity ent) { MatrixUpdate* b = (MatrixUpdate*)GetEntityUserData(ent); if(b != NULL) { b->OnUpdateMatrix(ent); } } class MyBody : public Collider, public MatrixUpdate { private: TEntity body; public: MyBody() { body = CreateBodyBox(); SetEntityUserData(body, (byte*)this); SetEntityCallback(body,(byte*)EntityCollisionCallback,ENTITYCALLBACK_COLLISION); SetEntityCallback(body,(byte*)EntityCollisionCallback,ENTITYCALLBACK_UPDATEMATRIX); } virtual void OnCollide(TEntity ent, byte* position, byte* normal, byte* force, flt speed) { } virtual void OnUpdateMatrix(TEntity ent) { } };

Thanks, I thought so too. This is how the C++ wrapper should handle these callbacks I think.

I agree with Red, but the implementation should be 99% transparent while programming. I didn't find Torque's implementation to be that good/friendly. With things like commandToClient() or Datablocks I just wasn't a fan of it. The idea is great, but if it could really be abstracted from the developer it would be nice. From what I remember with Torque if one called a client function with commandToClient("SetScoreCounter") the resulting client function would have to prefix itself with clientCmd like below. That's just ghetto function clientCmdSetScoreCounter(%score) { ScoreCounter.setText("Score:" SPC %score); }

You are exactly right. The debate of if Leadwerks is an API or an engine has happened a few times in the community. I for one find it to be an API. It lacks certain features to be an engine when compared to the other engines out on the market today. If you want to make straight games and don't mind using a predefined structure for how to do that than LE isn't the right product yet. 3.0 will most likely provide this but currently it's not there. It's completely open ended and more structured for you to make your own game engine currently. The Lua implementation however is a step in that direction of defining a game structure. Most of the programmers here (myself included) love that it's open ended because we generally like to control such things in our games, but it's not for everyone. The wiki is located http://www.leadwerks.com/wiki/, but I'm not 100% sure if you can view it if you don't have the license.