Rick

http://www.leadwerks.com/werkspace/topic/1250-plane-to-hug-terrain/page__hl__mesh+terrain__st__60 Here is a big giant thread talking about ways of doing it.

I think you could send and receive messages between the two languages also.

the three primary languages are bmax, lua, & c++. Pick whichever language you feel most comfortable with. Leadwerks editor has terrain functionality itself so no need for 3d world studio. a big hurdle with be the amount of art assets for any rpg game. Have fun and good luck.

These comparisons seem a little subjective.

LE 2 uses BMax but makes itself available to be programed in other languages like C/C++, .NET, Java, etc. C/C++, Lua, & BMax are the only "officially" supported languages though. LE 3 will be programmed in C/C++ but other languages will be unofficially supported just like today. That's the first time I've ever heard that in my life

The achievement system is what I would think you'd want to know how their API works around. I mean everyone could come up with a million different ways to do an achievement system and I would think Valve's API would have some kind of structure that one could use around the achievement system and knowing how their API works or is structured might influence how you build your achievement system so it's nice and integrated. Maybe it's so modular that it wouldn't cause you to rewrite some pieces in one's implementation of an achievement system though.

One would think it would be more efficient to fit their API into your game as you go along so it kind of sucks that you have to basically finish your game and then fit their API into your game after the fact. Not sure what harm it would be to just give the API as I'm sure there is some activation thing that has to happen for it to be connected anyway.

It requires programming. Sorry. Perhaps you can team up with someone.

I really think the stepping through code part was the missing piece with Lua. Not being able to do that in LE 2 currently makes it painful to debug. Most people have just latched on to the stepping through code for debugging and expect it. So the fact that LE 3 will have that for Lua is a massive plus and would really slow down any sort of .NET steam for scripting. The remaining thoughts about .NET would be all of the supporting functionality that comes with it that Lua doesn't have, although C++ and BMax people have been working fine without all that functionality so far anyway.

I believe Josh has this functionality working for LE 3.

That logic escapes me but it's your show. Wouldn't one programming forum better bring together programmers of all types instead of creating a segregation like we have today? When the API is all the same it's less about the syntax of the language and more about the general logic. You're right. MG I apologize. You are a valuable asset to this community and I apologize if I read to much into some of the things you type. That's something I have to work on. Will you tell me what scripting lang you are thinking about going to? I don't want to play detective anymore.

I think our group talk brought josh out to speak more about the topic, helping you come to your coclusion. Otherwise you would have just gotten the vague song and dance You're welcome jk

I guess my detective skills are lacking since Lua isn't a proprietary scripting language (and hence wouldn't fit into your description of using a proprietary scripting language) and it's the only scripting language officially supported by LE so switching to any other scripting language wouldn't be much different than using BMax in the first place with LE3. Have you met Marley?

It was a joke that brought the original request for a forum for a language (BMax), which by the sounds of it you are going to create your own, full circle. haha, wink wink, poke poke

Sounds like we're going to need another forum

In case Josh didn't want to go digging in your proof. Inside Control.cpp in the MSWCreateControl method: m_hWnd = (WXHWND)::CreateWindowEx ( exstyle, // extended style classname, // the kind of control to create label.wx_str(), // the window name style, // the window style x, y, w, h, // the window position and size GetHwndOf(GetParent()), // parent (HMENU)wxUIntToPtr(GetId()), // child id wxGetInstance(), // app instance NULL // creation parameters ); Native Windows creation of controls. In all honesty though I think a good number of other libraries that don't use Native GUI elements do so because all systems are different and getting things to look and feel just the way you want on all systems can be a pain. You've seen that pain between ATI and nVidia with your engine. Now your editor will experience that with 3 systems instead of 2 like your engine. Like Brent mentioned some concepts are system specific so you have to do the lowest common denominator with your controls which can hurt the design.

I think he's saying some of the controls are custom because out of the box MS doesn't have them in their default GUI. The common things like a button and the like would be using the default Windows button. There wouldn't be much point in making your own button since MS has one already for you, BUT if you wanted a button to do something MS's buttons doesn't that's where they are making their own.

Oh, I guess being the internet and all sarcasm doesn't come across to well Combining them all to just a Programming forum seems ok since all commands are exactly the same. Let's unite the programmers instead of divide them. Also we have Java & Python & who knows what other language ports the community will come up with and Josh doesn't create forums for those. We have a .NET forum which is about as supported as our Java port yet .NET has a forum. I mean it all doesn't really make sense. It's kind of like this thread http://www.leadwerks.com/werkspace/topic/3384-camera-going-thru-walls/page__pid__30954#entry30954 You point him to a C++ example, I explain in English and yet he posted it on the BMax forum. It's all just programming.

One other way which I've done before was to use EntityVisible from the camera location to the camera target (I just used pivots at either location to make it easy, but there are other ways to get the same effect) and if it's not use LinePick from the player to the camera looking for the first hit. Then move your camera to that hit. The benefit of this is that it won't allow anything to come between your camera and your player, if that's what you are looking for. Pillars for example would be where body collisions and this method would differ, but it all depends on what you are looking for. Sometimes it's cool to have the camera go behind pillars.

Didn't we just come to an agreement of not having a subforum and just having a programming forum? That was BMax and non BMax people coming together right there! What a beautiful thing.

I agree with this. If every command will be identical no matter what language then it doesn't make much sense to separate out the forums by language.

Actually the "default" Windows GUI is ugly. .NET adds some visual pleasantries with visual styles. Honestly I'm not a fan of that in wxWidgets either.

I'm not arguing with you there, but there is a big difference between a framework/api and the language itself. C++ has just chosen to not be that specific but libraries can be made to make a framework (not built in by any means) just as good as the built in frameworks. Also, C++ didn't get the short end of the stick, they picked that end. They want users to make those libraries using C++. I get it. I hate open source **** too. Combining 20 different libraries and having to compile each one is not something I like to do, but that's just old school mentality with C++ people. As .NET programmers over the years venture into C++ land they will eventually bring over the ideals. I think we are on the same page. The point I'm trying to make is that C++ currently isn't thought of as a GUI language because the implementations (and there really aren't all that many) are not that good. Instead of trying to copy proven frameworks (like .NET) they go off on their own and try to do some crazy stuff. Most also don't use the native GUI elements which like Josh points out is kind of annoying. There just hasn't been a good library created for C++ for GUI programming but it's more than capable of doing it. GC btw would be debatable if it's a good thing or not I'd say. Do you have examples of this? Just curious as I'd like to check some out. We are trying to help. You admitted yourself you are using a dead language for your editor. Is that really a long term solution? 5 years, 10 years, 15 years down the line? I'm defending C++ because I know it can do it, but personally I think you should have used mono. .NET isn't dead and will be around for a long time to come and it has amazing support. It's only growing but you picked a dead language because you know it better at this point in your life just like you picked it when you made previous of versions of LE, but look at LE 3 now. BTW can you believe MFC. I have a hard time believing MS tried to pass that off as anything but a POS.

The ideology of most c++ library writers is why most view c++ as a pain to write a gui with. It doesn't have to be that way though. I'm going to create a very small c++ wrapper around the win 32 api that just handles the main window and buttons and make it event oriented and follow .net specs as close as I can. If you are talking about either MFC or C++ CLR then both of those are a complete joke. MFC is just ugly and macro driven when it doesn't need to be and C++ CLR is a frankenstein of a beast. Weren't they even discontinuing that soon anyway? It's not even "real" C++. Show me the major differences in language and not framework that C++ can't do/simulate. Things like reflection is not the language itself but the framework. C++ has void* to simulate dynamic, I can simulate properties in C++ just like in C#, etc etc. At the core the biggest differences are at the framework level. That's what libraries are for. They are meant to hide the complexity and give the user (the programmer in this case) a nice clean and easy to use interface. This is the problem with most C++ library writers especially in the open source world. I'll do my demo and see what I can come up with. I'll compare it to a C# example of the same nature and see what the difference truly is. Note the C# glue code that the editor creates will be include as well since that's what you'd have to do without an IDE. Most people would hate C# just as much for GUI programming as C++ without VS because it does so so much for the programmer. Let's consider this test a proof of concept.

Only because nobody has created a good API and IDE for that purpose. If someone would basically duplicate .NET but in C++ and the IDE would be the same then it would be no different. For GUI apps the IDE plays a massive role in how successful the API is. .NET wouldn't be as popular for GUI apps if it didn't have the IDE doing the heavy lifting for us. I mean why would it since something like C# is so close to C++. You can't tell me the small differences between the 2 languages (not frameworks, but languages) makes all the difference. I'm going to have to get into Win 32 API programming again and make a C++ wrapper and IDE or something for people to see that the language has little to do with how "easy" writing a GUI app is. It's more about the framework and how it's setup.