SuperSakura uses data files packed with standard file formats. Game resources are first converted with DECOMP, to turn graphics from the original games into PNG images, .SC5 midi files into standard midi files, .M FM-music files into standard midi files, and bytecode scripts into plain text files. Then RECOMP is used to pack the standard resources into a space-saving binary file. The resulting .DAT is used by SSAKURA to run the game without need for the original files.

---

Many old Japanese games have graphics that clearly originally had more than 16 colors, but to save space and to support the most common video hardware, images were reduced to 16 colors with dithering. The dithering seen most often is a 4x4 pixel ordered dither. It occurred to me back in 2005 that the dithering might be reversible with a bit of effort, to restore the original higher color count.

So I developed a reverse-dithering algorithm, that works on any indexed-color images that use ordered dithering. The algorithm tries to identify lines, then looks for dithering patterns and smooths them out without messing the sharp lines. The algorithm could use more tweaking, and there are always some artifacts that need to be cleaned manually, but overall even now it produces suprisingly nice results.

Additionally, graphics can be improved by using a sharp rescaler. The original games all run in 640x400 resolution, with the actual game view often in a small viewport. Everything can be upscaled by at least 2x for use on modern systems. HQ2x and Scale2x are well-known sharp resizing algorithms, but I need an algorithm that can natively handle fractional multipliers as well, and does not have a restrictive license. Guess I have to write my own.

Of course, the best alternative for graphical enhancement would be to retrace the original images at a higher resolution, and re-color them manually. This would require someone with more artistic skill than I have, and lots of money to pay that person for hundreds of working hours. Crowdfunding might be a solution.

Unlike many engines that are stuck in a pre-determined resolution, SuperSakura can run in arbitrary resolutions. The lazy approach would have been to have an internal buffer in the game's native resolution, and resize redrawn screen areas while blitting them into an output window.

I opted to resize everything to the output resolution upon loading, building a graphics cache in a background thread. Allowing graphics with different aspect ratios to be used at the same time was necessary to accommodate switching between framed and frameless modes. Unfortunately, this causes some visual off by one pixel errors due to fractional anti-aliasing. To avoid this, I added an algorithm that optimises sprites' sub-pixel placement during caching. It's complex enough to be a pain to debug, but at least everything looks nearly perfect, and resizing is only done once per item, saving processing power.

---

I am toying with the idea of including a software FM-synthesiser. Currently the music is converted from .M files into midi, and .SC5 Recomposer midi into standard midi. Having an option for FM sound would be delightfully retro, and I like the sound of good FM. I suppose OGG-rendered high-fidelity versions should also be provided.

---

SuperSakura should work just fine in any Windows from 98 to 7. Why? I like Win98. It is also a lot more efficient than any subsequent Microsoft operating system. As for Win7, well, I guess I have to support it since so many people are using it. The engine has low system requirements; basically, if you are able to run a Windows, you can run SuperSakura. I did a lot of development on a temporary 0.5 GHz system in 2009, and the games were still running as smoothly as I could want.