-
Posts
7,936 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Downloads
Everything posted by Rick
-
I just want various trigger types in 3.0. Triggers form a large base for most all gameplay. Volume triggers, input triggers, etc would help get some gameplay going in some of these pretty screenshots.
-
I can't remember off the top of my head, but one is the parent of the other, and I can't remember what pick.entity returns (mesh or model) It's always a trial and error when I have to do this because I can't remember the order. I actually find that kind of annoying. What is the point of the model part of that? Why isn't it all just a mesh?
-
For speed/storage concerns Josh has chosen to not make this the default case. That is by design. That's how he can get tons of the same model on the screen at the same time cheaply. There are cases where that's good and there are cases where that's bad and causes devs to jump through hoops. He's meeting us in the middle and offering a way for us to make each mesh unique, while still being able to cheaply render tons of the same model. In short, it's good to give us the choice.
-
I didn't look at the code, but is it the case of mesh vs model? I know that who thing is around with picking.
-
Check out Editor.ini. There are some paths in there you can change back to your LE folder and it should work.
-
That actually wasn't my point Pancakes, but that is for sure a valid one. If he plans on "outsourcing" some of these tools, the professional base for BMax is certainly smaller than for C++. I honestly don't expect Josh to change from using BMax (just wanted to show the other side), but it will be educational to see if there are any big obstacles that come out of using a different language for the UI tools than the core engine is written in.
-
Basically No, for real though, using the same language for an editor that a library the editor uses, just seems like you can avoid any issues and glue code required with mixing different languages together. That's all I was saying. I understand Josh hasn't used any of these C++ UI's and that he would start out less efficient in them, but there would be no doubt he would get proficient with them. The tools have been proven. They have been used in enterprise applications already. It's not like I'm asking him to test a product that hasn't been proven. http://qt.nokia.com/qt-in-use
-
Yeah, you are right. There are no clear cases for using C++ for the editor that I can think of. I don't have the experience of BMax and mixing languages with it and such. The closest thing I can think of would be if the engine was written in C++ and I used .NET for the editor, one has to do headers and all that stuff, then you risk errors there so if I was in that situation it would seem best to avoid all that junk, but I don't know BMax so not sure how it plays with others.
-
Yep, you are right, it is. Just seems to me that you "could" avoid issues that aren't known now with using the same language for the UI's that the library will be written in. Seems to be what he did with LE up until now with BMax. So really, by mixing languages he might be going into unknown territory. He wasn't comfortable with C++ but he picked it to rewrite LE 3. That's for sure causing some slow down compared to if he kept with BMax to make LE 3, and he seemed OK with that. He seemed open to the idea, so thought I'd bring it up. Just trying to show the other side.
-
Qt is probably the most sophisticated out of those. Not at all, and to be honest I wouldn't call what the LE Editor is a "complex app". Even if you plan on adding a few more features to it, it's still pretty basic. I would call something like VS a complex app, with all the docking and customization that it allows. Qt has a designer for your UI just like .NET or Java does. At that point, what difference is the code behind it compared to .NET or Java? Not much, but the fact that it's the same language as the engine "could" bring benefits. It could avoid workarounds, and such that might be needed otherwise. It could give a faster more responsive editor also. Qt runs on some mobile devices also, which is kind of cool. C++ has truly be screwed over in the GUI department, so it's understandable that most people think C++ isn't used for this, but C++ can GUI's just like any other language. I personally think MS gave it a bad rap when they created MFC. That was probably the worse C++ UI (it was more than just that) implementation I've ever seen. The editors for UI's is probably 75% of creating UI's in the first place, then the rest is the code behind it and how easy it is to use. MS could have very easily created a better C++ implementation of their UI that mimicked the VB design at the time, but then people wouldn't need to buy their new VS versions like they do now with .NET.
-
Mono. I think it's important that you are honest with yourself and just know that you are using MaxGUI because it's just what you are most comfortable with, not really because it's the best solution. I'm not even saying Mono would be the best solution, because there are other GUI's out there also, but have you really checked all available solutions to you? There are some C++ GUI's out there that are cross platform, look great, and easy to use. Just a few that I know of: http://qt.nokia.com/ http://www.wxwidgets.org/ Using C++ for your GUI's might yield some benefits over MaxGUI, just like using C++ for your engine yields some benefits over using BMax.
-
You would be right. Trying to create a generic GUI that is flexible enough for everyone and every system will almost always end up being complicated to use and integrate. CEGUI is a prime example of this, but the creator doesn't actually care about that much. I talked with him on their forums when I was getting it to work with LE, and he created it for his own needs and just gave out the source to be nice, but he doesn't much care about making it easy to use. Plus it uses many 3rd party libraries so it gets complicated by that also.
-
I agree, but I don't see much wrong with the current editor UI so I don't think we have much to worry about. It needs to be functional first, pretty second.
-
Maybe use an environment variable for the path? I agree that it would be nice if Leadwerks did this already.
-
Artists won't like it because it limits them, but level designers love it & non artists love it! It's good to hear you'll think about it. Honestly I'd rather have lots of blocking levels that have actual gameplay (ie. programmer art), then just pretty static scenes. If anything it allows us programmers to showcase things that will help get artists interested in the job.
-
Says who? You are starting to sound like Lumooja. CSG is still very much in use today. It greatly increases level design and requires less skill than being a 3D artist.
-
There must be a way to do this, but does anyone know how you could get the lua state from inside lua itself? There must be a state variable within the current state in lua. I'd like to get that.
-
1 word, RakNet. Save your money on hiring professional programmers for networking code and use something that is already tested, tried, and true. You can basically make your own RakNet wrapper to make things easier, but the underneath stuff is the important part of any networking library. Seriously, don't even waste your money on making your own. There just isn't much point in it.
-
I don't really know if it really matters if it's html based or not as long as there is an editor that makes it easy to work with and customize I think that'll make everyone happy.
-
Were those able to be GUI elements in a 3D app? The examples I see look like it's just drawing what would be a webpage in 3D space. I would think ideally the GUI would be html elements drawn on top of the 3D application.
-
I assume that means Josh basically has to write an html renderer? I wonder how hard that would be.
-
xml based GUI for sure. Then the code in C/C++ and exposed to Lua like most of the other commands are. Also have an editor.
-
Did that work for you in C++? I'm pretty sure you can't overload a function with just the return type being different. Here is a trick that I found: struct func { operator string() { return "1";} operator int() { return 2; } }; int main( ) { int x = func(); // calls int version string y = func(); // calls string version double d = func(); // calls int version cout << func() << endl; // calls int version func(); // calls neither } Lazlo that might work, but does it work if they are all in the same class? That seems to be what he's trying to do.
-
You can. I wrote something on the old forum on how to load a DLL from Lua and call C/C++ functions from it.
-
This might help. http://www.gamedev.net/reference/articles/article2275.asp I'm sure you'll need a 3rd party library.