Now that we've passed the initial development week, we could consider if there's a better long term alternative to sdl for handling graphics, input and sound. Perhaps there's a more "rusty" option or one that has an API closer to our needs.
Spend some time looking for options, see if any look like an obviously better choice than sdl, and estimate how much of an effort would be to switch to it.
As a general note we likely prefer lower level libraries over opinionated frameworks (especially those that impose a specific pattern/project layout). An option that also covers audio and input would be interesting.
As an experiment, this branch shows the current code using minifb instead of sdl (the raycaster map was not migrated since it relies on sdl's fill rect and draw line routines)
Now that we've passed the initial development week, we could consider if there's a better long term alternative to sdl for handling graphics, input and sound. Perhaps there's a more "rusty" option or one that has an API closer to our needs.
A quick search yielded this: https://arewegameyet.rs/ecosystem/2drendering/ https://arewegameyet.rs/ecosystem/engines/ https://arewegameyet.rs/ecosystem/windowing/ https://wiki.alopex.li/AGuideToRustGraphicsLibraries2019
https://github.com/parasyte/pixels https://github.com/emoon/rust_minifb https://github.com/not-fl3/miniquad https://github.com/not-fl3/macroquad https://github.com/nannou-org/nannou https://github.com/ggez/ggez https://github.com/raysan5/raylib https://github.com/gfx-rs/gfx https://github.com/jrmuizel/raqote
Spend some time looking for options, see if any look like an obviously better choice than sdl, and estimate how much of an effort would be to switch to it.
As a general note we likely prefer lower level libraries over opinionated frameworks (especially those that impose a specific pattern/project layout). An option that also covers audio and input would be interesting.