Hello All,
I saw a post like this for another software before and it contained a lot of good tips and pointers to help newcomers out in the early to mid days.
So the start of using a new tool comes with a learning curve and many iterations of code to refine your skills to the point where they are highly effective. To this end what things have you learnt through your IrrLicht journey that you wish someone had told you before you started.
I would hope this post to help myself as well as other new joiners to the community.
Thanks All!
Things I wish I knew before starting IrrLicht
-
LunaRebirth
- Posts: 386
- Joined: Sun May 11, 2014 12:13 am
Re: Things I wish I knew before starting IrrLicht
Not really for before starting Irrlicht, but before starting to use an engine;
How useful an open source engine is.
Bug? Can fix it yourself. Create new subclasses? Copy-paste & edit. Need new things supported? See code snippets.
Other closed-sourced engines, your best bet is submitting a form stating the issue, or finding a way around the issue.
How useful an open source engine is.
Bug? Can fix it yourself. Create new subclasses? Copy-paste & edit. Need new things supported? See code snippets.
Other closed-sourced engines, your best bet is submitting a form stating the issue, or finding a way around the issue.
-
chronologicaldot
- Competition winner
- Posts: 688
- Joined: Mon Sep 10, 2012 8:51 am
Re: Things I wish I knew before starting IrrLicht
Before?
I wish I knew the terminology. Back when I first started, I wasn't too familiar with terms like "parallax mapping" or "particle" (in the CGI context).
Since I didn't understand Irrlicht to begin with, I decided to dig into the code. It took a year, but I finally found out what was available (for the most part) and how these things fit together. Do the homework: Go through the code. You'll learn plenty of things while you're at it.
It would have been nice to know the logic behind the engine design before jumping right in and trying to use it. That would have saved alot of needless effort. Most engines don't do this. It also gives you some idea of your limitations.
So while I'm talking about it, let me give you a very brief overview:
Irrlicht is meant to be a self-contained yet generic engine. It's meant to do all the boiler-plate 3D gaming-related stuff such as rendering, mesh management, scene management, bone-animation classes, particle creation, matrix transformations, etc. ... about any basic task you can do for a game without any actual game logic. Oh, and if you want some unique effect or special GUI element, chances are, you will need to make it yourself.
The engine has three primary required components and two extra components. The three required components are the "device" (the box that holds everything), a video driver (a wrapper for OpenGL, Burnings, DX, etc.), and a file system manager. More on these in a moment. The two extra components are the GUI manager and the Scene manager.
The device is just that: It links you to the hardware and can give you a couple of useful things, but you'll mostly use it to 1) set the "event receiver" (a class with a method used for receiving input from the user) and 2) accessing the other components. Notably, you can also embed Irrlicht into other programs via the device. This has proven rather tricky for people, however, and the information available in this regard seems to be either scarce or outdated.
The video driver is what you do all the drawing with. Every draw call reroutes through this. The main functions are all 3D based. In fact, behind the scenes, many of the 2D draw calls also happen to be 3D ones. That can be annoying (at least for me) if you want smooth drawing (like nice gradients and edges), but Irrlicht's default image class - which can be converted to textures for drawing - is easy for libraries like AGG to copy to.
The video driver acts as an image cache, so whenever you load image files, you do it via the video driver interface, and it will automatically save them. No need for you to make and manage your own cache. 
(Unless you create a new, blank image, of course.) The video driver also lets you set the render target and the drawing area, so you can render to textures for environment maps (simulating reflections) or create a 4-screen multiplayer game (see the Stunt Marble Racer game by Brainsaw).
The file management is self-descriptive: It gives access to files by loading a directory into a "file list" which you can sort through to find the names you want. Of course, it's still a process of 1) pick a path 2) find a directory name from the list 3) load the new path 4) find a file name etc. And you may have to mess with the fact that Windows and Linux load file names with different case preservation (on Windows "LOG" and "log" are read the same).
The scene manager and GUI manager are optional, as evidenced by the fact that, when you run the main loop for Irrlicht (that is, you have a while-loop with device->run() as the conditional), you don't have to actually use them. Irrlicht even lets you create new scene managers so you can store multiple scenes. This can be helpful for game design. The GUI manager could be replaced by your own GUI system. In fact, you can even compile the engine without it, saving space! (I believe you can do this with the scene manager too, but I forget.) Both Irrlicht scene nodes and GUI elements allow for their draw calls to be overridden, so you can draw anything you want in them when you inherit those classes. This has allowed some people to draw mini 3D scenes in GUI elements.
Wait! There's more! Irrlicht also has a particle generator. I can't speak for it's quality, but it's something.
There are a number of extras you can find sitting around the boards. Be mindful that alot of code is abandoned. Some isn't. And alot of stuff may still work (assuming it didn't rely on some bug in the engine).
Finally, perhaps the most important thing you should know: The dev branch from subversion is more up-to-date and more stable than the published version. CuteAlien says it's alot of work to publish a version of Irrlicht, so he does it more infrequently than a blue moon. Irrlicht is very stable, but one or two things may break in that long span of changes. For that reason, you need to read the changelog and keep up to date with the developments (in the "Open Discussion and Dev Announcements" http://irrlicht.sourceforge.net/forum/viewforum.php?f=2 ).
I wish I knew the terminology. Back when I first started, I wasn't too familiar with terms like "parallax mapping" or "particle" (in the CGI context).
Since I didn't understand Irrlicht to begin with, I decided to dig into the code. It took a year, but I finally found out what was available (for the most part) and how these things fit together. Do the homework: Go through the code. You'll learn plenty of things while you're at it.
It would have been nice to know the logic behind the engine design before jumping right in and trying to use it. That would have saved alot of needless effort. Most engines don't do this. It also gives you some idea of your limitations.
So while I'm talking about it, let me give you a very brief overview:
Irrlicht is meant to be a self-contained yet generic engine. It's meant to do all the boiler-plate 3D gaming-related stuff such as rendering, mesh management, scene management, bone-animation classes, particle creation, matrix transformations, etc. ... about any basic task you can do for a game without any actual game logic. Oh, and if you want some unique effect or special GUI element, chances are, you will need to make it yourself.
The engine has three primary required components and two extra components. The three required components are the "device" (the box that holds everything), a video driver (a wrapper for OpenGL, Burnings, DX, etc.), and a file system manager. More on these in a moment. The two extra components are the GUI manager and the Scene manager.
The device is just that: It links you to the hardware and can give you a couple of useful things, but you'll mostly use it to 1) set the "event receiver" (a class with a method used for receiving input from the user) and 2) accessing the other components. Notably, you can also embed Irrlicht into other programs via the device. This has proven rather tricky for people, however, and the information available in this regard seems to be either scarce or outdated.
The video driver is what you do all the drawing with. Every draw call reroutes through this. The main functions are all 3D based. In fact, behind the scenes, many of the 2D draw calls also happen to be 3D ones. That can be annoying (at least for me) if you want smooth drawing (like nice gradients and edges), but Irrlicht's default image class - which can be converted to textures for drawing - is easy for libraries like AGG to copy to.
The video driver acts as an image cache, so whenever you load image files, you do it via the video driver interface, and it will automatically save them. No need for you to make and manage your own cache. (Unless you create a new, blank image, of course.) The video driver also lets you set the render target and the drawing area, so you can render to textures for environment maps (simulating reflections) or create a 4-screen multiplayer game (see the Stunt Marble Racer game by Brainsaw).The file management is self-descriptive: It gives access to files by loading a directory into a "file list" which you can sort through to find the names you want. Of course, it's still a process of 1) pick a path 2) find a directory name from the list 3) load the new path 4) find a file name etc. And you may have to mess with the fact that Windows and Linux load file names with different case preservation (on Windows "LOG" and "log" are read the same).
The scene manager and GUI manager are optional, as evidenced by the fact that, when you run the main loop for Irrlicht (that is, you have a while-loop with device->run() as the conditional), you don't have to actually use them. Irrlicht even lets you create new scene managers so you can store multiple scenes. This can be helpful for game design. The GUI manager could be replaced by your own GUI system. In fact, you can even compile the engine without it, saving space! (I believe you can do this with the scene manager too, but I forget.) Both Irrlicht scene nodes and GUI elements allow for their draw calls to be overridden, so you can draw anything you want in them when you inherit those classes. This has allowed some people to draw mini 3D scenes in GUI elements.
Wait! There's more! Irrlicht also has a particle generator. I can't speak for it's quality, but it's something.
There are a number of extras you can find sitting around the boards. Be mindful that alot of code is abandoned. Some isn't. And alot of stuff may still work (assuming it didn't rely on some bug in the engine).
Finally, perhaps the most important thing you should know: The dev branch from subversion is more up-to-date and more stable than the published version. CuteAlien says it's alot of work to publish a version of Irrlicht, so he does it more infrequently than a blue moon. Irrlicht is very stable, but one or two things may break in that long span of changes. For that reason, you need to read the changelog and keep up to date with the developments (in the "Open Discussion and Dev Announcements" http://irrlicht.sourceforge.net/forum/viewforum.php?f=2 ).
Re: Things I wish I knew before starting IrrLicht
You better come with a fresh mind and knowing nothing, in the end, everything comes out on its own
If you needed help with any specific topic, just throw a message here, someone will be more than glad to help.
If you needed help with any specific topic, just throw a message here, someone will be more than glad to help.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Things I wish I knew before starting IrrLicht
I learned most of what I know from poking around with intellisense lol. You can access most of the engine by derefrencing the device, environment, driver, ect. and scrolling around and reading the doc. Also look in the namespaces irr::*. The doc in VS 2017 is the same as the online doc from what I could tell. Just jump in lol. Oh yeah, the tutorials can you help you get started. It's amazing the kind of programming tools we got nowadays. Without intellisense I would be slowly referencing online docs switching back and forth between my editor and browser.