* allow for multiple materials in obj files also fix obj_loader hash map issues

* minor fix for warning

Co-authored-by: codifies <nospam@antispam.com>

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?

Raylib-forever: 3.1-dev
It generates the c-to-nim bindings straight from the source.

nim-raylib: 3.1-dev
It uses Raylib-forever.

raylib-php: 3.0
Tested it using the provided binaries.

raylib-java: 2.0
Tested it using the provided binaries.

Texture type also maps to Texture2D and TextureCubemap

* rlDrawMeshInstanced first attempt

* rlDrawMeshInstanced OpenGL 3.3 and VAO checks

* rlDrawMeshInstanced GetShaderAttribLocation; comments

* example instanced shader

* RLGL_STANDALONE RAYMATH_STANDALONE Vector4

* apply suggested naming changes; add instanced mesh example

* remove orphan variables

* updated README.md

* fixed CMakeLists.txt to allow building and debugging with Visual Studio Code and CMAKE Tools extension

* added PLATFORM_DRM
contains mouse pointer code from https://github.com/chriscamacho

* removed redundant cleanup in InitGraphicsDevice

* fixed DRM connector mode selection

* added choosen DRM connected mode to log output

* added respecting TargetFPS on DRM mode selection, default to 60

* added support for GetMonitorRefreshRate

* changed SUPPORT_MOUSE_CURSOR_RPI to SUPPORT_MOUSE_CURSOR_NATIVE

* changed avoidProgressive to allowInterlaced

* cleanup, function extraction and improved mode selection

* README reverted to original for PR

* line endings fixed for core.c

* removed old code

* mouse pointer reverted to small square

* replaced SetGraphicDeviceName() by DEFAULT_GRAPHIC_DEVICE_DRM

Co-authored-by: kernelkinetic <kernelkinetic@outlook.com>

- DrawCube() belongs to models.c -> rl*() alternative should be used

Function has been reviewed to avoid any direct OpenGL call and use rlgl functionality, also, GenDrawCube() has been replaced by the internal batch system with DrawCube().

WARNING: rlEnableTexture() call must be issued after enabling the current framebuffer when using batch mechanism because it includes a set of security checks to avoid batch overflow and push/pop matrix operations.

Fixes #1380: incorrect usage of CMake paths which causes issues
on some more complicated environments (NixOS especially).

It does not work properly yet but it compiles correctly

Added some tracelog messages

The repository is not a mirror anymore.

Now supports dynamic panoramic view, just drag and drop

This is the recommended way

Functions have been redesigned to use rlgl and allow to externalize them (aka removing them from rlgl because they use custom shaders...).

Related to commit https://github.com/tazdij/raylib-pas/pull/15

Required to attach multiple color textures and multiple cubemap faces

* fixed wrong error message for input device

* error message without errnofor input device on RPI
 to prevent from including additional header

Co-authored-by: kkl <klingenberger@bfmc.de>

This redesign allows more flexibility when creating RenderTexture and a simplification (and hopefully removal) of `GenTexture*()` functions, that should not belong to this model but the user code, due to the use of custom shaders.

Also, this new API opens the door for a possible GBuffers type and advance rendering possibilities...

Some functions of the API have been also simplified or even removed.

rlgl module can be used as an standalone library, so, a version for the library has been added: v3.1.0, matching current raylib version.

Not required anymore, attachment type is queried when required

Avoid unloading default shader, raylib will take care of it

Before deleting certain objects, they must be detached from their parents. That's the case for shader objects after linkage to shader program and also for the texture/cubemaps/renderbuffers attached to framebuffers. If objects are deleted before detached, they are kept in memory to avoid accessing deleted data.

Better organized and commented

Also updated raylib Wiki about struct sizes in 32bit and 64bit