Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: 4.5.0 + various redesign #149

Draft
wants to merge 32 commits into
base: master
Choose a base branch
from

Conversation

TSnake41
Copy link

@TSnake41 TSnake41 commented Jan 28, 2023

Built on top of https://github.com/deltaphc/raylib-rs/tree/4.2.0

Along with 4.5.0 support (albeit without its added features), this branches features this :

  • add make_bound_thin_wrapper! to create raylib objects that has a shorter lifetime than RaylibHandle, port relevant types to this, including appropriate lifetime parameters
    • it forbids using a raylib object (e.g font) after RaylibHandle is dropped
  • try to make update_audio_stream a bit safer
  • use RaylibBuffer<T> instead of "rslices"
  • redesign get_dropped_files with iterators
  • make compress_data/decompress_data less leaky using RaylibBuffer<T>
  • fix get_window_state
  • add a experimental closure-based RaylibRenderLoop to manage RaylibDrawHandle
    • may be better for web support, but a bit more complex, it was the only thing that worked for me with lifetime changes
    • did some other changes to avoid mutable borrows that drove me crazy without sacrificing safety

and probably some other things

Samples still need to be updated.

Rover656 and others added 20 commits January 25, 2022 23:10
- Added get_mouse_delta
- Added get_touch_point_id
- Made get_random_value stateful and added set_random_seed
- Works no matter if the game uses -s ASYNCIFY on web or not
- Fixed broken examples
- Fixed build on all samples

TODO: Look at compressions and now encoding
While (im)mutable handles are fundamentally not a bad idea, the Rust semantics of mutable borrow mecanism doesn't really match what we are trying to do and can cause some weird errors. It is actually best to make things a lot simpler while losing a bit on guaranties on raylib state.
Additionally, replace the rather confusing "renderloop" with a simple frame callback mecanism.
Add support for some unimplemented raylib 4.5.0.
Replace impl Into<ffi::VectorN> with mint vectors.
Remove some wrappers, move their implementation into raylib-sys's structures.
Cleanup various parts.
Improve raylib-sys, may be able to use other raylib librairies.
Actually makes things simpler, and avoids invalid nested begin*mode.
Copy link
Collaborator

@Dacode45 Dacode45 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small Changes

raylib/src/core/mod.rs Outdated Show resolved Hide resolved
raylib-sys/src/camera.rs Outdated Show resolved Hide resolved
raylib-test/Cargo.toml Outdated Show resolved Hide resolved
raylib-test/Cargo.toml Outdated Show resolved Hide resolved
raylib/src/prelude.rs Show resolved Hide resolved
@Rucadi
Copy link

Rucadi commented Apr 14, 2023

How is the status of this?
Is it usable right now?

I would love to have this merged and usable.

@TSnake41
Copy link
Author

How is the status of this? Is it usable right now?

I would love to have this merged and usable.

It is somewhat usable (not thoroughly tested).
You can check https://github.com/tsnake41/raylib-rs-games for some examples.

…er things.

Raygui wasn't really safe, as it relied on "use after free" to be fine, this review made it less reliant on this undefined behavior.
@MatejMagat305
Copy link

it is outdated, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants