Open ebkalderon opened 1 year ago
There is a work-in-progress branch named improve-api-ergonomics
which contains a significant rewrite of this library. It includes, among other things:
Version
s which uses Minimum<V>
and Below<V>
trait bounds to conditionally enable and disable methods RenderDoc<V>
.
std::ops::{Deref, DerefMut}
and sound (but scary) transmutation.shutdown
-> remove_hooks
) are expressible, fixing #93.Debug
output for RenderDoc<V>
and other versioned types.InputButton
s into set_{focus_toggle,capture}_keys()
.VersionCode
enum, no more HasPrevious
trait).
AsInputButtons
remains public so users checking the rustdoc
output can see a list of types that implement it.More ergonomics improvements to come.
This library does some pretty sketchy things internally (abuse of the
Deref
andDerefMut
traits plus some weird, but sound, uses ofstd::mem::transmute()
to simulate inheritance, etc), and its user ergonomics aren't the best either. I've learned quite a lot since I first started this project, and I would like to completely redo this library to make better use of the type system and be more user-friendly.For one, it is possible to fully reimplement this style of API using 100% safe and idiomatic code (Playground link), while also fixing #93. Other aspects of this library could use a lick of paint; for example, the
CaptureOptions
interface of the raw RenderDoc API could be abstracted over with a type safe interface, and the frame capture methods could be made more idiomatic too (consider providing aDrop
guard for starting and ending a frame capture, for instance).Finally, the
RenderDoc<V>
struct could offer a default generic type parameter which defaults to the newest supported API version to make things easier for users who don't really care about selecting a specific API version themselves.The whole type-safe runtime downgrading API with
.into()
is honestly an unnecessary gimmick and should be removed. But perhaps offering a fallible API for users to upgrade theirRenderDoc<V>
instance to a newer version, if they so choose, would be more useful (one would select a minimum supported version first, and if so desired, test at runtime whether RenderDoc handed over a newer version and then switch to that).