is Irrlicht irrelevant?
-
- Posts: 4
- Joined: Sat Sep 20, 2003 10:22 pm
is Irrlicht irrelevant?
It states on the irrlicht FAQ here:
http://irrlicht.sourceforge.net/faq.html
There are lots of other 3D Engines available. So what are the advantages of the Irrlicht engine?
- No dependencies from other libraries. The engine needs no other libraries and sdks to be installed. Not for programming with the engine and not for using the engine as end user. E.g. The engine will also start up if no DirectX is installed on the end user system.
This is not true. This morning I made a brand new minimal installation of Suse 8.0. I installed GCC 3.3.1, the Nvidia drivers for my card ( ftp client and unzip ). I compiled irrlicht which depends on OpenGL include files GL/gl.h, glx.h. These files in turn depend on X11 header files, so irrlicht is therefore dependent upon X-windows. Therefore complilation failed.
So the FAQ is incorrect.
If this is wrong, please give me explicit instructions as proof. I would love to see that.
Futhermore, if irrlicht is dependent upon X-windows, why should I use it? X-windows already comes with DRI and OpenGL support in hardware which will be much faster and more reliable than any software implementation. Why should I use Irrlicht? If I want a cross-platform game programming library ( I can't imagine why anyone would, when OpenGL is already very cross-platform ) use SDL or DirectFB.
Why should I use it?
If Irrlicht didn't depend on X-windows and I could run a full-screen OpenGL game on Linux with a minimal installation ( no X-Windows ), that would make Irrlicht highly desirable and distinguish itself from all the other engines.
If I can't see why I should use it, I ask, isn't Irrlicht irrelevant?
http://irrlicht.sourceforge.net/faq.html
There are lots of other 3D Engines available. So what are the advantages of the Irrlicht engine?
- No dependencies from other libraries. The engine needs no other libraries and sdks to be installed. Not for programming with the engine and not for using the engine as end user. E.g. The engine will also start up if no DirectX is installed on the end user system.
This is not true. This morning I made a brand new minimal installation of Suse 8.0. I installed GCC 3.3.1, the Nvidia drivers for my card ( ftp client and unzip ). I compiled irrlicht which depends on OpenGL include files GL/gl.h, glx.h. These files in turn depend on X11 header files, so irrlicht is therefore dependent upon X-windows. Therefore complilation failed.
So the FAQ is incorrect.
If this is wrong, please give me explicit instructions as proof. I would love to see that.
Futhermore, if irrlicht is dependent upon X-windows, why should I use it? X-windows already comes with DRI and OpenGL support in hardware which will be much faster and more reliable than any software implementation. Why should I use Irrlicht? If I want a cross-platform game programming library ( I can't imagine why anyone would, when OpenGL is already very cross-platform ) use SDL or DirectFB.
Why should I use it?
If Irrlicht didn't depend on X-windows and I could run a full-screen OpenGL game on Linux with a minimal installation ( no X-Windows ), that would make Irrlicht highly desirable and distinguish itself from all the other engines.
If I can't see why I should use it, I ask, isn't Irrlicht irrelevant?
-
- Posts: 81
- Joined: Fri Aug 22, 2003 12:06 pm
- Location: Germany
- Contact:
Don't pin Niko down on what he wrote in the FAQ. Most home user linux distributions install X-Windows by default. Moreover, you can't compare OpenGL and the Irrlicht engine. OpenGL is very lowlevel, while the Irrlicht API (which uses OpenGL, btw., so I don't understand your OpenGL support argument) is located an abstaction level higher. The header GL/gl.h is the default header for the OpenGL declarations, so you can't blame Niko neither for using them nor for the X-Windows dependencies.
Cheers.
Cheers.
matthias gall, lead programmer at sechsta sinn - email matthias@sechsta-sinn.de
It's a 3d engine. It requires a 3d graphics capable system to work. This means that you have to have a windowing system in *nix. And Irrlicht does not depend on xwindows. Xwindows has support for gl, providing the headers. If you find another windowing system for *nix that has gl support, niko might add in support. But no, it cannot run in a console, it needs a graphics capable windowing system.
It doesn't need any OpenGL libraries. If you don't want it to run in OpenGL... change the driver to software mode.
What I interpret "No dependencies from other libraries." to mean is that I don't have to set up the libraries for STLPort like Ogre needs, GLUT,
ViaVoice-DL or anything else like that.
OpenGL does not support hardware accelerated multimonitoring. DirectX does. This is a feature that my game has. OpenGL = NO. It doesn't mean OpenGL is bad, it just means it doesn't have what I want.
Irrlicht makes it easy for me to add objects into a world simply by not making me have to worry about vertices, vertex buffers, multiple scene managers, yadda-yadda. It also makes it so that if I choose to port my code to another OS other than Windows, I won't have to re-code near as much. And in the end, for me, that's what I want. I like worrying more about my game dynamics then whether or not I can scrimpt out a few frames more if I go with a different culling algorithm.
If you can't see a reason that you can't use it. Then don't.
What I interpret "No dependencies from other libraries." to mean is that I don't have to set up the libraries for STLPort like Ogre needs, GLUT,
ViaVoice-DL or anything else like that.
The reason you can't imagine why anyone would want to use anything but OpenGL is the same reason someone lambasted me for using DirectPlay in my application. (I've since switched to RakNet because it has more of what I want.) Just because it's right for you doesn't make it right for me.Why should I use Irrlicht? If I want a cross-platform game programming library ( I can't imagine why anyone would, when OpenGL is already very cross-platform ) use SDL or DirectFB.
OpenGL does not support hardware accelerated multimonitoring. DirectX does. This is a feature that my game has. OpenGL = NO. It doesn't mean OpenGL is bad, it just means it doesn't have what I want.
Irrlicht makes it easy for me to add objects into a world simply by not making me have to worry about vertices, vertex buffers, multiple scene managers, yadda-yadda. It also makes it so that if I choose to port my code to another OS other than Windows, I won't have to re-code near as much. And in the end, for me, that's what I want. I like worrying more about my game dynamics then whether or not I can scrimpt out a few frames more if I go with a different culling algorithm.
If you can't see a reason that you can't use it. Then don't.
Crud, how do I do this again?
There is not much to add. Saigumi, Lonesome and Matthias already explained everything.
I simply want to say that with 'no other libraries' I meant that It does not use that army of libraries other engines use. Like boost, external STL implementations, DevIL and so on. It's clear that the engine has to use some os specific libary to get the graphics somehow on the screen: In Win32 it's the Win32 API, in Linux it's X Windows.
And, if you like, the engine runs and compiles really without any other library. You can disable compiling with all external libraries manualy. Just out comment the defines in irrCompileConfig.h header file. And you can only use the DT_NULL device. You won't see anything, but everything like collision detection, texture loading an manipulating, mesh loading and so on works.
I simply want to say that with 'no other libraries' I meant that It does not use that army of libraries other engines use. Like boost, external STL implementations, DevIL and so on. It's clear that the engine has to use some os specific libary to get the graphics somehow on the screen: In Win32 it's the Win32 API, in Linux it's X Windows.
And, if you like, the engine runs and compiles really without any other library. You can disable compiling with all external libraries manualy. Just out comment the defines in irrCompileConfig.h header file. And you can only use the DT_NULL device. You won't see anything, but everything like collision detection, texture loading an manipulating, mesh loading and so on works.
Last edited by niko on Mon Sep 22, 2003 10:52 am, edited 1 time in total.
-
- Posts: 4
- Joined: Sat Sep 20, 2003 10:22 pm
anything else?
>Niko wrote:
>And, if you like, the engine runs and compiles really without any other library. >You can disable compiling with all external libraries manualy. Just out comment >the defines in irrCompileConfig.h header file. And you can only use the DT_NULL >device. You won't see anything, but everything like collision detection, texture >loading an manipulating, mesh loading and so on works.
Niko,
The extremely minimal dependency on other libraries is very good. Other developers should follow your lead, in that respect.
The ability to render to the DT_NULL device could be handy in some cases in development but already, for years, the free software implementation of OpenGL called MESA has allowed the same trick.
Specifically, what does Irrlicht add to these APIs, above and beyond the OpenGL or DirectX APIs, in terms of functionality? You listed one function: the ability to render to a null device.
I'll throw one in that none of you mentioned : Irrlicht has some UI widgets. That's handy.
What else does it do? Allow us to author DirectX applications on Unix? That would be a big step in the wrong direction.
Multi-heading doesn't count.
Anything else?
If the list is short, I think your time would be better spent contributing to MESA. There are very few people who have the knowledge and ability to work at that level and you could really advance that project instead of repeating what's already been done many times before.
>And, if you like, the engine runs and compiles really without any other library. >You can disable compiling with all external libraries manualy. Just out comment >the defines in irrCompileConfig.h header file. And you can only use the DT_NULL >device. You won't see anything, but everything like collision detection, texture >loading an manipulating, mesh loading and so on works.
Niko,
The extremely minimal dependency on other libraries is very good. Other developers should follow your lead, in that respect.
The ability to render to the DT_NULL device could be handy in some cases in development but already, for years, the free software implementation of OpenGL called MESA has allowed the same trick.
Specifically, what does Irrlicht add to these APIs, above and beyond the OpenGL or DirectX APIs, in terms of functionality? You listed one function: the ability to render to a null device.
I'll throw one in that none of you mentioned : Irrlicht has some UI widgets. That's handy.
What else does it do? Allow us to author DirectX applications on Unix? That would be a big step in the wrong direction.
Multi-heading doesn't count.
Anything else?
If the list is short, I think your time would be better spent contributing to MESA. There are very few people who have the knowledge and ability to work at that level and you could really advance that project instead of repeating what's already been done many times before.
Re: anything else?
I've never used Mesa directly, but as I can read from the homepage, it is very similar to OpenGL. But OpenGL can not be compared to Irrlicht, it is completely different, it is more highlevel. For example, if you write a game with OpenGL, you usually need to write a framework for your game, for loading textures, drawing fonts, and so on. This would look like this:LoveOpenGL wrote:I'll throw one in that none of you mentioned : Irrlicht has some UI widgets. That's handy.
What else does it do? Allow us to author DirectX applications on Unix? That would be a big step in the wrong direction.
Code: Select all
YourGame -> YourWin32FrameWork -> OpenGL -> Win32 -> Hardware
Code: Select all
+-> OpenGL -> Linux -> Hardware
|
YourGame -> Irrlicht -+-> OpenGL-> Win32 -> Hardware
|
+-> Direct3D -> Win32 -> Hardware
|
+-> Direct3D -> XBox (someday?) -> Hardware
|
+-> SoftwareRenderer
|
+-> NullDevice
And to answer your question "What else does it do?":
- Abstracts the operating system. (File access, Input processing, ...)
- Abstracts the rendering API (OpenGL, D3D)
- Loads textures.
- Loads meshes.
- Provides algorithms for 3d rendering like OctTrees, ParticleSystems, ShadowVolume generation, ...
- Provides other useful methods for 3d applications like collision tests, scene graph, animators, etc.
- Provides GUI system
- And most important: It does all this with a extremely easy to use interface.
-
- Posts: 20
- Joined: Mon Sep 08, 2003 6:35 am
- Location: India
Mesa is developed by a person like Niko.Why in the first place did he write Mesa when Opengl is already there? Irrlicht is only version0.4.1. It may advance in many ways. For me, I tried to learn Opengl, well, understood the basics from Nehe , a good person similar to Niko. But to understand all the low level code is very time taking and is another specialisation.
But the net is a good place to be in ,is because of people like Niko, Nate Robins etc. Please give goodness back to goodness.
I will learn more coding one day to be more useful, in the meantime I will try to develop some levels and characters for my friends in the net.
But the net is a good place to be in ,is because of people like Niko, Nate Robins etc. Please give goodness back to goodness.
I will learn more coding one day to be more useful, in the meantime I will try to develop some levels and characters for my friends in the net.
Niko has done a great job with Irrlicht and the original poster is missing the point of the engine entirely. It is NOT a graphics API like DX or OGl it is a rendering and utility engine that encapsulates greatly many common functions used in games and with a choice of API.
This is NO easy task I can assure you. I wrote my own Framework in DX9 and it was only half as robust and featured as Irrlicht so why re-invent the wheel. irrlicht engine is very flexible, extremely easy to get to grips with and most importantly for those who could maybe do their own engine (and as such wonder why bother with someone elses) is that it has been tested by MANY people on many setups (ie us the users) and therefore is far more robust than an individuals framework is likely to be.. that and it takes care of the very low level stuff like caps checking and fallbacks means it is in a different ball-park alltogether from a simple gfx api like OGL.
Realise it is an abstraction layer/wrapper/whatever you will call it and you will understand why it is not irrelevent!
This is NO easy task I can assure you. I wrote my own Framework in DX9 and it was only half as robust and featured as Irrlicht so why re-invent the wheel. irrlicht engine is very flexible, extremely easy to get to grips with and most importantly for those who could maybe do their own engine (and as such wonder why bother with someone elses) is that it has been tested by MANY people on many setups (ie us the users) and therefore is far more robust than an individuals framework is likely to be.. that and it takes care of the very low level stuff like caps checking and fallbacks means it is in a different ball-park alltogether from a simple gfx api like OGL.
Realise it is an abstraction layer/wrapper/whatever you will call it and you will understand why it is not irrelevent!