This week was a bit of a jarring week at work, so not too much big stuff this week on personal projects, just a lot of small things.

Mainly I've been doing a bunch of small website/repo readme tweaks, and helping the guys doing libretro integration for rustual boy. One thing in particular that was done was to split up the rustual boy crate into 3 crates:

• rustual-boy-core: Covers core emulation and basic traits to implement to get data out.
• rustual-boy-cli: Our minimalistic frontend with basic debugger.
• rustual-boy-middleware: Some useful things for implementing frontends.

This separation makes it easy to support both our own rustual-boy-cli package, as well as the libretro frontend. We also did some work implementing a nice Sink pattern for pumping out audio/pixels from the emu, allowing it to produce data whenever it's convenient rather than having the core store extra output buffers, and making the bootstrapping poll for such data. We also separated certain pixel conversions, such as transforming the stereo images into one anaglyph image and rgb -> srgb conversions, into their own sinks which just transform the data and dump a new buffer into another sink. Thus, by chaining sinks, we can chain together a pixel conversion pipeline (or audio conversion pipeline!) that's convenient for the top-level emulator code, and then pass the whole thing to the emulator, which can still just dump its simple data into.

While this pattern is elegant, I think it may have introduced a bit of a perf penalty, since it has to create a few extra buffers than it did before. I've thought about this a bit since implementing the pattern, and I think a simple way to fix this is just going to be to have the boostrapping still implement a sink to accept output from the emu, but instead of chaining sinks for data conversion, chain a bunch of per-pixel (or per-audio-frame) iterators together to make the sink, which are consumed however the top-level code sees fit. This would eliminate bounds checks and allow the rust compiler to (hopefully) collapse all of the iterator implementations into a single loop that does all the conversions in one go, while still allowing us to provide pre-made code and types for these conversions to make them as convenient as possible.

While I think this would do the trick, I hope to hold off on implementing it until the libretro integration is more complete and hopefully moved to the main repo, so we can fix it everywhere at once and get some more performance data to see if it's even a bottleneck.

I also did some braindumping about Rustual Boy 1.0, which is some kind of milestone I made up in my head for some reason. The goal is to lay out some more concrete goals for the release in this github issue to make them more clear and trackable (and to store them somewhere less volatile than my head). You can also see there that I did some more investigation into the bugs in Vertical Force and Space Squash; unfortunately, they still have yet to yield some concrete results, so that's annoying :P

Until next time!

Last Edited on Sun Feb 12 2017 09:42:19 GMT-0500 (EST)