Enhanced Nemesis 3 test version

TBH I haven't considered smooth scrolling for SD snatcher yet. I'm sure it's possible and maybe it'll be worth it to give it a try, but it'll be a lot more difficult than the Gradius-style games (and Knightmare, where I also implemented smooth scrolling).
Don't get your hopes up for Contra though. The MSX port is just not designed to scroll at all and no emulator trickery is going to help there.

That said, both already support enhanced music, fwiw.

If your emulator is based on fMSX, it should not be too difficult to add the MSX2+ support.

TurboR support is another story, as fMSX does not have this support.

@ericd By the way I wonder, as an emulator is a very realtime system; the Hotspot JVM’s garbage collector is pretty good, concurrent, generational etc. Did you need to make any special considerations to reduce garbage collection churn, such as object pooling? Or is the modern garbage collector good enough so that you don’t have to worry about it at all?

I made a pure-Java 3D test project on Dalvik (the old Android VM) and the results were disappointing, a lot of jitter due to pauses of sometimes in the tens of milliseconds. I need to try it again on the new ART runtime, its GC is supposed to have been improved a lot. I’ve never tried to do such a thing on Hotspot.

@Grauw
I don't do object pooling or some such. There are times where you don't want to depend too much on GC if you want to be real-time, but those considerations aren't all that different from writing in C (just don't allocate/de-allocate too much).
But by and large, the GC in JVMs perform surprisingly well and even if you do stress the GC a bit, it's hardly ever a problem.

Dalvik is another story though. First of all, Dalvik isn't really Java. The language is the same and parts of the API are the same, but the virtual machine and byte-code are entirely different.
Frankly, Dalvik kind of sucks. It's like going back at least 10 years back in time compared to desktop JVMs. In Dalvik, you do have to worry about GC a lot more if you care about consistent real-time performance.

Well it's good to hear Google are moving away from Dalvik. To be honest I haven't heard about ART before. Hopefully that'll be a good improvement.

A few years ago I modified my emulator to run on Android, but the results were disappointing in terms of pure runtime performance.
I managed to get the Donkey Kong arcade running at (sort of) real-time speed by seriously down-clocking the CPU, but with even MSX I had no chance (think ~5fps on a 1GHz phone). GC wasn't the problem (there's hardly any garbage generated in my emulator anyway).
To compare, the MSX driver of my emulator even worked alright on an old 266MHz Pentium II laptop running the IBM Java 1.3 JVM or HotSpot 1.4.
(My emulator also supports Sega Y-Board arcades but I didn't even bother trying those on Android; I expect less than a slide-show there)

A good JVM can manage close to C++ speed (and in some cases even surpass it), but Dalvik isn't that.
My understanding is that Dalvik only has a very simple JIT compiler that doesn't do all the fancy optimisation stuff that the likes of HotSpot or IBM do. It's not just GC (which you can work around if you have to); it's just bad performance across the board.

Dalvik isn't completely useless though. For the typical 'app' it's usually good enough. The remote debugging facilities and such are nice. You can even code simple 3D GLES games at good framerates if you put the effort in. But more CPU intensive stuff like emulation is obviously not it's strong suit.