libretro tracking issue

[yupferris]

• Support all output pixel formats
  • Currently we request the frontend use XRGB8888 format, but sometimes retroarch doesn't listen to this call (something we should actually look into and try to debug, as the libretro folks have said this is pretty weird), and other frontends may not support this format at all, so we need to support all possible formats.
• Revisit controller/input impl to see if we actually need to map analog sticks like we do
  • It looks like libretro provides a couple different retropad options, one of which may do automatic analog stick -> dpad button conversion, which I would much rather rely on than doing it in the core.
• Support multiple stereo output options
  • Currently we only do mixed red/electric cyan output, but we should support additional types as well. bparker in the libretro community had some nice ideas/insight here from professional experience.
• Use buffered audio output instead of callback-per-sample
  • This is just an optimization, but something we're pretty well equipped to take care of actually.
• Reduce allocations/copies in the AV output chain
  • Right now we have a somewhat elegant sink system for converting/filtering output from the emulator. However, since the emulator's output is fairly regular, we can rather provide storage and expected packing info as input instead of a sink and have the emu itself output in specific formats. This is less elegant but should be much faster, and I'm fairly certain we can still make this pretty safe with Rust. Especially for pixel output, this is likely a major performance bottleneck in both frontends currently.
• Profile/benchmark perf in both libretro and cl frontends
• SRAM
• Consider exposing other types of RAM as well
  • The libretro API supports querying several types of memory, not just SRAM. This would allow a frontend to inspect system RAM, video RAM, etc.
• Serialization/deserialization
  • We need to be a bit careful here, since internal structures may change between versions. Specifically, an accuracy improvement/fix may introduce or remove an internal register, which we want to be a part of the serialized state ideally, but may not align with a previously-saved state. I'm not sure what the best approach here is yet, but I'm sure we can come up with something decent.
• Make sure rustual-boy-libretro's Cargo.toml info is up-to-date and matching the rest of the repo
• Get libretro core builds in CI/distribution pipeline
  • This includes distributing licensing docs, which differ from the CL license info as it uses a lot less IP.
  • We should also think through/document our manual release procedure (currently it's basically just pushing with a specific tag but I want to document that, and it may get a bit more complicated with version bumps etc as we progress).
• When libretro core is more mature, speak with libretro folks about making rustual boy a primary retroarch core
  • I'm not sure what this entails, but I know at least we'll need to provide and maintain documentation, hook up builds in their pipeline, investigate cross compilation for multiple [esoteric] targets, etc.