update raylib to 5.5 - #1
Open
solamint wants to merge 2489 commits into
Open
Conversation
For consistency with the new `DrawTriangleGradient()`
for consistency with `DrawSphere*()`
…rawRectangleLines()` ADDED: `ImageDrawRectangleLinesEx()`
…r `Image*()` functions
…erQuadratic()` Consistent with similar spline functions and avoid confusion with `Quad` related functions.
* Include resource preloads when building wasm examples with Zig. List of resources derived from examples/Makefile.Web * Move resource list to zon file to reduce build.zig bloat
Raylib 6.0 support has been released for C3
Co-authored-by: Huang Zhaobin <xcpky@proton.me>
…bGL 1.0 standard (#5820)
Co-authored-by: zhanlong9890 <lichuang59559890@gmail.com>
…efine (#5804) * Adds a missing macro definition check * Shifts __cplusplus check to a higher level for bool define * Copy same change to rgestures.h and rlgl.h * Fixes float comparison issues in raymath functions * Revert "Fixes float comparison issues in raymath functions" This reverts commit a266d0b.
* [rlsw] Add sw_rcp helper using Xtensa recip0.s for hot-path divisions
Adds a `sw_rcp(x)` inline reciprocal that on Xtensa (ESP32 / ESP32-S3
LX6/LX7) emits a `recip0.s` seed plus two Newton-Raphson refinement
steps -- 1-ULP accurate in ~7 instructions, all in FPU registers.
On every other target it expands to plain `1.0f/x`, so generated code
is byte-identical to before for non-Xtensa builds.
Replaces the hot-path `1.0f/x` calls that were previously compiling to
the `__divsf3` software helper on Xtensa:
- perspective divide (1/w) in triangle clip-and-project (PCT and PC paths)
- line and point clip-and-project NDC conversion
- triangle span setup: dxRcp, blockLenRcp, wRcpA, wRcpB
- triangle scanline setup: h02Rcp, h01Rcp, h12Rcp
- axis-aligned quad: wRcp, hRcp
- line rasterizer: stepRcp
Other `1.0f/x` uses (matrix translate/normalize, texture init `tx`/`ty`,
sw_matrix_rotate inverse-length) are not on the per-pixel hot path and
are left untouched.
Measured on ESP32-S3 @ 240 MHz, R5G6B5 240x240, textured 3D model:
contributes to a ~10-15% rasterization speedup.
Made-with: Cursor
* [rlsw] Use ESP-DSP for 4x4 matrix multiply and per-vertex MVP transform
Adds an opt-in ESP-DSP code path for ESP32 / ESP32-S3 builds. ESP-DSP is
ESP-IDF's official optimized math library and ships hand-vectorized
kernels that beat the scalar implementations on Xtensa.
Two integration points:
1. `sw_matrix_mul_rst` -> `dspm_mult_4x4x4_f32` for any 4x4*4x4 multiply
(used for MVP build, gluLookAt, push/multiply, etc.). rlsw stores
matrices column-major and ESP-DSP reads row-major; the comment on the
call site explains why the flat-buffer call still produces the
correct column-major product (transpose-of-transposes equivalence).
2. `sw_immediate_push_vertex` -> `dspm_mult_4x4x1_f32` for the per-vertex
clip-space transform. Because ESP-DSP expects a row-major matrix in
this case, a row-major copy `matMVP_rm[16]` is maintained alongside
`matMVP` and refreshed once per `isDirtyMVP` rebuild in
`sw_immediate_begin`. Cost is 16 scalar copies per matrix update,
amortized over thousands of vertices per frame.
Detection is **opt-in** via `SW_USE_ESP_DSP` so existing ESP-IDF projects
that don't depend on the `esp-dsp` component keep building unchanged.
A user enables it from CMakeLists.txt (or anywhere before including
rlgl.h):
target_compile_definitions(${COMPONENT_LIB} PRIVATE SW_USE_ESP_DSP=1)
and adds the dependency to `idf_component.yml`:
espressif/esp-dsp: "^1.4.0"
Measured on ESP32-S3 @ 240 MHz, R5G6B5 240x240, textured 3D model:
contributes meaningfully to the overall frame-time improvement
(combined with sw_rcp).
Made-with: Cursor
* [rlsw] Add SW_TEXTURE_REPEAT_POT_FAST opt-in for POT bitmask wrap
Adds an opt-in compile-time flag that replaces the SW_REPEAT wrap chain
with a bitmask (`x & (size-1)`) for power-of-two textures. NPOT textures
keep using the original `sw_fract` / signed-modulo paths via a runtime
`(size & (size-1)) == 0` check, so SW_REPEAT remains correct for them.
Affects two samplers:
- `sw_texture_sample_nearest`: drops the `floorf` + multiply + cast for
POT textures in REPEAT mode (saves a software call on Xtensa).
- `sw_texture_sample_linear`: replaces the `(x % w + w) % w` two-step
modulo (a software divide on Xtensa) with a single bitwise AND for
POT textures in REPEAT mode. Two's-complement int wrap covers
negative coordinates correctly.
Off by default: for POT textures sampled with negative UVs, bitmask wrap
can differ from `sw_fract` wrap by one texel at the boundary. That is
imperceptible at typical resolutions but technically a behavior change,
so existing users get bit-for-bit identical output. Opt in if you
control your asset UVs and want the speedup:
#define SW_TEXTURE_REPEAT_POT_FAST
This addresses the long-standing TODO comment "If the textures are POT,
avoid the division for SW_REPEAT" in `sw_texture_sample_linear`.
Made-with: Cursor
…CS_API_OPENGL_SOFTWARE (#5839) * fix warnings: goto label not used outside of SW_ENABLE_DEPTH_TEST * comment out x coordinates that aren't used in SW_RASTER_TRIANGLE * silence warnings: unused DrmModeConnector functions in rcore_drm.c when using GRAPHICS_API_OPENGL_SOFTWARE
In #5980 a bug was introduced for `DrawRectangleRoundedLines()`. `DrawRectangleRoundedLines()` previously assumed that `DrawRectangleRoundedLinesEx()` uses `RL_LINES` when line thickness is 1 (which is no longer true, it now uses `RL_QUADS` or `RL_TRIANGLES`.) I copy/pasted the previous `DrawRectangleRoundedLinesEx()` implementation and trimmed it down (since now the line thickness is always 1), so now `DrawRectangleRoundedLines()` uses `RL_LINES`. This makes it consistent with all other `Draw*Lines()` functions, which use `RL_LINES`.
* Fix DrawSphereWires (Less aggressively) Summary: - Eliminated some redundancies - Fixed a bug(?) where the sphere would have 1 more "ring" (latitude division) than expected - Fixed a bug where the top ring was double-covered - Added comments denoting which code draws which lines * DrawSphereWires + DrawSphereEx parity Summary: - Replaced DrawSphereWires algorithm with one based on the much faster algorithm from DrawSphereEx - Fixed +1 ring quirk on DrawSphereEx to match the change made to DrawSphereWires
…s Pico 2 (#5994) * pico doesn't implement time.h * add option for RLSW to hold a back buffer, and give it a sw method to swap * Remove unused pointer and give swSwapColorBuffers a default nop-behaviour * Fix compilation by removing old colorBackBuffer setters * use the correct logger * return line * rename RLSW_BACKBUFFER to SW_DOUBLE_BUFFERING
* rlsw config section * use raster flags to define rasterizer variants * simplifies the generation of dispatch tables * single dispatch table for the lines same logic as for the points * internal color interp state * check whether vertex colors should be interpolated * vector op helper macro + pick sampler once before primitive drawing * op order tweaks * refactoring without gotos for triangle and quad rasterizers * same cleaning for the lines
If `innerRadius` is less than 0, it causes the outline to overlap itself and even grow outside of the polygon's bounds when `thick` is greater than `radius`. Clamping `innerRadius` to 0 fixes these problems.
Follow up to #6004. The previous formula would produce inconsistent results for different polygons with the same `thick` parameter.
Fixed nasty bug
Fixed nasty bug, text after insertion is deleted
Add an example to demonstrate/observe DrawPolyLinesEx() behavior.
Previously DrawRectangleLinesEx() would draw lines overlapping each other when they were thick enough (which was only noticeable if the color's alpha was lower than 255.)
NOTE: raylib data validation policy defines not to validate any data that does not suppose a crash in the program, letting user manage that layer... probably several functions should be carefully reviewed or the policy itself...
Added bindings of Raylib 6.0 for openEuphoria
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.