I have not looked much into music hacking, except for this FF6 document I was reading a while ago but what I want is probably different.
Could Mario Bros 3 in Mario All Stars for example have Mario Bros 3 NES music, or is this impossible?
I've got an NSF for Mario bros 3 and an SPC for Mario All Stars. Not sure what else to do.
I thought the music was already the same (but with different instruments) between the NES and Super NES versions of Super Mario Bros. 3. What are you trying to do? Make the Super NES version use square waves to sound just like an NES? Reintroduce the slight desynchronization in the airship theme that was fixed in the Super NES version? Your actual goal informs the choice of replacement technique of least effort.
Quote:
Make the Super NES version use square waves to sound just like an NES?
This.
Isn't there at least one NSF player for the SNES? Surely you could use the same techniques it uses to simulate the NES sound channels.
The SNES is alas poorly suited to play baack square waves, because they'll either sound very lowpass-filtered, or you won't be able to reach high notes (or both). So in order to sound decent you'll need a collection of square waves at different lengths and play the longer ones when lower notes are played and the shorter ones when higher notes are played. Also the square waves might be pre-highpass filtered to sound more NES like.
In anycase I don't see much interest in doing that, the music is the only major difference between the NES and SNES versions, so if you were to hack the SNES version to have a music more similar to the NES version, why not just play the NES version instead ?
+ better graphics + no flicker + no wrong colors at edges
"better" graphics
calima wrote:
+ better graphics + no flicker + no wrong colors at edges
Any emulator can easily remove sprite flickering, and Nestopia can easily mask the rightmost 8 pixels in order to hide the wrong colours - as for "better" graphics, I don't see why you'd desire them if you don't desire "better" sound.
Some other options:
-AVS solves most cancelling/flickering in 16 sps mode
-add a new layer of paint onto the chr-rom (sure, it's not original then)
-Move it out of NROM, make new custom graphics
-Fiddle with the scrolling engine and mirroring (pretty cumbersome to do just to be able to play a more personalized and polished copy)
I really dislike the shading they added to sprites on the SNES version, and to me it feels kind of darker somehow. More detailed backgrounds is a good addition, but I don't like the colors there either. Actually, looking at both versions in detail, it totally loses the "staged play" feel of the original version with things in the horizon with parallax scrolling and fog...
And there's the overuse of colours and gradients again making everything feel oddly rounded (besides active choices to round corners) i bemoaned in the snesdev thread. It's like everythings' made out of hard candy.
(on the other hand, as a kid i always thought the blocks used in the staircase to the flagpole looked like chocolate blocks).
FrankenGraphics wrote:
as a kid i always thought the blocks used in the staircase to the flagpole looked like chocolate blocks
Maybe even more than the actual chocolate blocks in Castle of Illusion's (SMS) candy level, but they're similar.
This is a good example of how low-pass it would get:
https://www.youtube.com/watch?v=gyS5ymEURJw
Just had an idea...
What if it's an MSU-1 hack?
The only cappy thing is, you'd need an SD2SNES or a specific emulator.
BUT thoeretically this is possible to deploy with NES clarity using MSU-1.
I tried writing some spc700 code to see how long it takes to make a square wave in software, and I got this:
Code:
ldw {phase_0} //5
adw {frequency_0} //5 10
stw {phase_0} //5 15
cpy {duty_0} //3 18
bcs + //2 20
adc {output}={volume_0} //6 26
+;
Already 26 cycles, and the spc700 only has 32 cycles between samples.
Maybe doing two samples at once would be a little bit better.
On the other hand, it would be faster if the SPC700 generated square waves by decrementing a register by a certain amount until it went negative, then add another value back to the negative number and updated the sample for the channel. It would be unpredictable how much CPU it will take, so it should draw it to a BRR sample.
You could probably get away with mip-mapping them. Pre-generate a bunch of BRR waveforms of the form 7666...66679AAA...AAA9 and filter 0, one for each combination of octave and duty. (The 7 and 9 are pre-emphasis to fool the Gaussian interpolation into behaving more like cubic spline interpolation.) Then switch each channel's loop point among them based on the octave and duty in effect at any given time. This would cause a "phase reset" of sorts when crossing octaves, but the 2A03 APU has those anyway.
It's a matter on memory vs speed. Though using "speed" method you'll get an extra crispy square wave.
But you've got plenty of memory on hand. Generate square waves of lengths 16, 32, 64, 128, 256, and 512 for the three audibly distinct duty cycles the NES APU can produce, for a total of 1008 samples or 1008 * 9/16 = 567 bytes per channel. Round that up to 768 to account for padding consideration when switching among waveforms, and you're still only up to 2.25 KiB out of the 64 KiB that the APU has. Then have the player tweak each pulse channel's loop point to switch among them.
Doesn't the faux retro jingle from the intro of Donkey Kong Country bypass the filtering somehow and preserve the aliased sound of the triangle?
lazygecko wrote:
Doesn't the faux retro jingle from the intro of Donkey Kong Country bypass the filtering
No. I just put my
DKC cartridge in my Super NES, listened to the first six measures of the intro, and couldn't hear the
telltale 31st and 33rd harmonics, which are supposed to be in the 4K-8K band for the notes being played. It's also unrealistic in that the triangle channel has smooth volume control.
I thought of a way to do it through software. Calculate the slope of the output for each channel combined, and then recursively add the output of the previous sample.