Rename camera near and far private members to avoid conflict with Windows.h defines

[0x0ACB]

Sadly Windows.h defines macros for both near and far so naming variables like this, especially in header files is causing a lot of issues. As soon as any file includes Windows.h before camera_3d.h your build will simply fail. While camera_3d.h does already include undefs for mingw builds this is insufficient as those macros are used in other parts of the windows headers as well.

This PR simply renames Camera3D::far and Camera3D::near to Camera3D::camera_far and Camera3D::camera_near to avoid this issue alltogether. Since all public methods stay the same this shouldn't cause any downstream issues.

[AThousandShips]

These could alternatively be undefined with other things in typedefs.h where a lot of things windows badly defines are undefined, like min/max

[0x0ACB]

That won't work. While you can remove the min/max defs from Windows.h with WIN32_LEAN_AND_MEAN or NOMINMAX undefining far and near has a lot of issues as these macros are used in a lot of additional headers that then won't compile at all. Renaming them is the only solution to this issue that I got to work. A lot of function definitions in windows headers are using the near and far macros.

[RandomShaper]

This PR could also remove this snippets I had to add to some places precisely for the root issue being addressed here:

#ifdef MINGW_ENABLED
#undef near
#undef far
#endif

Those wouldn't be needed anymore.

[0x0ACB]

Don't think these can simply be removed in other locations. Atleast the couple where I found this macro there were local variables called near and far . So it would require a lot more refactoring to get rid of all of those

[akien-mga]

Makes sense to me. Those are private members so it doesn't break compat for C++ modules.

[akien-mga]

Could you amend the commit message to be more explicit, e.g. like I renamed the PR? This would prevent confusion about this possibly renaming the actual exposed near and far properties. And we like commit messages starting with a capital letter ;)

Don't think these can simply be removed in other locations. Atleast the couple where I found this macro there were local variables called near and far . So it would require a lot more refactoring to get rid of all of those

Would be nice to do as a follow-up PR if you're interested.

[0x0ACB]

Could you amend the commit message to be more explicit, e.g. like I renamed the PR? This would prevent confusion about this possibly renaming the actual exposed near and far properties. And we like commit messages starting with a capital letter ;)

Done.

Would be nice to do as a follow-up PR if you're interested.

Will do once I find time for that.

[fire]

@akien-mga This might require compatibility methods so we don't change the existing api for Camera3D. I am not very familiar with compatibility methods to guide.

[AThousandShips]

These are private member variables in the c++ class, not exposed properties

[fire]

If they're private apis, that's fine.

[akien-mga]

Thanks!

[0x0ACB]

You alright mate?

This is not even about min and max macros, which by the way you can turn of via #define NOMINMAX.