Examining the code shows that the rectangle is drawn winding counterclockwise, starting
with the top left. Therefore the colors used should be in the order: topLeft, bottomLeft,
bottomRight, topRight.
However, the variables actually being used are topLeft, bottomLeft, topRight,
bottomRight. I was confused by this as I was getting striping where I didn't expect any.
Put another way, the last two parameters are misnamed.
This diff swaps the parameter names and their usages. The result is that no runtime
behaviour changes: the same parameter order yields the same visual result both before and
after this change, but the parameter names now correctly reflect what they are actually
used for.
You can actually see this in the implementation of DrawRectangleGradientV, which
(correctly) passes top, bottom, bottom, top to DrawRectangleGradientEx.
I believe it makes sense to only do this when there are no known
touch points. I am not even sure if this should be done at all.
See https://github.com/raysan5/raylib/issues/4872 for more information.
Restore window currently says it sets the window state to:
"not minimized/maximized"
However, if a window is maximized and then minimized, it's typical that
it would restore back to being maximized, which is what seems to happen
from my testing. I've reworded the description to better reflect
this behavior.
raylib app crashing when started and a gamepad is already connected to the PC (even if the gamepad is not used in the app). I only tested this with a gamepad that has a layout which is not recognized. Using SDL3 as backend.
InitWindow() prints CWD during initialization,
but ChangeDirectory() does not, which is quite confusing when you start
messing with CWD. Now said function should log similar message.
Prevents unnecessary work and division by zero (when segments=0) in DrawCircleSector/DrawCircleSectorLines when startAngle equals endAngle, matching existing behavior in DrawRing/DrawRingLines.
This may not be the correct approach, however this appears to work. The idea is that before modifying `CORE.Window.flags` when first creating the window we keep a copy of the flags in order to call `SetWindowState` after initialization has completed, which should behave as if `MaximizeWindow` or `MinimizeWindow`, or conceptually any other flag modifying function were called after `InitWindow`.
This pull request only performs this for the windows platform, modify as needed in the switch statement at the end for others.
Undefine DEBUG to avoid external redefinition
warnings/conflicts. This is probably a common
definition for many external build systems'
debug configurations.
This ensures raylib will not emit
a warning about the DEBUG definition being
redefined in external build systems.
* [rcore] fix crash in InitWindow, due to unchecked result of InitPlatform
Check the result of InitPlatform(), if it isn't 0, report the Error
and return. This prevent crashes and allows for gracefully aborting
or recovering by checking IsWindowReady().
Partially-fixes: https://github.com/raysan5/raylib/issues/4801
* [rcore] style: store the result of InitPlatform() before checking it
Small style change that doesn't impact how the code behaves here.
Variable 'result' is not used anywhere else in this block,
it's just for compliance with Raylib's coding conventions.
Requested in PR: https://github.com/raysan5/raylib/pull/4803#discussion_r1976502788
* [rcore] use LOG_WARNING when InitPlatform() fails
...as this is preferred over LOG_ERROR.
Requested-by: https://github.com/raysan5/raylib/pull/4803#discussion_r1976651724
In the case of a failure within miniaudio on the function: ma_convert_frames, the dynamic memory allocated for the `data` variable will leak on the early return.
Raylib allows for providing custom allocators via macros.
GLFW supports this too, but via function pointers.
Make sure that GLFW uses those Raylib macros, by wrapping them in
function calls and setting them up inside of InitPlatform().
This is possible because of glfwInitAllocator() and GLFWallocator.
Fixes: https://github.com/raysan5/raylib/issues/4776
Relates-to: https://github.com/raysan5/raylib/issues/4751
I was really wondering what is going on here :D I believe this code
tried initially to out-cast 'const' specifier but this is not needed here
at all. Currently, it just confuses whoever reads this so I changed it.
The old code would also trigger -Wcast-qual warning on some compilers.
Currently, a warning about _GNU_SOURCE being redefined is emitted when
compiling rglfw.c
In file included from rglfw.c:99:
external/glfw/src/posix_poll.c:27:9: warning: "_GNU_SOURCE" redefined
27 | #define _GNU_SOURCE
| ^~~~~~~~~~~
<command-line>: note: this is the location of the previous definition
This can be avoided by not defining _GNU_SOURCE on the command line for
this file.
Defining feature test macros in source code is not really good practice
so this should probably reviewed in glfw itself, at least to maybe check
#ifdef _GNU_SOURCE first. But for now this change will suffice.
Fixes#4725
When asking Makefile to create SHARED library for WEB
$ make TARGET_PLATFORM=PLATFORM_WEB RAYLIB_LIBTYPE=SHARED
it would instead silently create STATIC library
thus not fulfilling the request as expected
This commit adds an error in this case and stops further execution.
This is not consistent with Cmake, because Cmake throws the warning and
does not stop, but Cmake can easily recover from this case and people
probably does not even notice it. However, Makefile is something that
you have to handle yourself and you have to recover from any issues so
having an error and aborting with exit code 1 is more expected.
Otherwise people may spend a lot of time debugging Makefile in order to
understand what's even going on.
Fixes: https://github.com/raysan5/raylib/issues/4717
define STBIR_NO_SIMD when __TINYC__ is defined so stb_image_resize2 will
not include *mmintrin which are not supported by all compilers.
There are similar checks for __TINYC__ already elswere in raylib
and they are also mostly there to disable SIMD headers.
Additionally, move similar check for stb_image, to be a little bit
deeper. Before it was defining STBI_NO_SIMD without including stb_image
It was also clashing with note, causing said note to make no sense.
Fixes: https://github.com/raysan5/raylib/discussions/2994
Reference: https://github.com/nothings/stb/issues/1738
This change is replacing the hardcoded "#canvas" element references in
rcore_web to allow using canvas elements that use different names
(which is necessary when using multiple canvas elements on one page).
Also adding a cursor hiding example to mouse example.
Lately got some compilation `errors` related, it seems GCC 14 interprets some `const`-missmatch as errors instead of warnings (as previous versions).
But in any case, I don't see why an user won't be able to operate directly over of those returned buffers; `const` adds a restriction (for security reasons?) that in my opinion is useless.
From an expert on compilers (w64devkit creator), here there are some notes I agree with:
```
No const. It serves no practical role in optimization, and I cannot recall an instance where it caught, or would have caught, a mistake. I held out for awhile as prototype documentation, but on reflection I found that good parameter names were sufficient. Dropping const has made me noticeably more productive by reducing cognitive load and eliminating visual clutter. I now believe its inclusion in C was a costly mistake.
(One small exception: I still like it as a hint to place static tables in read-only memory closer to the code. I’ll cast away the const if needed. This is only of minor importance.)
```
Ref: https://nullprogram.com/blog/2023/10/08/
This optimization works in the following ways:
1. Reduces calls to malloc to 1. Instead of needing an extra array, we
can just swap the top half with the bottom half of the one array.
2. Unroll the inner for loop and remove a condition. Unrolling loops
buys some performance wins, but the real goal was to remove the if check
and just set the alpha channel to 255.
On my hidpi arm64 laptop, I saw ~60% improvement in performance in my
debug build (29 FPS vs 47 FPS). When optimized, the gains were roughly
10% (75 FPS vs 83%).
Signed-off-by: K. Adam Christensen <pope@shifteleven.com>
* Add implementation for CORE.Window.eventWaiting on PLATFORM_DESKTOP_SDL
* Optimize GetFrameTime() reset
* Optimize FLAG_WINDOW_ALWAYS_RUN and GetFrameTime() reset for PLATFORM_DESKTOP_GLFW
* Enable FLAG_WINDOW_ALWAYS_RUN by default on PLATFORM_DESKTOP_GLFW
* Revert enabling FLAG_WINDOW_ALWAYS_RUN by default on PLATFORM_DESKTOP_GLFW
* Add implementation for FLAG_WINDOW_ALWAYS_RUN on PLATFORM_DESKTOP_SDL
* Add reset for GetFrameTime()
* Update rmodels.c
resolves segfault with missing bone weights or bone IDs
* Update rmodels.c segfault with animation and missing normals/animnormals
* correct place.
- Updating bones only once instead for each mesh.
- Updating only one `model.meshes[].boneMatrices` and then using deep copy for other meshes instead of calculating for each bone in each mesh.
**Other points:**
- Makes it a clean base/template/reference for bone updation functions. Because if using this as template then some calculations done in one mesh can affect bones in other mesh in next iteration(doubles the effect in for next mesh).
Signed-off-by: Kirandeep-Singh-Khehra <kirandeepsinghkhehra@gmail.com>
