Posix only defines that PATH_MAX may is defined through limits.h.
GNU/Hurd has removed this definition without violating the standards.
Mupen64Plus still relies on it and we work around that problem by
defining PATH_MAX as 4096 in all places it is needed. This is not 100%
correct as their are ways to generate longer paths, but mupen64plus must
be heavily refactored in some places to fix the actual problem.
Some games experience fog problems (like goldeneye with doors wich are not "fogged" while the rest of the scene is).
Before, you can only disable, or let n64 choose if an object have to be "fogged" or not.
With this new method, you can disable, let n64 choose, or force fog generation on all rendered objects.
Force fog generation can create probs on some game during rendering (goldeneye mission selection menu) but can increase visual quality of some games (Goldeneye doors).
I change option, it's no more "EnableFog" but "FogMethod" (wich is more explicite):
"Enable, Disable or Force fog generation (0=Disable, 1=Enable n64 choose, 2=Force Fog)"
Anisotropic filtering:
-This filtering method is independant of others (Bilinear and Trilinear) but only work with mipmaping.
-It create a new option in .cfg: "AnisotropicFiltering".
-Valid value are: 2-4-8-16
OGLGraphicsContext check if extension is avaible and get the maximum value of aniso supported by hardware (If user want less, it set this maximum value to the value user want).
I also add two methods:
-IsSupportAnisotropicFiltering() << Return the bool value
-getMaxAnisotropicFiltering() << Return max value of aniso to use (limited by hardware or user)
OGLTexture now need access to "OGLGraphicsContext.h" class to work well:
-It just apply max aniso value that OGLGraphicsContext return
-Little modifications about mipmap: gluBuild2DMipmaps has been remove (this remove a dep) for a better option: GL_GENERATE_MIPMAP wich automaticaly generate mipmap when glTexImage2D function is called (It's even possible that this is done directly by hardware. I hope this will remove ATI radeon lag with some games when mipmap is activated).
-Because we don't use two methods (one for mipmap: gluBuild2DMipmaps, and one without: glTexImage2D) because now we use GL_GENERATE_MIPMAP: glTexImage2D has been "factorised" and put to the end of the method.
- little rearrangement in some options order (in Config.h .cpp: texture filter, force, enhancement) in order to give a more "readeable code".
- Options text explanations are now more explicite in what they really do.
- TextureFilteringMethod is 1 by default (wich is Bilinear). Could be 2 (Trilinear) by default because current PC can easealy use it.
If GL_TEXTURE_MIN_FILTER is set to GL_LINEAR (instead of GL_LINEAR_MIPMAP_NEAREST) before making mipmaping, it create graphic bugs, so GL_TEXTURE_MIN_FILTER has to be set to the correct status.
- little rearrangement in some options order (in Config.h .cpp: texture filter, force, enhancement) in order to give a more "readeable code".
- Options text explanations are now more explicite in what they really do.
- TextureFilteringMethod is 1 by default (wich is Bilinear). Could be 2 (Trilinear) by default because current PC can easealy use it.
When EnableMipmaping is true, the texture filtering is Bilinear (except if your force no filtering):
GL_NEAREST (mag filter) + GL_LINEAR_MIPMAP_NEAREST (min filter) = two GL_LINEAR = Bilinear
(Trilinear will come soon)
Now ForceTextureFilter is used for what it has to do:
"Force to use texture filtering or not (0=auto: n64 choose, 1=no filtering, 2=force filtering)"
Also change the definition in cfg file to be more clear.
This don't choose wich filter you want or not, it only force to:
-Leave the N64 choose if it want to filter a texture or not
-Don't filter any texture (nearest neighbor
-Force filtering on all texture.
Filtering type (trilinear, anisotropic, etc...) will come soon. For now, the only filter is Bilinear without mipmap.
The g++ also exports symbols of implicit instantiations of templates. These
aren't part of the api and must not be accessed by any other part of
mupen64plus. We can use version-scripts to surpress these symbols without using
explicit instantiations of all templates we use.
Every time a header is changed, the user had to cleanup the whole project and
then rebuild it. It is quite easy to fix and should help a lot when working on
the project. The dependency files will be created at the first run (when
dependency tracking isn't useful anyway) and should create nearly no overhead.
