I mean, one could try it in C and see how it goes. Given how common slowdown was even among games programmed in assembly, and given how suboptimal C code tends to be on 65xx processors, I wouldn't expect a flawless result. But I could be wrong...
A working C version could be profiled, and the slow parts rewritten in assembly. To a 6502 programmer, 65C816 is a big improvement; the only real disadvantage is that you have to keep track of the sizes of the accumulator and the index registers (cc65 avoids this issue by doing everything in 8-bit mode).
PypeBros wrote:An interesting problem, but I don't know if I'll end up with a running game or just excessively techy tools if I follow that path.
That seems to be a risk with any kind of SNES development. It's friendlier than NES programming, but it's more complicated because you can do so much more with the console, and it's not nearly as friendly as a modern C++ framework. It's not something you can just turn to and dash off a quick side project in a few weeks; you have to be serious about getting something done.
PypeBros wrote:The non-square pixels is likely the most annoying part.
Perhaps. This one's a bit unusual, because with Mega Drive or arcade ports, they're already 224-line games and ideally would only need horizontal rescaling, but this is a 256-wide game that only needs to be scaled vertically. This means that it may be easier to rejigger the level maps, because horizontal widths and distances don't change.
Or you could just leave it the way it is:
Original:
NTSC:
PAL:
(Please excuse the colour/gamma; the processing was kinda ad hoc...)
...
Regarding music, the SNES (as you may have noted) is limited to 8 channels including sound effects. They're all sample channels (or optionally noise), so you can use chord samples to boost the apparent polyphony. But there's only 64 KB of RAM for BRR samples, audio engine code, and the echo buffer, so if you're using a lot of sophisticated instruments you're going to bump your head. This memory limit shaped the sound of the SNES at least as much as did the capabilities of the DSP, and it didn't help that most developers were in too much of a hurry to spend much effort exploring the limits of optimization.
Real-time sample streaming is possible, as proved by Tales of Phantasia and Star Ocean, and there are a couple of homebrew audio engines that support it. But for various reasons they're more bandwidth-limited than I personally believe they could be (though I'm too busy to prove it), and last I checked you could only stream muffled mono. Good enough for sample replacement during playback and for some types of sound effects, but without more development you aren't going to be streaming 32 kHz stereo, not that a SNES cartridge could hold much music at that bitrate anyway...
The MSU1 is a possible way around this (up to 4 GB of Red Book audio with loops), but it loses authenticity somewhat as it is not period hardware, and not every emulator supports it. The Nintendo Play Station could potentially be used for CD audio, but it was never released and there's only one known extant hardware unit, with the result that it is not especially well understood or widely emulated. The Voicer-Kun is another period-accurate possibility, but in addition to the extra hardware (which was only released in Japan), it requires the use of a CD player with infrared remote control functionality, which may be overkill when you could just put up with somewhat cut-down music instead...