This is fullscreen antialias. Unfortunately not documented which values it takes. But there is also a per material antialias in SMaterial::AntiAliasing which takes one of those values: http://irrlicht.sourceforge.net/docu/na ... 3e8f2b149d
Maybe you get better results for that.
Thanks for the answer, but how do I use it? I can't figure out where to put that code...
BONUS QUESTION
This is not related to anti-alias but I want to know if i'm correct.
In order to statically link, you need a lib file and compile with your main.cpp file. Am I correct?
In order to dynamically link, you need a lib file and a dll file then compile your main.cpp file with lib file. Then in order to run your program, you'll need the dll file.
But if you want to compile your main.cpp without linking lib file, you declare all functions/classes inside the .h file so that your .h file act as lib file...am I correct?
Each meshbuffer has a material (more or less that's the definition of a meshbuffer in Irrlicht - having geometry + a material). You can access meshbuffers through the mesh. Alternatively you can access the materials of scenenodes (they copy materials by default when you create them so each scenenode can have different materials even if they share the same mesh) with ISceneNode::getMaterial.
And for the bonus question: You can't link to a library with header only. What your compiler does is that it creates object code (which is mainly machine code) for each .cpp and each .c file. The compiler works from top to bottom and in each line it needs to know all the symbols used in that line. So if you want to use a function it has to be declared first. But to allow having functions use each other the c/cpp languages allow to have declaration before the definition. So you just tell the compiler there is a function or class of that name and tell it that the definition will follow. And this trick also allows also to have source distributed over several compile units. Because the compiler only needs the declarations while the definitions are only necessary at link-time.
So you can use functions/ classes from other files as long as each file has the declarations. To avoid typing too much and ensuring each file uses the same declarations you put them in a header file and include that (an include is basically working like copy-paste - the compiler just copies the whole file in place of the include line).
So why can't you link to headers only? Because the linkers job is to create a program which contains all the machine code needed to run. So it needs the machine code generated for your function and class definitions. And that is not in the headers but in the object files. You can link them in 3 ways. First one is that the compiler created an object file (.o or .obj depending on compiler) for each .c/.cpp file and you can link directly to those. This is what your project file (or Makefile) generally does for you when you have several sources. It simply ensures each generated object file from the compiler is at the end given to the linker. Second solution are lib files (.lib on Windows and .a on Linux). Those are basically object files put into a single file (more or less like a zip or tar file puts several files together into one file). So you can give that file to the linker and it contains all object files of a library. And last dynamic means the dll contains the obj file but they are not linked into your exe but loaded at runtime. And on Windows there is a tiny .lib file which gives the loader for those dll files some hints how to load the functions (you can also do the dll loading manually in your code then you won't even need that lib, that's the way plugins are for exampley typically coded).
So maybe you heard that some libs only need the header to be linked. For example many boost libraries work like that. Given the information above you could already figure it out. Obviously the linker needs all code which should run - so that can't be avoided. But what can be done is implementing class-functions directly in the header. That way the code is included in each .cpp file that includes that header. And thereby put into each object file. But a library has to be coded specifically like that for that to work and Irrlicht isn't. And likely won't ever be - because while this is comfortable (no more linker troubles) it also has disadvantages. That code is now compiled again for every .cpp file - which is slow (though can be reduced with pre-compiled headers). And the object files get larger because each of them now contains copies of the same compiled header-code. So linking them will take longer. And in large projects that starts to make a noticeable difference.
Pythy Python wrote:I heard that some drivers support anti-alias and some don't. But I used anti-alias in Panda3D before and it worked well. What's going on here?
Your code is enough to enable MSAA even in a window; works for me in Linux. No need to edit the per-node material.
You might want to add printfs to the windows device creation function to see if and why you didn't get AA.