* Fixing typecast warnings generated by visual studio 2019 in examples.
* Changes to fixes based on feedback
Co-authored-by: Jeffery Myers <JefMyers@blizzard.com>
* Add a function to know if two lines intersect each other and if yes, get the intersection point
* Remove indents
* Rework the declaration of the 'Vector2LineIntersect' function, and add the 'Vector2SegmentIntersect' function
* Remove bad indents
* Fix compilation issues
* Fix compilation error
* Fix compilation error
* Replace keyword '_Bool' by 'bool'
Vector3Reflect exists but not Vector2Reflect. The code is pretty much the same.
I'm not sure what RMDEF does, but I added it to match other function definitions (haven't done much C programming, maybe I'm missing something). Can someone explain to me what it does?
* Adding Norm and Remap functions
// Normalize input value within input range
// Remap input value within input range to output range
* Rename Norm to Normalize
To make it uniforms with Raylib's functions
* Calculate Remap without other functions
Just for clarification, no plans to remove libc dependency, just did some code analysis to see how much raylib depend on stardard C library. My conclusions:
- stdlib.h: primary dependency is for malloc() and free()
- stdio.h: primary dependency is for FILE access, maybe it could go through a custom ABI?
- string.h: just around 8 functions required
- math.h: just around 8 functions required
- others: 1-2 functions required for some other headers
- Added Vector3OrthoNormalize() to raymath.h - not sure if it is correct
- Implemented MeshBinormals() - Mesh struct has not a place for them...
- Updated model_material_pbr example - tested but not working on my GPU
(old Intel HD), actually, it never worked on it...
Reported in #435, tcc generates out-of-line definitions for inline
symbols, something it shouldn't. This fix punishes tcc for that
by making applications it compiles (slightly) larger...
RAYMATH_EXTERN_INLINE was renamed to RAYMATH_HEADER_ONLY, which user code
may define if they want to use it as header-only library. If multiple
files in the same project define RAYMATH_HEADER_ONLY, they might each
have duplicate out-of-line definitions of the same functions.
By default, raymath.h exposes inline definitions, which instructs the
compiler _not_ to generate out-of-line definitons, if out-of-line
definitions are required, those of the file defined with
RAYLIB_IMPLEMENTATION are used instead. There may be only one such file.
In C++ mode, the compiler will select only one out-of-line definition
automatically, so no need to define a RAYLIB_IMPLEMENTATION.
Unfortunately, we have to remove raymath function declaration from
raylib.h as those declarations would lead to duplicate out-of-line
definitions which would yield linker errors. This problem didn't
exist with GNU89 or C++, because there multiple defintions are ok,
but in C99 they aren't.
RAYMATH_EXTERN_INLINE was renamed to RAYMATH_HEADER_ONLY, which user code
may define if they want to use it as header-only library. If multiple
files in the same project define RAYMATH_HEADER_ONLY, they might each
have duplicate out-of-line definitions of the same functions.
By default, raymath.h exposes inline definitions, which instructs the
compiler _not_ to generate out-of-line definitons, if out-of-line
definitions are required, those of the file defined with
RAYLIB_IMPLEMENTATION are used instead. There may be only one such file.
In C++ mode, the compiler will select only one out-of-line definition
automatically, so no need to define a RAYLIB_IMPLEMENTATION.
Unfortunately, we have to remove raymath function declaration from
raylib.h as those declarations would lead to duplicate out-of-line
definitions which would yield linker errors. This problem didn't
exist with GNU89 or C++, because there multiple defintions are ok,
but in C99 they aren't.
