The Sonic CD video finally finished processing.
I've uploaded it to github along with the source code because why not. Only included manifest.bml and not the .xml file since I haven't been able to make a .xml file work for it yet. Please let me know if anyone has trouble playing it,
I don't have the utmost confidence in the uploading that just happened (okay it worked). (I also don't know why github insisted on inconsistently double-spacing my code for me. Oh well.)
I'm disappointed with how much of it turned out. Consider this v1.0, I will be seeing if I can improve the results through some colour-merging, but I'm not terribly optimistic - it might cure the problems in the big solid colour regions, but then you also risk losing definition in the smoother more detailed areas.
I would like to point out that at least some of the problem is simply from scaling the video down to 15bpp SNES colour depth. The original was not a very clean video, but it was the best I could find. The little imperfections in the solid colours make it look like hell when they're all broken up though. It's far more noticeable on my monitor than on my TV, but I'd like it to look nice on both.
Now I just need somebody to port the game itself!
(please?)EDIT: Oh yeah I was going to mention. I think the sound is quieter than it should be on the SD2SNES. I know they had issues with how to blend the two audio signals. Considering I have to basically double the volume for it to sound right, might need looking into.
Khaz wrote:
Now I just need somebody to port the game itself! (please?)
It's really quite astounding that no one has even made a simple Sonic the Hedgehog demo yet.
There is Speedy Gonzales, and there's a Sonic-themed ROM hack thereof. (And on the NES, there's Somari, but that doesn't count because there's also Sonic for Master System/Game Gear.) I wonder if the lack of an attempted serious port has something to do with Sega legal.
tepples wrote:
There is Speedy Gonzales, and there's a Sonic-themed ROM hack thereof.
I hope we can all agree that that doesn't really... count as a "Sonic game"... It may have been inspired by it somehow but there's nothing even remotely similar in the gameplay.
Khaz wrote:
tepples wrote:
There is Speedy Gonzales, and there's a Sonic-themed ROM hack thereof.
I hope we can all agree that that doesn't really... count as a "Sonic game"... It may have been inspired by it somehow but there's nothing even remotely similar in the gameplay.
It's basically a pile of crap. I've even seen non Sega demos of a Sonic engine on the GBA before. One thing I've always wondered about the Sonic games is how they handle the loop-d-loops, but I know that whatever they do isn't perfect. (On Sonic 2, there's this one spot on Chemical Plant Zone, Act II where there's a bunch of the speed booster things and a loop-d-loop. It's fun having to wait for 10 minutes because you're stuck inside of a wall...)
Espozo wrote:
One thing I've always wondered about the Sonic games is how they handle the loop-d-loops, but I know that whatever they do isn't perfect. (On Sonic 2, there's this one spot on Chemical Plant Zone, Act II where there's a bunch of the speed booster things and a loop-d-loop. It's fun having to wait for 10 minutes because you're stuck inside of a wall...)
I found this to be downright fascinating reading myself:
http://info.sonicretro.org/Sonic_Physics_GuideMy own game is moderately based on their way of doing things, what with the sensor bars and such. I haven't implemented the more advanced physics like loops and ground-speed, but only because I'm not sure if I want that yet. I'm not trying to rip Sonic off here, their method just made by far the most sense to me for pixel-accurate collision detection...
As for getting stuck inside walls... I have to say given just how much of my life I spent playing Sonic 2 it's amazing how rarely that happened to me.
Khaz wrote:
As for getting stuck inside walls... I have to say given just how much of my life I spent playing Sonic 2 it's amazing how rarely that happened to me.
It mostly just happens there. Anyway, if you look at the picture in the link, (it's really big) it's the loop at the bottom and near the middle of the picture. If you go one of the ways, you have a significant amount of speed when you get there.
This is the link to the picture:
http://soniczone0.com/games/sonic2/down ... ct2map.png
Khaz wrote:
I hope we can all agree that that doesn't really... count as a "Sonic game"... It may have been inspired by it somehow but there's nothing even remotely similar in the gameplay.
The
Game Boy version is a much more obvious rip off, with many elements blatantly copied (spinning signs, deforming bridges, loops, springs, fans).
Khaz wrote:
Now I just need somebody to port the game itself! (please?)
If I'm remembering things right, Sonic 1 has been completely disassembled so if someone wanted to their could possibly port that game to whatever system they wanted. The SNES ofcourse has a lower resolution, and a completely different flavor CPU that would require alot of reworking of the program code. But if someone was determined enough, it could be done. With the MSU-1, you could stream the recorded Genesis music and only have to deal with the sound effects on the SPC.
MottZilla wrote:
The SNES ofcourse has a lower resolution,
That's not that bad. Just cut off 32 pixels on each side and when Sonic is going very fast in a particular direction, the camera moves to where you can see the 64 pixels in front of him but not behind him. The SNES of course offers it's own advantages over the Genesis, but if you want to make it a "pixel perfect" port, you're not going to.
MottZilla wrote:
With the MSU-1, you could stream the recorded Genesis music
Do you think that maybe you could have FM sounding sound samples in audio ram (or whatever it's called) and use those?
The SNES has a limited ability to reproduce the Sega Genesis sounds though its pitch modulation feature. There's a reason why I say limited, though...
- Four channel limit (or even fewer in some cases if you want more operators at once)
- Limited pitch control (you can't go beyond one octave without just sampling it)
There are probably some others, but these are a start.
Or instead of attempting to slavishly imitate FM at a low level, you could just arrange the soundtrack for the Super NES in much the same way that the PC ports of
Sonic games arrange the soundtrack for General MIDI. The steps that would have been done for a cross-platform game back in the day, had Sega not been exclusive to its own consoles, would have looked like this:
- Find another instrument that sounds like each instrument in the game. This can be done by matching patches to those that shipped with Yamaha synthesizers, by noting which General MIDI patches were used in official MIDI arrangements, or by identifying instruments in recordings of the soundtrack made with real instruments.
- Find samples to match these instruments.
- Translate the music sequence data to that of your preferred SPC700 sound driver.
What tepples said is what I had in mind. I imagine you wouldn't need that long of a sample to replicate the "FM style sound".
tokumaru wrote:
Khaz wrote:
I hope we can all agree that that doesn't really... count as a "Sonic game"... It may have been inspired by it somehow but there's nothing even remotely similar in the gameplay.
The
Game Boy version is a much more obvious rip off, with many elements blatantly copied (spinning signs, deforming bridges, loops, springs, fans).
Sadly it didn't copy the good physics.
And yes,
bootleggers took notice of the similarities already.
KungFuFurby wrote:
The SNES has a limited ability to reproduce the Sega Genesis sounds though its pitch modulation feature. There's a reason why I say limited, though...
- Four channel limit (or even fewer in some cases if you want more operators at once)
- Limited pitch control (you can't go beyond one octave without just sampling it)
There are probably some others, but these are a start.
On the flip side, you don't need to use sine waves. Perhaps you could get good results by starting with halfway-FMed samples and going the rest of the way with pitchmod.
Alternately, you could use loop-rewriting and/or sample-switching tricks to decouple modulation speed from playback speed in a static sample, which has the additional advantage of only requiring one channel...
Why not reimagine the music and use the strong poins of the SNES hardware instead of trying to force it to do what it wasn't designed to?
It depends on the philosophy of the person doing the port, I suppose. I like forcing the SNES to do stuff it wasn't designed to do but can anyway. And if you reimagine it, the result had better be damn good or Sega fanboys who've formed a subconscious bias in favour of MD sound will insist it proves the MD's sound chip is better.
Anyway, this depends on whether we're talking about Sonic 1 or Sonic CD. I believe the music for Sonic CD is a mix of sequenced sample-based tracks and CD audio, which sounds like it could map reasonably well to a combination of MSU1 and SPC700 work. Just be careful to properly prefilter your samples... In either case, the sound effects should probably be rebuilt rather than sampled so as not to muffle them or eat too much sample RAM...
tokumaru wrote:
Why not reimagine the music and use the strong poins of the SNES hardware instead of trying to force it to do what it wasn't designed to?
Why not just reimagine everything then? Give enemies their own palette so they could use more colors for shading and do the same with the backgrounds and add BG3 or make the first layer 8bpp. When sonic gets hit, he could also drop more rings. I like just sticking with how it originally was. Better yet, there could be some kind of mode in the options... (yes, I know this would require a good bit more memory, but I doubt Sonic 1 was that big of a cartridge anyway.)
93143 wrote:
And if you reimagine it, the result had better be damn good or Sega fanboys who've formed a subconscious bias in favour of MD sound will insist it proves the MD's sound chip is better.
I have never met someone with that opinion, but deep down in the depths of Sega 16, there's probably somebody...
Some cross-platform games do have better musical arrangements on the MD though, such as Pac-Attack.
Which if any Sonic games were ported to PC with MIDI sound?
To really get them riled up, ask them if their Master System or Game Gear could do
this rendition of Emerald Hill Zone.
Upon checking the Sega CD Sonic CD disc, it has all the music stored as CD-audio except for the "Past" theme of each level. So, if you were to do a port of Sonic CD to SNES, I think it would be perfectly reasonable to do the same thing over there, only porting the past themes onto SPC700. I think that would give a nice ideal balance between staying true to the original and using the SNES the way it was intended to be used. Sure you could have everything be exactly the same, but we've already heard what it sounds like on the Genesis. Why not hear something new once in a while?
My PC copy of Sonic CD has all the music as CD-audio, naturally, since it wouldn't sound consistent otherwise.
Edit: Nice Emerald Hill arrangement, where's it from?
The thing about that is, the "past" themes are reportedly all using just the PCM chip in the Mega CD, which has been described as essentially a budget SPC700... It should be possible to do a roughly 1:1 port without straining the SNES's design philosophy - unless there are instances where most or all of the channels are used and the sound effects have to kick something off the chip; depending on the circumstances it may be possible to use prerendered chords to get around this without dropping parts...
Khaz wrote:
Edit: Nice Emerald Hill arrangement, where's it from?
I think
I made it in 2007 to prove a point.
Uploaded a demonstration to Youtube. Long overdue but meh, better late than never. Wish I could have gotten a better quality video of the TV screen but I think it gets the point across...
byuu or Ikari: The first attempt at recording the video, the playback actually FAILED somehow. The audio screwed up very harshly for a moment near the end and the video started displaying garbage. How could the SD2SNES/MSU1 have an error like that...? Or is it maybe my SNES that's becoming unreliable?
"Sonic boom, sonic boom..." I was able to overlook the overexposure, but all I could think of is why isn't
the music I know for "sonic boom" playing?
You can always go with
"Toot Toot Sonic Warrior" if Sonic Boom bothers you.
I'm not the only person bothered by Sonic Boom.
Metascore 32
tepples wrote:
"Sonic boom, sonic boom..." I was able to overlook the overexposure, but all I could think of is why isn't
the music I know for "sonic boom" playing?
Took me while to understand that. lol. Anyways, as always,
the internet's got you covered. Just disappointed I couldn't find a mashup of the two songs since, you know, Guile's theme goes with everything...
Would still love an answer on why it failed on me the first time though. As a guy considering making serious use of the MSU1, that's disturbing...
What frame rate and resolution is this?
I'm pretty sure he said 15fps, with only one row of tiles missing so 256x216.
Quote:
why isn't the music I know for "sonic boom" playing?
This one is much better:
https://www.youtube.com/watch?v=vlz6qgahnYQtokumaru wrote:
"Toot Toot Sonic Warrior"
What? Is he a train? Sonic The Tank Engine.
Also relevant...
(Also, it does say Sonic Boom in the song still anyway.)
Khaz wrote:
byuu or Ikari: The first attempt at recording the video, the playback actually FAILED somehow. The audio screwed up very harshly for a moment near the end and the video started displaying garbage. How could the SD2SNES/MSU1 have an error like that...? Or is it maybe my SNES that's becoming unreliable?
Sounds like your SD Card goofed and was re-initialized or something. Or maybe its access time doesn't satisfy MSU1 requirements. Some cards take very long for random access after power up but speed up the next time. I guess the internal flash controller caches some NAND sector lookups or something. This is rather unpredictable.
You can check out the measured access time for your card in the System Information screen reachable from the main menu. Just wait until measurement completes and you get two values (average and max). It isn't 100% representative of the card's actual performance because it does not seek between ALL sectors but only a selection. But you might see a larger number for max after a cold boot (power cut) as opposed to leaving and re-entering the System Information screen.
See also
https://sd2snes.de/blog/card-list which lists some tested cards and their respective access times and MSU1 capability.
Thank you very much for the reply! I'm using the SD card that came with my SD2SNES. I will make a note to check it's timing when I get home. Though your answer does sound plausible - it screwed up during the first attempt at playback after sitting unused for a long time and then was fine after that.
I'm assuming if one were to implement an MSU1 configuration for a dedicated single-game cartridge in the future, you wouldn't want/need an SD card involved and this problem would theoretically be eliminated...?
That might be a solution. With raw NAND flash you can run into the same problems though. You could minimize random access by using separate chips for audio and data. Sadly there is no kind of flow control with the MSU1 spec which would help alleviate this.
About volume - the sd2snes audio output is rather quiet when compared to bsnes which mixes in MSU audio at full level. It is probably an oversight on my part. A possible hardware mod would be to run the DAC at 5V instead of 3.3V. I recommend normalizing all audio files to 0dB for use with sd2snes, ideally after decompression to avoid clipping in case they are to be shipped in a lossy compression format. That is the most you can get out of the sd2snes without the help of a soldering iron
> Sadly there is no kind of flow control with the MSU1 spec which would help alleviate this.
The idea was incompatible with the goal of simplicity, and wouldn't have been practical. I sacrificed a lot of stuff I really wanted, too, like multiple audio streams so you could do CD BGM+voice acting, enhanced sound effects, etc.
A single DMA can run for up to ten seconds, but even a realistic DMA can transfer a full 64KB of data through MSU1 in one shot. You're not gonna be able to take control of the flow to write back SRAM on a reset button press, or to fetch more audio samples, in the middle of a DMA.
The data was initially intended to be separate: I envisioned something like a giant NAND ROM for the data, and a CD (or another NAND ROM) for the audio tracks. The delays allowed for seeking, but sequential access was presumed after that.
Putting both streams on the SD card is incredibly convenient (and essential), but that complicates things and requires buffering. And of course, you have the save issue. My advice on the save issue would be to store a flag stating the currently loaded game name, hold the SRAM data via battery back-up until next power-on, and have the BIOS write back the SRAM when the system is turned on again and then clear that "SRAM write needed" flag. However, I understand if you don't want to special case just MSU1, or if that design isn't possible for some reason (eg maybe the SRAM isn't battery-backed?)
> That is the most you can get out of the sd2snes without the help of a soldering iron
Damn, so it really is impossible to fix in software, then =(
This is a really tough issue for me. There's only a few people making MSU1 hacks, and they all target sd2snes first.
The problem is that reducing the volume by 1/3rd throws away information that cannot be recovered just by amplifying volume back.
And I can't change the MSU1 spec to say volume should play at 66% max, because some games may have sound effects loud enough that MSU1 can't properly mix with them at that volume (I know, rare for SNES games that are notoriously quiet.)
Plus, matching a spec to a specific hardware implementation will only work once. If anyone else ever releases a flash cart with this support (I know, another long shot), I will be unable to compensate for two conflicting hardware implementations at the same time.
So I guess the solution remains that we need a tool to produce per-implementation MSU1 games. Generate XML for bsnes, BML for higan, or 1/3rd quieter audio for sd2snes.
...
By the way, while you're here ... would you be able to tweak the audio playback rate to 44100hz? The goal was to match redbook audio playback frequency, and it needs to be precise for some of the Satellaview hacks that expect audio to match up to in-game events, where the audio can be up to an hour long.
byuu wrote:
So I guess the solution remains that we need a tool to produce per-implementation MSU1 games
...
would you be able to tweak the audio playback rate to 44100hz?
I might have missed something, but... If a tool like that is created to adjust the volume (depending on MSU1 target), why not adjust the sample rate too ?
I'm going to provide a volume boost option for MSU1 audio. Just tried it out and it works better than expected (quite some headroom before clipping).
ikari_01 wrote:
I'm going to provide a volume boost option for MSU1 audio. Just tried it out and it works better than expected (quite some headroom before clipping).
I for one am excited by this development! Thank you!
> why not adjust the sample rate too ?
Certainly also a possibility. But the audio boost idea sounds extremely promising, so hopefully adjusting the clock rates could get the sample rates closer together (perhaps as an option as well?), in which case we'd have wonderful feature parity :D
Just need to extend icarus to handle importation of MSU1 games in a format compatible with sd2snes (game.sfc+game.msu+game-#.pcm), and I think we'd have a definitive distribution method!
For the Satellaview games with hour-long soundtracks, is there a reason they can't be split up into individual 1-minute tracks?
Incidentally, even though the MSU ought not to need it, what's the tolerance on the Super NES sound module's oscillator? I'm told it's wider than that for the 21.47 MHz master clock because it doesn't have to feed a color modulator.
Khaz wrote:
Uploaded a demonstration to Youtube. Long overdue but meh, better late than never. Wish I could have gotten a better quality video of the TV screen but I think it gets the point across...
Nice
Quote:
The video was rendered into SNES format by a python script that I invented, which you can also find on my github page (under SNESTools). The script takes in a simple bitmap file, breaks it down into tiles, quantizes a palette of 16 colors to represent each tile, and then merges similar palettes together until you have 8 remaining - the maximum number of color palettes the SNES can have at a time for "backgrounds".
Care to share info on your algorithm for the sub-palette merge section?
tomaitheous wrote:
Care to share info on your algorithm for the sub-palette merge section?
Well, if you can read Python the source is on my github linked in my first post here (file is "Quantomatic.py").
It works like this: Each palette has a variable of how well it represents its tiles, measured simply as the sum "distance" of each actual pixel color from the closest palette color. The program then compares a block of N palettes to each other (N defaults to 20 I think but can be adjusted), and merges the two that are the closest together before comparing the next block.
The comparison tests two palettes by checking what the sum "distance" would be if each palette's tiles were rendered in the other palette. The lowest sum distance found is declared the best fit, the two sets of tiles are merged into one, and a new palette is quantized out for the merged set.
Been a while so I'm rusty on the fine details, but if you want to know more I can look at the source code and explain. I'm sure it's probably possible to improve on my method; if you have a proposal how to I'd be interested to hear it.