SuperSakura consists of four components, in processing order:

Custom content

The most obvious custom content you'll see are the new textboxes, title screens and, in some games, map-based movement instead of multiple-choice.

I'm keen on including modding support, not least because that would be the smoothest way to create fixpacks for the original games. A fixpack mod could fix scripting bugs, enable previously unaccessible code, correct translation issues, and maybe throw in some improved visual effects. You could even create a mod with new characters and storylines, or write a whole new game.


Since there are so many games I want to play in English, it's important to have a scripting language that keeps the text strings in a separate chunk that can be easily dumped into a spreadsheet. I'm currently moving toward that. I could probably add an automated method for using machine translation to create a quick and very dirty translation of every string, that could then be polished by a halfway competent localisation person.

I think the translated strings can then be packed into a mod, along with any graphics that needed new text drawn on them. If you want to switch languages while playing, say, to compare the original Japanese to see exactly how bad the English text is, you can. Maybe even display text from both languages at the same time.


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. It's simple enough to drop the viewframe and expand the actual game graphics to full screen. Everything can be upscaled by at least 2x for use on modern systems. For best results, drawn art needs to be resized using a sharp pixel scaling algorithm. HQ2x, Scale2x and most recently xBR are probably the best-known, but I need an algorithm that can natively handle fractional size multipliers as well, and does not have a restrictive license. Guess I'll 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. Crowdsourcing might be a solution.

I always found it strange that game engines are limited in their output resolutions. So I designed my engine to be able to run in any arbitrary resolution, from dinky 512x256 tablets to 1280x1024 desktops, or even 3840x2160 4K displays. Why not go all the way, right?

It turns out there are a lot of problems in making a 2D game engine that can run in any resolution. If you only target one or two most important resolutions and optimise everything for those, the implementation is fairly simple. A compromise approach would have been to use an internal buffer, and render the game in its native resolution, then resize everything only once when copying the picture to be displayed to the user. That wasn't good enough for me.

Instead, I opted to resize every graphic when it is loaded to the output resolution, building a graphics cache in a background thread. To further complicate things, it is sometimes necessary to display graphics designed for different aspect ratios, for example when toggling the viewframe on and off. The biggest problem all this caused were some visual off-by-one-pixel errors due to fractional anti-aliasing. Aligning image elements pixel-perfectly is child's play if you're operating in a single fixed resolution or an integer multiple of it. Otherwise, rounding errors accumulate and cause misplaced sprites or animations to have distracting seams around them. To avoid this, I had to develop an algorithm that optimises sprites' sub-pixel placement during caching. It's complex enough to be a pain to debug, but it does make everything look perfect no matter what resolution you're playing in. That is, until my latest asset loader redesign. Maintaining the sub-pixel optimisation would have required too ugly hacks, so I dropped it, and decided to transition to SDL2/OpenGL rendering sooner. I'm sure I'll yet regret this decision.


I am toying with the idea of including a software synthesiser. Currently the music is converted from .M files into midi, and .SC5 Recomposer midi into standard midi. Having an option for PC-98 style FM and pulse wave sounds, probably with added drum samples, would be delightfully retro. I suppose OGG-rendered high-fidelity versions should also be provided.

Operating systems

The engine has very low system requirements. I did a lot of development on a temporary 0.5 GHz system in 2009, and the games were still running as smoothly as ever. The engine now uses SDL2, and runs on Linux and Windows. The biggest obstacle to an Android port is the limited support in FPC, though the engine is otherwise flexible enough to transition smoothly to a touch interface.