Brent Taylor

I should also point out that models from google's 3d warehouse can't be used for any commercial projects, or at least that is my understanding. Just keep it in mind.

While QT can be made to do that, it doesn't do so by default and for good reason. GUI code does not need to draw very quickly. Draw too quickly and you're wasting system resources.

It actually isn't using the native widgets to the OS. It uses a theme engine to give the appearance of native widgets.

You have to understand that Leadwerks is still fairly new, at least in terms of community size and age. The communities for most of Leadwerks's competing engines are substantially larger, and with that comes more people writing these little blog posts and tutorials with all these little gotcha's and tips. For all intents and purposes, we're all still early adopters and have to figure these things out on our own.

Always glad to see contributions. Not to undermine your contribution or anything, but mind providing some sort of information as to what your library does? Maybe a screenshot or two?

Simple. You don't. Never, EVER, break standard convention without a damn good reason.

Andy_s is correct. Wavefront object files (.obj) do not store any animation data. You'll want to use FBX for that.

Incorrect. XBLA supports C++ just fine. Don't confuse the Xbox Live Arcade with the Xbox Indie Arcade. The Indie arcade is open to anyone as long as you are using C# with XNA. XBLA does not have these restrictions.

I'm pretty sure he wants to change it via code. This is actually pretty easy under windows. MSDN Forum link with examples.

No, it's largely because most of the people developing iOS games are one man "teams". They are mostly programmer art. A good example of what the device is capable of would be the Infinity Blade demo made by Epic Games. That runs amazingly well on the hardware with great visuals, shaders and a high polycount. It's running via the UDK which is significantly more bloated than LE3 will be. I'm expecting good things here.

Great to hear.

If I'm not mistaken, the licenses are not transferable.

I personally really enjoy his "tests". Very subjective. More importantly, I love how he only tested the absolute bare bone basic features and concluded that Fortran was faster*. *Don't get me wrong, Fortran _IS_ damn fast. On average however, it's on par with C or C++. Where it shines is that Fortran is designed for cluster computing, an area where C++ fails hard.

Come on Lumooja...this is the kind of stuff that is so damn easy to get right with just a quick bit of research. http://en.wikipedia.org/wiki/Fortran 1957 it is then. Easiest, or easiest to you? What paradigms does it offer? Can you work with it as a functional language? Pattern matching? Closures? What threading models does it offer? Fortran may be easy to learn initially, but keep in mind that a lot of it's paradigms (especially it's threading models for cluster computing) are fairly difficult to master.

You're off by seven years there, Lumooja. Fortran showed up in 1957, not 1950. Different languages have different paradigms and ease of use. Those are pretty good reasons to develop and use different languages.

Hello Rick, I'd like to introduce you to Lumooja.

Avoid using SoftImage Mod Tool if you have any intent whatsoever of selling your game. Mod tool is specifically designed for non commercial work. If you're looking for a free 3D modelling and animation package, the only one worth considering currently is Blender. If you're willing to spend some cash...there are arguably better solutions.

That's pretty much all it is. As mentioned, it's trivial to add it. There's no reason to release the API for that until you're ready to actually get something on steam.

Which unfortunately, no one can tell you. It's all behind that NDA. @Rick: Again, it's really trivial to add to your code base at a later time. In terms of code, they are not major features. Take Torchlight for example. They integrated steamworks in less than a week (as well as fixed a bug list a few miles long, which I'm pretty sure took up most of that time).

Well no, keep in mind, steamworks doesn't do a whole lot. The steam overlay and all that stuff works automatically on ANY game run via steam (remember, you can launch non steam games via steam). Steamworks is primarily just achievements and VoIP. Both of which are trivial to add to a code base. Giving that out to everyone would be ridiculous, considering that functionality uses and runs ON steams servers. Remember, getting published on steam isn't just an added API. That's the easy part. Valve actually does marketing and such for your game, as well as helping you polish your game and such. It's a big investment on their part. If they are going to provide support via an API that integrates into steam as well as marketing and experience...It makes a heck of a lot of sense to want a near finished product to work with. It shows you actually have something you might finish. Otherwise they're going to get a huge influx of half finished games with authors that lose interest. That costs Valve money.

You start by having a near finished title. I'm not trying to be sarcastic, but if it's not anywhere near finished, they don't want anything to do with you. Get a near finished title and then look into steamworks. Beyond that, it's all behind an NDA.

Just thought that I'd point out that Mono is NOT an IDE nor an editor. It's a combination of a compiler (with multiple frontends to handle C#, IronPython, Boo, etc.) and a runtime. What you're thinking of is Mono Develop, which isn't related to the Mono project (it gets it's name because it runs on top of Mono and can be used as a frontend to the Mono toolchain, but they are completely separate projects and development teams). I like the idea of embedding mono, but it's not something I'd push for from Josh either. If you want to embed Mono into Leadwerks, you've already got the tools to do so.

That pretty much covers it, yes. Precisely like the Treeview control that Josh has created for LE3's editor. It's a custom widget. Keep in mind Josh, QT and most other GUI toolkits don't use GDI or native widgets. They have their own rendering routines. They don't have access to ANY of the standard controls in any OS (with the exception of Nokia's OS's, where QT _IS_ the native GUI toolkit). The base wxWidgets toolkit only provides widgets native to the OS (with a few exceptions*) and does use GDI's native controls (proof). Most applications written with wxWidgets just use the standard widgets, or modify their functionality. Much like how you're building the LE3 Editor. You could create custom widgets for everything to give visual flare if you wanted. But you're sane and don't do so. You create custom widgets only when you need functionality that isn't provided. It's precisely the way MaxGUI works actually. Under windows it's a wrapper around GDI as well (proof). When the native toolkit doesn't provide functionality you need, you create a custom widget. It's not terribly complicated concept. The creators of Code Blocks and Audacity however, for whatever reason, decided to create completely custom drawn widgets for a lot of their application. Do I agree with their decision? Heck no. Is it a problem with the GUI library used? Not in the slightest. When you write an application in wxWidgets, it will look different on every OS purely because it will use the native windowing API's for the system. GDI on Windows, GTK under linux (which doesn't HAVE a native GUI library) and I believe it's using Cocoa under OS X. *Exceptions being like MDI under OS X and Linux. MDI is a windows paradigm, and while the controls are "supported" under other OS's, they're converted by the runtime to native tabbed interfaces and the like. There are only a couple of controls that do things like that, and they are well documented. ---- As I said though, use what makes you the most productive. The only reason I would bother switching to something other than Blitz for writing the editor would be my concern of Blitz applications no longer working on future versions of OS X. I expect Blitz and MaxGUI will continue to work on Windows and Linux for quite some time. ---- That's not what I said. I was pointing out that those two applications are using custom widgets. wxWidgets by itself does not. In precisely the same way that MaxGUI provides native widgets. Both however give you the option of creating custom widgets, if those provided by the system to not offer the functionality needed by your application.

*sigh* I'm not blind and I've worked with the code base. However, you're confusing custom drawn widgets with native controls. Code Blocks is using a lot of custom widgets as do most applications. As you're very much aware (having created them yourself for the LE3 editor) most GUI toolkits allow for custom widgets. wxWidgets (and GDI under windows, as that is what is being used internally) of course also allows this functionality. It's really pointless to argue this. wxWidgets is under the MIT license, feel free to check out the source. I have. ---- You don't have to like wxWidgets. I honestly don't care what you use, as long as you're productive in it. That said, don't spread FUD either.

MFC is a perfect example of the engineering at Microsoft back in the day. Overall, the concepts and paradigms in MFC are very well engineered. They then took those concepts and paradigms and took them entirely too far. And then created an even worse implementation. It's one of the reason I like wxWidgets. It uses the same concepts and paradigms, but scales them back to an appropriate level and keeps a nice, clean and usable implementation.