Slashdot Mirror
Irrlicht - Fast Realtime 3D Engine
Surye writes "Though a few days late on the release, Irrlicht has released version 0.7 of its engine. The site describes it as 'an open source high performance realtime 3D engine written in C++. It is completely cross-platform, using D3D, OpenGL and its own software renderer, and has all of the state-of-the-art features which can be found in commercial 3d engines.' Bindings for java, perl, ruby, and python, and it is platform independent (only implemented currently on Windows and Linux, but when it moves to other platforms, the code will be completely portable). The feature list is simply amazing, and since it's still being quite actively developed, I can see this becoming a major player soon."
Imagine if the parrot or mono guys wrote really slick bindings for this and made them availible on all supported platforms. Personally, I would rather have a game that is just "pretty" fast but isn't bound to a particular operating system to one that is really fast, but that I cannot take to any platform I want.
If PERL 6 and Parrot are able to get really mature in the next 6 months to a year, they owe it to their users to try to provide solid support for a library like this as part of the parrot distribution. A language like PERL 6 which is supposed to be really slick thanks to ruby's influence on its design would be great for opening up game development to the masses.
The way I see it, unless a game written in C/C++ is going to completely max out your CPU and GPU then it's probably worth being written in C# or PERL 6 eventually. Something like this would be Microsoft's worst nightmare for home users who play games a lot.
Click here or a puppy gets stomped!
We've been looking at Crystal Space, as well as Irrlicht and others such as the Nebula Device. In the end, we ended up buying licenses for Torque from GarageGames, because it has been used to do several games and it has lots of integrated tools built right into the engine. You can move and reshape just about everything inside the running game. Now, it is a bit dated, but there will be a newer version out hopefully soon with all those shaders the kids like. For now, it is definitely good enough for most people. Most people couldn't produce content to match the newest engines anyways... ;-)
;-)
Really, Crystal Space or the Nebula Device may be better in themselves, but if we were to use them, we'd have to recreate all these tools ourselves. Hint: if you are gonna do a game of any serious magnitude, you will need tools, and lots of them. If Crystal Space wants to start seeing games built, they should include starter kits (as in something simple to start modding instead of starting from scratch) and more importantly tools. Tools for manipulating terrain, creating particle effects, placing objects and so on. Being able to import stuff from Quark or Maya is not enough. DO you as a level designer want to place everything in your game by entering numbers in a text file? I thought not... =)
As for Irrlicht, I really like it a lot. It is cool, it is really, really easy to get something up quickly in, it has good performance and plenty of good examples to get one started. However, it is nowhere finished enough (but I can wait) and it is not a game engine - it is a 3D rendering engine that could very well be used to power an awesome game engine. I think some people over there are working on such beasts, though I don't know the status... if any of them also read this, remember the tools boys!
Spine World
People have to stop abusing this term. There's nothing in that API that even qualifies it as soft-real-time. Real-time APIs have runtime estimation, deadline scheduling, and other things that have to do with managing time.
Not that I'd expect it to be real-time given it doesn't require any real-time OS features, and not that I know anything about whether game developers can use real-time features, just a pet peeve.
Someone had to do it.
The point is that stuff such as file handling should be unified within the game, but everyone will have their own system. We use PhysFS to abstract everything within one big file tree. If you use PhysFS, you have to change, or, if you want to be able to upgrade to a higher version later without any trouble later, rewrite all the Irrlicht code that uses files, rather than writing some kind of plugin/implementing a generic interface.
XML parsing was possibly a bad example, but we've basically got two XML parsers compiled into the game right now. Irrlicht's XML parser would be a pain to get running with PhysFS, and it only works once the graphics engine is set up, at which point we'll actually have done a considerable amount of XML file loading already.
The problem with all this added functionality is that it's fairly laborious to work around if you don't want it, and it's quite likely that that is the case, because the way it's integrated into the engine isn't especially flexible.
Input handling is another one of these problems. We support keyboard and joystick input in our game. Because keyboard input is heavily tied in with the windowing abstraction, and thus the graphics engine, it seems sensible to put it into the graphics engine. It isn't that clever though, because you'd now have two seperate systems doing almost the same thing - the graphics engine doing keyboard input, and the input system doing joystick input. It's barmy!
I also shy away from anything but graphics being dependent on the graphics engine. If there was an Irrlicht file handling module, an Irrlicht Input module, and an Irrlicht graphics module, that would be great. If I decided to drop Irrlicht graphics I could still use Irrlicht file handling without having this behemoth sleeping in my source tree. As it is, I wouldn't even want to rely on loading sound files with the Irrlicht file system, because sound and graphics are, and should be separate.
It can certainly be worked around, it would just be a lot friendlier to make it inherently more extensible, for example by creating a very simple file handling interface, providing a standard implementation that uses fstream objects or whatever, but leaving you the ability to create another implementation to that interface which happens to use your file handling system of choice. Lots of C-based libraries use callbacks for this kind of stuff, and in C++, with polymorphism in the language, it should be even cleaner!
~phil