Jump to content

Brent Taylor

Members
  • Posts

    215
  • Joined

  • Last visited

Everything posted by Brent Taylor

  1. Err...Josh, I've done *dev work on wxWidgets. It's using the native GUI lib on the system. As far as being "full of bugs", I'd like to see a source for that. No software is bug free mind you, but don't confuse bugs with the toolkit, and bugs in an individual program. High Priority wxWidget bug list. I've no idea where you get the idea that wxWidgets applications are "instantly recognizable". As mentioned, it uses the native windowing kit of the system. *By dev work, I mean I've poked around in the source and have made a couple of changes. Nothing official. But it is definitely using the native windowing kit on the system.
  2. I'm talking about MFC. Yes, I don't like MFC either. There is also QT Creator (for QT) and wxGlade (for wxWidgets). They certainly make the job easier, even more so with QT (wxWidgets still being my favorite however. I hate qmake). It's still nowhere as easy as .NET with Winforms or WPF. Or Python with wxWidgets (and it's an almost identical library) or just about any managed language with a GUI library. The framework/standard library that ships with a language and the fundamental paradigms used in any language make a huge impact on ease and speed of development. Currently, C++ has the short end of the stick in that regard. There is a significant difference between "provided out of the box" and "you can do that, but you have to make it". Reflection, properties, garbage collection and just about everything else are all possible to set up in C++. In general they are not trivial to create (some are however, easier than others). Are you seriously suggesting that you'd have shorter or easier development given that this is true? Yes, you could make a library for C++ that makes GUI development easy. That's theoretical. The library does not currently exist, and that is what matters. When you've created such a library, by all means lets revisit this. Unless you intend to create a framework that rivals the .NET, Python, Ruby or <managed language of choice> standard libs/frameworks, it's still not going to be as easy or bug free. Again, the standard library and paradigms used in a language greatly effect ease of use and development time. In addition, you're talking about a theoretic GUI library, a library I might add, that is designed for a specific task. Just the GUI. ---- Don't get me wrong, I'm not saying don't use C++. It's a perfectly viable tool for any number of tasks. GUI dev just normally is not one of them as there are far better options.
  3. You seem to be unaware that Visual Studio comes with an identical form designer for C++ as the .NET languages. It's not free as it's only in one of the paid VS packages. It works just as well as the C# and other .NET form designers. Coding for it however is still a very painful experience. C++, when used properly, is still a monstrous beast. If you honestly think the differences between C++ and C# are inconsequential, I'm afraid I'm left to believe you've never really used C++ for anything beyond the basics. It's not that writing GUI's in C++ is difficult exactly. It's the fact that most things in C++, when done properly tend to be far more complicated than their .NET (or language of choice) implementations. In the end designing a GUI application (which in general does NOT have to be fast) in C++ is going to result in more dev time, more bugs and more code. Where's the advantage?
  4. Josh, if you want a native GUI, you're pretty much stuck with wxWidgets if you want it cross platform. That said, using C++ for GUI development of any kind is a pain in the rear. Might I suggest Python with wxPython (a nice wxWidgets lib for Python)? You can create native style executables with py2exe, py2app and freeze under Linux. Just about all of my cross platform GUI apps have been developed this way and it's trivial to do. *Just to be clear, I'm not suggesting you write the editor NOW. Just in the future if you do decide to write the editor in another language due to blitz no longer being supported.
  5. More specifically Bullet WILL support OpenCL. As pointed out in your quote, the OpenCL standard isn't public yet. I expect most physics engines will move over to it once it's been standardized. PhysX is still a good move.
  6. Good luck with that. I'm not trying to cause trouble, but while the Collada format is nice...no one implements the exporters properly, and I mean NO ONE. Maya, Blender, SoftImage and 3DS Max all have their quirks in their importers and exporters (in Blenders case they are severe). Part of the problem is everyone has their own implementation.
  7. I'm not sure if thats true or not (I've never used Poser), however if it is, there are apps like Decimator and such that can greatly lower polycount very quickly. They don't necessarily do an optimal job, but they don't require any skill to use either.
  8. To each their own for sure.
  9. I'm not trying to be rude, but at some point you're going to need some experience with a real modelling application to get anything done, in any engine. What you want to do is fairly trivial in a traditional modelling App such as Maya or (on the free end) Blender. You can bake your BVH animations and export your model as an FBX file. From there you can convert it directly with fbxtogmf, or use UU3D. But you are going to have to learn a modelling app, at least some of it anyway.
  10. Don't forget, I actually do have experience with Blender, and especially the UDK. Node graphs are great and all for a lot of things. Game logic just isn't one of them IMHO. It gets to be quite the mess if you use strictly kismet for everything in the UDK, rather than just code things out. It's not the syntax difference thats the issue, but the visual feedback gets overly confusing. It's an issue of visual overload. I know you're working on a tool to do just this, and I wish you the best of luck. To get an idea of exactly what you're creating, I highly suggest you look into Alice. http://www.alice.org/ It's not a node graph implementation, per say, but it's not far off. It uses drag and drop for line by line code generation. Try picturing doing something even remotely close to this using SoftImage ICE nodes or via Blender's node system. You're going to find it gets very complex very quickly.
  11. I'm a huge fan of ICE, but for what you're talking about it wouldn't be optimal. As soon as you start getting into any sort of reasonably complex game mechanics (and most games have more than a single mechanic) the node graphs start to get unwieldy. The only reason they work so well for shader creation, is you can usually get up to the node visual feedback of what's going on up and down the node chain. That just doesn't work very well in practice when dealing with code and that can be seen in SoftImage's ICE as well. It's great for non programmers, but it gets hard to follow very very quickly for everyone involved.
  12. Oh you can certainly write an engine in C#. But as mentioned, it does take a decent amount of knowledge to get it running at acceptable speeds. Admittedly, the same can be said about an engine written in C++. A crappy programmer is going to produce crappy code, not matter the language used. As for Lua, actually you're going to find Lua can be used for XNA dev. There's a .NET port of Lua that works just fine on the compact runtime. But whether you should even consider porting to XNA is a pretty easy question. Are you looking to target Indies for console dev, or professionals? Unfortunately "both" isn't much of an option here, considering dev kit requirements. In addition, if you were to port to XNA, is there enough interest to warrant the time spent rewriting the engine from scratch?
  13. Brent Taylor

    LE.NET

    I'm currently working on .NET headers as well. They'll precisely mimic both LE and LEO in order to get them officially supported.
  14. I get where you're coming from now. The problem with introducing such a structure is it's implementation. If it's not done JUST right, it's going to be very limiting. Unity's is pretty simple. Entities and Behaviors. It might be a decent way for Leadwerks to go.
  15. It's sad really and not at all helpful. He constantly derails potentially very positive discussions with his general attitude and most importantly his behavior.
  16. It would have been a lot faster to just look at the documentation. A simple search for "Rotate" would have gotten you this result. http://unity3d.com/support/documentation/ScriptReference/Transform.Rotate.html Seriously, this is ridiculous. This doesn't have anything to do with Leadwerks at this point. EDIT: Now trying to get back on topic... Actually the Up vector makes a lot of sense, and is required for a lot of the math you'll use in just about any game. In terms of direction, it's not really talking about "up" in the sense of "towards the sky" so much as it's talking about the rotation of the "Y" axis of an object in it's local space (some engines use "Z" as up as well, but thats relatively rare). The world space itself has it's own "Up" vector as well, and this is true for any engine (Leadwerks included). While I agree it doesn't necessarily make a lot of conceptual sense in all games (say, a space sim for example, where there is no true "Up"), it does however make the mathematics a heck of a lot easier to work with.
  17. Lumooja, you're only proving your own ignorance. Thats not only possible to do in Unity, it's as trivial as the code you posted. It's also entirely irrelevant. I'm not trying to advertise Unity here, but promoting improvements to Leadwerks. Lumooja, at this point it should be fairly obvious why no one believes anything you have to say. Yes, Unity can spawn a cube and rotate it with code. In fact one of it's features is procedural content. Yes, Cryengine has realtime shadows. It just doesn't run on XP or Linux, which while apparently irrelevant to you, it's quite relevant to the rest of the world.
  18. No doubt Leadwerks has great rendering facilities. I wasn't implying that Leadwerks has only one strength. Please make a point of taking what I say in context. As for your issues with the Unity editor, maybe you had a bug. Maybe you were trying to run it via WINE. No idea. However seeing how Unity has over 50 million downloads, holds a significant share of the game engine market on iOS, Android and OS X, as well as the general indie market...it's clear they are doing something right. If you had a bug, post it on their bug tracker. I can assure you, it was an isolated case. Claiming one of Josh's biggest competitors has no redeeming qualities is nothing more than a joke. You don't have to like Unity, thats fine (I'm not a big fan either). But pretending that there is nothing that Unity does right, and nothing for Josh to learn from to improve LE? That's just asinine.
  19. I don't know Rick. I agree, Leadwerks is not a game engine, but a framework geared towards multi-media applications (with an emphasis on games/simulations). However, thats also it's greatest strength IMHO. It's also precisely why Unity is so popular. Unity is NOT a game engine either. It's a framework, designed for the exact same market as Leadwerks. The difference is in the tool set. The Leadwerks editor is reasonable, but it's very very basic. Compare it to the Unity editor and you'll see precisely why Unity is as popular as it is. It provides some pretty basic behavior, but it's done with an emphasis of making it intuitive and RAPID. All the unity editor does (stock, and in a basic sense) is: Move, scale and rotate nodes/objects. Keep in mind, the last I checked, scaling is broken in the Leadwerks editor. Allow you to attach scripts (written in an external, third party editor) to those nodes. Create terrains. It's also extendable to allow for developers to add and create their own tools. THIS IS IMPORTANT. The Leadwerks editor does most of this...sort of. It's not extendable and there really isn't a way of attaching scripts to objects. Right now, Leadwerks's biggest issue is it's content pipeline. While there are tools for converting models and other assets into a format Leadwerks can work with, they are not intuitive and it's fairly largely agreed that they are near useless. People rather favor using other, expensive third party tools JUST to get content into the engine/framework. Why is that even acceptable? Secondly, the documentation for the Leadwerks engine is fairly abysmal. You have basic documentation that barely goes over functionality in the engine. Compare it to the documentation that is available (stock that is, not third party) that comes with Unity, UDK or even Torque 3D. The community has been creating examples, documentation and tutorials, however none of them are in the same league as what is available for other engines. @Everyone but Josh. Keep in mind, I'm speaking of LE as it is currently. I'm aware that LE 3 is around the corner and fixes some of these things. But that's the future and is subject to change, not the state of LE as it is this very moment. ---- Just to be clear. I'm not trying to bash on Leadwerks, but rather trying to give input so that in the end we have a better product. I like Leadwerks. I wouldn't have bought it if I didn't.
  20. I'm not trying to compare Leadwerks to Unity 3D or anything, but for the sake of making sure I understand you accurately, I think it's safe ground. This sounds a LOT like the system Unity has in place for dealing with scripts. You can attach a script to any node (and multiple scripts to the same node), and the same scripts to multiple nodes of different types. At runtime it just fires off certain, predetermined methods/functions (Object.Update, Object.OnClick, etc.) in each attached script at the appropriate time. Is this what you're trying to accomplish? If so, you've got me grinning.
  21. And I'm out of things to complain about. That doesn't happen very often.
  22. I've used it for a few years and I can testify that it's quite nice to work with. It's considerably easier to bind C++ classes and functions to Squirrel counterparts when using sqbind. It also has a syntax perhaps a little more compatible with game engines (as they tend to be OOP in nature). Lua was never a particularly good fit for that, it was just extremely easy to embed.
  23. I have an issue with this. You say that w'll be able to sell code and such in the asset store. But you make a specific case of file formats in the agreement. According to that agreement, any executables, .dll or C++ files for example could be freely redistributed. Furthermore this also means that FBX and collada files could be freely redistributed.
  24. Actually mono is simply a different implementation of the .NET runtime and VM. With the exception of applications written using certain libraries, a .NET application will run on mono without so much as a recompile. It's also true in reverse. So it's a non issue. Think of it as Java in this case. At this point mono compiles and runs for Windows, OS X, Linux, iOS and Android. As for separate documentation, thats fine. The syntax should be pretty much identical with a few slight syntactical differences. I'll get started today.
  25. @Josh What would your opinion be on me working with you to design a .NET wrapper that precisely mimics the C++ interface? I'd also be happy to write proper documentation for it (and have it automatically generated via doxygen). If all works out to your liking, we can work on getting proper (and maybe official) support for the language in LE3.
×
×
  • Create New...