> It's funny you mentioned WLA-DX .. I even switched once to ca65 and then *went back* to WLA DX. I think I am masochistic these days, which could probably be why I'm good at any of this stuff.
You'd kind of have to be, yeah :P
In bass:
Code: Select all
macro seek(offset) {
origin {offset}&$3fffff //hirom
//origin ({offset}&$7f0000) >> 1 | ({offset}&$7fff) //lorom
base {offset}
}
seek($c00000)
98% of mappings described in literally two lines of code in a macro. Yet you have the flexibility to implement vastly more complex mappers if you wanted (64MiB ROMs, MMC-based ROMs, etc.)
I will never understand (nor want to) the complexity of mapping in WLA-DX.
> Who is "we"?
The people on my forum that are heavily into SNES dev.
> Now I could get into further details of why I feel your better file format(s) or tool(s) did not gain popularity
You don't have to, I already know the reason.
> for Streaming -- Why is it safe to assume no timing info needs to be logged? Isn't that making an assumption that all data being written is at the earliest possible moment? The assumption might suit a lot of test cases, or all of them, but this is definitely an assumption! Unless you school me.
When you are emulating the SFM file, you're producing the timing and adressing information again. The bytes written to $f4-f7 that are logged act like an assembly line. It doesn't matter how fast or slow that line moves, so long as the bytes come out the other end in the same order, and they will as long as both the recorder and player have correct timing.
Emulator movie files work on the same principle: they are only a linear stream of 1 = pressed / 0 = clear bits recorded for each time the emulator polls input. So you can record a movie file that can be used to perfectly play back a video game with only 12-bits per frame, or 90-bytes a second, provided you have the original ROM for playback. SFM is the same, SFM is effectively the "original ROM for music playback."
> I don't see how the traditional SPC logging of this information doesn't already have this covered
SPC didn't know about the required state in the beginning. The existing rips are missing the information. Adding a new emulator-specific section to log new fields is not a solution. That's basically making another new format and calling it SPC still. You'll spend the rest of time trying to replace older SPC rips with better, newer ones; and trying to get people to use newer SPC players that support the new state.
> the minimum that SPC already provides seems sufficient and relieves us of additional complexity to the format.
> Can you agree with me to leave out emulator-specific state and just leave in traditional SPC state, namely DSP vals, CPU reg vals, and RAM snapshot.
It's not sufficient. It's not a full state capture. It may not cause any bugs in playback, but it might. It might not result in two different players producing different output (because they assume different values for the undefined state), but it might.
> Of course, even if I/we make a new format, SNES Tracker will support SPC as well!
Right, everyone will support SPC because that's the format that everything's already in.
And that's why everyone will keep using SPC.
And that's why iNES 1.0 will still be the predominant file format in 2116 for NES ROMs.
See? I told you I understood this :)
> I didn't know SNSF required a whole-system emulation.
It's basically the original SNES ROM. They just go in and hack out as much as humanly possible, and patch some of the code. So the reset vector jumps to the song player as soon as possible with a small patch. Then they kill out everything not used.
It's clever, but SFM is a much better way of doing it. Especially because it doesn't require someone with ROM hacking skills to create. And because you don't have to emulate the SNES CPU as well.
> I do wonder if it would take more or less space to log timestamped writes instead of bare reads
No matter the case, timestamps wouldn't save you at all. If the ripper and player don't have the same opcode timing, it will fall apart during playback. But again, it's a non-issue. We know the exact cycle timing of every instruction on the SMP and DSP, thanks to blargg. It has all been verified (although blargg's SMP core has errors, so you'd not want to use that.)
> Yeah, I planned that.
I was going to point out that it seemed a bit immature to associate your software with venereal diseases, but then it dawned on me that the C++ standard library's namespace is "std", so ...
> Of course, after a format is defined, someone like Byuu would be most fit for writing in the new SPC export feature, while someone like me could write the new SPC Import feature, and then we'd have a working prototype.
I gave up on it over the internal state serialization issue.
They say perfection is the enemy of good, but that's what got us iNES, IPS, SPC, etc in the first place.
I don't want to be the guy responsible for over-looking some detail that ends up requiring everyone to replace SFM with some newer, better format ten years down the line. Or much, much worse ... the format everyone says is "good enough" and just groans about the problem(s) it has.
> doing a "value,repetitions" pattern could be efficient. But compared to real compression solutions, this might be a joke.
Correct. The data will be very highly repetitive. Even in the case of ripping Tales' streaming opening song, compression helps immensely. Amateur hour compression like RLE won't hold a candle to even something as simple as ZIP.
And the biggest space savings in SNES music is that the sound player engine and samples are 95% identical between songs. This is why they use solid archivers like RAR for SPCs. It's better to just leave compression to better tools for the job. And when an even better compression comes along, you can switch to it without having to throw out your existing format.
> I hope y'all like what I'm cooking!
I don't mind you playing around with the idea. Maybe you'll come up with some new ideas I like :)
But I want to stress two things. First, my original warning: you will
never gain any kind of serious adoption of your format, no matter how amazingly awesome it is. Second, I'm not planning to work on this now, so you would have to patch bsnes yourself to rip into your format, sorry. I am totally swamped with work as always.
> Very clever indeed! But how do you support infinite playback?
I've never seen a streaming game that has infinite playback.
Non-streaming games won't need it. Just like how infinite playback SPCs right now work, you'd return #$00 from reads from $f4-f7 once the stream log runs out (in this case, it wouldn't exist, so that'd be immediately.)
But even if we contrived some example of an infinite streaming song, it would eventually loop, so the format could encode its own "after X samples are decoded, seek back to sample Y" to form a perfect, clean loop just like MSU1 PCM files do.
The only way you could intentionally break this would be to create a truly irrational format (pardon the pun ... you'll see) by doing something like streaming the computed bits of pi on an endless loop. Which, I don't really care about silly cases that don't exist, and won't exist outside of intentionally trying to break the format :P
