The other PR has more info, but the overall gist here is:
SlippiUser has a mostly-kept API to reduce churn, but gets a copy of the Rust EXI device pointer and its API just ferries in and out of the Rust layer. This is safe enough since we don't allow the user to outlive the EXI device.
Minor modifications to matchmaking and EXI device files where chat messages were being loaded for a user, just for pulling them across the FFI boundary.
slprs_exi_device_create now uses a config struct to make what we're passing over the boundary a little more clear.
I've played on this branch for a few days now with no issues, but I of course invite any testing since there's definitely things I could've missed.
This should port relatively cleanly to the mainline branch, all things considered.
This PR goes hand-in-hand with project-slippi/slippi-rust-extensions#5: Initial scaffolding for porting User model .
The other PR has more info, but the overall gist here is:
SlippiUserhas a mostly-kept API to reduce churn, but gets a copy of the Rust EXI device pointer and its API just ferries in and out of the Rust layer. This is safe enough since we don't allow the user to outlive the EXI device.slprs_exi_device_createnow uses a config struct to make what we're passing over the boundary a little more clear.I've played on this branch for a few days now with no issues, but I of course invite any testing since there's definitely things I could've missed.
This should port relatively cleanly to the mainline branch, all things considered.