* Added the ability to draw a model as a point cloud
* Added example to demonstrate drawing a model as a point cloud
* polished the demo a bit
* picture for example
* adhere to conventions for example
* update png to match aspect ratio
* minor changes
* address code convention comments
* added point rendering to makefiles
* added point rendering to readme and renumbered examples
* comment formatting
---------
Co-authored-by: Reese Gallagher <re325479@ucf.edu.com>
Co-authored-by: Ray <raysan5@gmail.com>
Currently, when building, the cmake example in projects/CMake gives this
warning, with CMake 3.30.2
CMake Warning (dev) at /usr/share/cmake/Modules/FetchContent.cmake:1953 (message):
Calling FetchContent_Populate(raylib) is deprecated, call
FetchContent_MakeAvailable(raylib) instead. Policy CMP0169 can be set to
OLD to allow FetchContent_Populate(raylib) to be called directly for now,
but the ability to call it with declared details will be removed completely
in a future version.
Call Stack (most recent call first):
CMakeLists.txt:20 (FetchContent_Populate)
This warning is for project developers. Use -Wno-dev to suppress it.
Changing FetchContent_Populate to FetchContent_MakeAvailable didn't
cause any issues I could observe when building. I'm not sure why it
wasn't like that to begin with.
This file seems to not do anything useful. From what I can tell the
OSX_FATLIB option sets CMAKE_OSX_ARCHITECTURES to "x86_64;i386". This
doesn't account for the arm that apple now has, as well as 32 bit
support being completely removed, and I think it's entirely reasonable
to expect users to pass the necessary architectures they want
themselves. It's possible this could break some users who rely on this,
but I sincerely doubt anyone does. The solution is trivial either way
(put -DCMAKE_OSX_ARCHITECTURES="i386;x86_64" on the command line
yourself)
The second part of BuildOptions.cmake claims to set PLATFORM to "Web" if
the emscripten toolchain file is used (if (EMSCRIPTEN)), but it does not
work correctly anyway. Currently, glfw searches for wayland and x11
libraries and fails likeso:
CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:645 (message):
The following required packages were not found:
- wayland-client>=0.2.7
- wayland-cursor>=0.2.7
- wayland-egl>=0.2.7
- xkbcommon>=0.5.0
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPkgConfig.cmake:873 (_pkg_check_modules_internal)
src/external/glfw/src/CMakeLists.txt:163 (pkg_check_modules)
Considering this code doesn't work as described, it's okay to delete it.
I think a better check should be implemented, but that is for a
different PR.
* Update raylib_api.* by CI
* Add a temp warning about material assignments during OBJ loading if the file has more than one material. To be replaced when the OBJ translation code is fixed.
---------
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
void DrawCircleGradient(int centerX, int centerY, float radius, Color color1, Color color2);
void DrawRectangleGradientV(int posX, int posY, int width, int height, Color color1, Color color2);
void DrawRectangleGradientH(int posX, int posY, int width, int height, Color color1, Color color2);
void DrawRectangleGradientEx(Rectangle rec, Color col1, Color col2, Color col3, Color col4);
Have been changed to:
void DrawCircleGradient(int centerX, int centerY, float radius, Color inner, Color outer);
void DrawRectangleGradientV(int posX, int posY, int width, int height, Color top, Color bottom);
void DrawRectangleGradientH(int posX, int posY, int width, int height, Color left, Color right);
void DrawRectangleGradientEx(Rectangle rec, Color topLeft, Color bottomLeft, Color topRight, Color bottomRight);
* Create raymarching.fs
* Update raymarching.fs
* Update raymarching.fs
* Update raymarching.fs
Remove `fragColor` as it is unused
Move the license to the top of the code to improve readability.
* [build.zig] Overridable definitions from config.h
The new Options field "config" holds a string the user can set in the
format "-Dflag_a=1 -Dflag_b=0 ..." to override the values set in
`config.h`.
The file is parsed and the default values are appended to the
compilation flags, if the user doesn't override them.
The user string is appended to the compilation flags.
The "-DEXTERNAL_CONFIG_FLAGS" is added to prevent "config.h" inclusion.
Note: a certain format is assumed for the formatting of config.h
Note: this commit references the closed issue #3516
* [build.zig] Only SUPPORT_* definitions are overridable
Lines from `config.h` which contains "SUPPORT" are added to compilation after being parsed:
- remove whitespace
- format to preprocessor option https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
The user supplied flags have priority over the ones read from the file.
NOTE: extension to commit 4da7f82e6f, the logic is simplified
because the SUPPORT flags only have binary values, which makes them easier to parse.
* GLFW AUTO_ICONIFY flag is now set to false per default.
Previously AUTO_ICONIFY was only disabled if the user requested a Fullscreen window from the start. After that it was not possible to change this behavior on the user side anymore, even when changing to a Fullscreen window.
The AUTO_ICONIFY causes problems on macOS. On macOS if the window is minimized because of AUTO_ICONIFY than the only way to restore it is to click on the icon in the dock. In other words when AUTO_ICONIFY is enabled alt/cmd-tabbing through windows does not work correctly. On windows it works even when AUTO_ICONIFY is enabled.
Additionally if a raylib window is in Fullscreen mode on another monitor the AUTO_ICONIFY behavior is a problem because the user might want to window to stay on the monitor even if it loses focus. (problem on all OS's)
AUTO_ICONIFY also restores the monitor hardware resolution if a fullscreen window loses focus.
* Update rcore_desktop_glfw.c
Extra space removed and comments updated with a space at the beginning
* [rcore] fix gamepad axis movement and its automation event recording
This commit fixes 2 issues:
- Automation events aren't recorded for negative axis movements on
gamepads (e.g. stick going left/up)
- 'GetGamepadAxisMovement' drift check isn't working correctly for
triggers. Axis values between [-0.1, 0.1] are clamped to 0.0
Behaviour change:
- 'GetGamepadAxisMovement' returns default value for each axis, even
if gamepad isn't attached.
* [rcore] inline body of 'GetGamepadAxisMovementDefault' and remove it
