Are High SNES Homebrew Expectations Justified?

[Pokun]

Yeah a lot of people suggest to prototype a game in a high-level language to speed up development, then port it over to the target platform when you get the concept working.

Personally I have the problem that my 6502 skills have surpassed my, quite basic, C skills long ago, and I'm simply not as comfortable with C and SDL2 or Allegro as I'm with 6502 and the NES hardware. It may seem backwards when there are better modern tools, but it's not really much different from what many developers for these systems did back in the day.
I should really brush up on my C skills sometime though. It's useful for making the tools you need for homebrew development as well.


Yeah the SNES S-APU is a beast in itself. I only just got it working myself. I've concluded that the only assembler that seems to produce correct SPC700 code is bass, so I made a table file for it using the official syntax, as I couldn't find one anywhere. I will share it very soon after some more testing.
Edit: It's here.

One thing the NES, SNES, and TG-16 all share is having a 6502-based CPU, so maybe the Game Boy is big on C more because people who have done 6502 assembly can't apply their pre-existing 6502 ASM knowledge to the Game Boy at all.

The Game Boy uses a Sharp SM83 CPU core, which is basically a modified Zilog Z80 (or Intel 8080). The Z80 is also used in all Sega systems up to the Mega Drive (where it's only used as a sound co-processor or in Mark III mode) and in many many arcade systems and PCs from the 80s or earlier, including ZX Spectrum and MSX (and is still used in TI calculators today). So knowledge of and information about Z80 assembly is at least as common as 6502. In fact Nintendo's programmers were angry at the engineers for choosing the, at the time obscure, 6502 as the Famicom CPU core over the more common Z80 that they were all familiar with. And as I understands it, the Z80 isn't much better for C than the 6502 either.

[tepples]

Gameboy seems to have this odd middle ground where it has a pile of good games, but also generally seen as simple enough that making a new C game doesn't seem "bad" but a lot of people have a deep love for it, possibly retrospectively thanks to the "music scene" around it.

That and the most obvious source of programmable single-game Game Boy cartridges sells no-mapper cartridges, which means 32 KiB ROM only. To fit, a project intended for cart release has to be either kept simple or treated as a sizecoding challenge.

However also nobody ( well okay maybe Tepples ) actually likes to write Z80 code.

One difficulty with programming for the Game Boy isn't Z80 as much as that the CPU isn't quite a Z80. Though sequential access to memory on 8080 family is more convenient in ways than on 6502 family, random access suffers. In particular, lack of the indexed addressing mode associated with ix and iy registers and no ex instructions to swap HL with DE or with top of stack mean there's a lot more register pressure when reading and writing properties of an actor. Wikipedia cites a French source claiming that even the Z80 proponents within Nintendo thought of the Game Boy as "DaMeGame" (dame だめ meaning 'bad' or 'hopeless'), which translates roughly as "Lame Boy" or "DaMaGed goods".

I've concluded that the only assembler that seems to produce correct SPC700 code is bass

What problems did you run into with blargg's SPC700 macro pack for ca65? If you have a GitHub account, feel free to report them against lorom-template.

[strat]

One difficulty with programming for the Game Boy isn't Z80 as much as that the CPU isn't quite a Z80. Though sequential access to memory on 8080 family is more convenient in ways than on 6502 family, random access suffers.

I guess it's been said here before but whereas in a 6502 program it's most efficient to store the same field sequentially, array-style (so all fields related to a single moving character can be accessed with the index in X or Y), on the GB cpu it's pretty much mandatory to bypass indexing by moving all the fields for each character into zeropage temp vars. Otherwise something as simple as this

Code: Select all

ldx character_index
lda lo_x_pos,X
clc
adc lo_x_vel,X
sta lo_x_pos,X

becomes something like this

Code: Select all

ld bc,lo_x_pos
ld h,00
ld a,(character_index)
ld l,a
push hl
add hl,bc
ld b,h
ld c,l
pop hl
ld de,lo_x_vel
add hl,de
ld a,(bc)
add a,(hl)
ld (bc),a

Any GB game you look at will probably have lengthy runs of pointer arithmetic because indexing from an address basically doesn't exist (it's only available for zeropage vars with the c-reg). I wonder if Kirby's Dreamland 2 had so few enemies and relied on the animal friends to increase the available special abilities just because the code ate up more space.

To keep this post on-topic, this is a cover-band doing Megaman X and the guitarist doesn't seem to use an fx pedal, so for ex. Spark Mandrill's stage doesn't have that reverb. Is the SPC's echo ability a value in itself for putting the game on SNES or just a convenience so the samples don't have to be composed with it?
https://www.youtube.com/watch?v=pg2aCvkmzbc&t=1089s

[Nikku4211]

To keep this post on-topic, this is a cover-band doing Megaman X and the guitarist doesn't seem to use an fx pedal, so for ex. Spark Mandrill's stage doesn't have that reverb. Is the SPC's echo ability a value in itself for putting the game on SNES or just a convenience so the samples don't have to be composed with it?
https://www.youtube.com/watch?v=pg2aCvkmzbc&t=1089s

To be honest, I think SPC700 echo is overused. Way too many SNES games use it, which doesn't help with the muffled sound many soundtracks on SNES already have. SPC700 echo feels more like a last-minute thing that doesn't really add anything meaningful to the song in most cases. Sometimes, it can detract from the song. Seriously, I would tolerate so many SNES songs if it weren't for misuse of the SPC700 echo.

[Pokun]

Even though a stock Z80 has IX and IY, they are slow and probably not as useful as X and Y on the 6502 when speed is important.

I've concluded that the only assembler that seems to produce correct SPC700 code is bass

What problems did you run into with blargg's SPC700 macro pack for ca65? If you have a GitHub account, feel free to report them against lorom-template.

That's like the one method I didn't try, since I kept forgetting about it, and I couldn't find that forum post either (only one with the non-standard syntax). But thanks for the link, I might try it once I get tired of bass' antics.

Reading Blarg's post, it looks like he wasn't able to make the "mem.bit" syntax work as it should. Bass doesn't have any problems with this (it was probably developed with the SPC700 syntax in mind, even though Byuu/Near never included it in the end) and I could easily make it do all SPC700 instructions exactly as specified. It has other weirdness though, like a very nontraditional C-like syntax for everything else, seems to lack many useful features like program listing, and requiring macros to do many basic things like defining storage in RAM. It's a blessing and a curse of an assembler.

[93143]

Is the SPC's echo ability a value in itself for putting the game on SNES or just a convenience so the samples don't have to be composed with it?

Baked reverb is only sufficient if you have effectively unlimited resources. Hauptwerk claims to use a convolution reverb engine now, but one of the notable points early on was that it relied on recordings of the reverberant tail of every pipe in the organ, which it would crossfade to when the key was released. This technique produces a VERY heavy channel load, particularly when the tails are long and you're playing quickly, and the SNES isn't really in that game. Baked reverb cuts off the moment you have to use that channel for something else. You could save sample memory by using standard chiptune soft-echo techniques, but that doesn't help the channel situation.

Sometimes you don't need the tail so much, but not every case is like that.

Also, sound effects would have to be baked with multiple reverb settings, for at least caves vs. above ground, and possibly more. Easy nowadays, but still a waste of space. Same applies to music if you want to use the same instrument with more than one level of reverb per game.

To be honest, I think SPC700 echo is overused. Way too many SNES games use it, which doesn't help with the muffled sound many soundtracks on SNES already have. SPC700 echo feels more like a last-minute thing that doesn't really add anything meaningful to the song in most cases. Sometimes, it can detract from the song. Seriously, I would tolerate so many SNES songs if it weren't for misuse of the SPC700 echo.

Sure, there are some SNES games that use the echo poorly. But there are others that use it extremely well. Having it available as an actual effect on the DSP is a substantial advantage to a composer, as well as to a sound effects programmer.

Of course, then there are those rare composers who managed to do stuff like abusing the echo feature as a programmable filter while still faking reverb well enough... I suppose you could contend that the filter should have been available on its own...

That filter is what makes it nontrivial to design a reverb on SNES. Volume, delay length and feedback are pretty simple to fiddle around with, but that filter will make or break an echo setting.

[dougeff]

You could process your audio with reverb / echo BEFORE converting them to BRR.

[93143]

You could process your audio with reverb / echo BEFORE converting them to BRR.

That's what I mean by "baked". It has several disadvantages, including a severe tradeoff between flexibility and memory requirements, and an inability to accurately render reverb tails without overstressing the S-DSP's relatively low channel count.

Also (and I forgot about this when composing my post above, probably because it's not that important), you can't pan baked reverb independently of the sample it's in. You'd need a second channel for that. The SNES has limited control over echo pan and volume, but it's there.

On the flip side, you can use a sophisticated high-quality reverb rather than the primitive S-DSP echo. However, as some developers have shown, it is possible to get surprisingly good reverb out of the SNES.

[Nikku4211]

To be honest, I think SPC700 echo is overused. Way too many SNES games use it, which doesn't help with the muffled sound many soundtracks on SNES already have. SPC700 echo feels more like a last-minute thing that doesn't really add anything meaningful to the song in most cases. Sometimes, it can detract from the song. Seriously, I would tolerate so many SNES songs if it weren't for misuse of the SPC700 echo.

Sure, there are some SNES games that use the echo poorly. But there are others that use it extremely well. Having it available as an actual effect on the DSP is a substantial advantage to a composer, as well as to a sound effects programmer.

What SNES soundtracks have used SPC700 reverb well enough to make the song actually need the echo?

I'm sure Square Enix RPGs would definitely be in that list, as they're the games everyone uses as an example of the 'best of' for anything SNES related.

You could process your audio with reverb / echo BEFORE converting them to BRR.

That's what I mean by "baked". It has several disadvantages, including a severe tradeoff between flexibility and memory requirements[...]

SNES hardware reverb uses up valuable ARAM (that can be better used) anyway, so /shrug.

[93143]

What SNES soundtracks have used SPC700 reverb well enough to make the song actually need the echo?

Ninja alert. I just edited in a link in my previous post that (IMO) answers this question.

It's not really a fair question anyway, at least the way you've phrased it. What game actually needs music at all? If it sounds better, that's good enough.

I've worked out how to add reverb to sound effects in Doom at several levels of realism, partly by harnessing the DSP echo across multiple channels. The most realistic setting can only handle two sound effects at a time even with MSU1 music. Does Doom need this? Obviously not; it got incredibly popular on PC without any such thing. I would still want to do it.

On the subject of sound effects, Super Mario World's caves had beautiful reverb (much nicer than the claustrophobic Super Mario All-Stars cave reverb), and it was a very ROM-constrained game.

SNES hardware reverb uses up valuable ARAM (that can be better used) anyway, so /shrug.

Not just ARAM. ROM. You need a separate sample (ideally a longer sample) for every reverb setting you want to use in the game. And as I said it's not the only problem.

Also, the hardware reverb only uses up ARAM if you turn it on, and it's in proportion to the EDL setting. It's not like it hogs half the audio memory just by existing. If you think you can do better without it, you don't have to use it (Tim Follin didn't).

The ToP soundtrack uses soft echo techniques combined with DSP echo. The effect is quite nice. In fact, IMHO the track I linked is better on SNES than on PSX, though that's admittedly more of an artistic matter rather than a technical one...

Another example: Hydropolis, from the same game.

Another example: Aroma of Stew from Energy Breaker. Yes, the reverb on that bird tweet is all DSP.

I don't really have a "list", as such. A lot of games use echo at least decently well in my opinion, and where to draw the line is a matter of taste.

[lidnariq]

SNES hardware reverb [also] uses up valuable ARAM

Except that samples with pre-baked reverb uses up ARAM for each sample you want reverb on, instead of a fixed buffer.

[tepples]

strat and others: Let's please take the digression about accessing properties of a member of an entity pool on Game Boy to the previous topic about this issue.

[Nikku4211]

It's not really a fair question anyway, at least the way you've phrased it. What game actually needs music at all? If it sounds better, that's good enough.

I guess my point is: how much of a difference does it make?

Sure, I can download the SPCs and disable the echo in SPCPlay, but I am aware that most of my opinions are... unpopular, so I want to know what other people think about the differences.

I've worked out how to add reverb to sound effects in Doom at several levels of realism, partly by harnessing the DSP echo across multiple channels. The most realistic setting can only handle two sound effects at a time even with MSU1 music. Does Doom need this? Obviously not; it got incredibly popular on PC without any such thing. I would still want to do it.

Yeah, I found it cool that ZDoom (a popular Doom source port with tonnes of added features) supports the REVERBS lump with the SoundEnvironment thing, even if I haven't found a single non-tech demo ZDoom WAD that uses this.

SNES hardware reverb uses up valuable ARAM (that can be better used) anyway, so /shrug.

Not just ARAM. ROM. You need a separate sample (ideally a longer sample) for every reverb setting you want to use in the game.

Wait, how?

[93143]

I guess my point is: how much of a difference does it make?

Sure, I can download the SPCs and disable the echo in SPCPlay, but I am aware that most of my opinions are... unpopular, so I want to know what other people think about the differences.

I can tell you what I think. I think the tunes I linked sound flat and dead without the DSP echo. The use of manual echo techniques helps some, but not enough. Perhaps it wouldn't be quite as bad if they'd been composed for an alternate-universe S-DSP with no echo feature, but I think it helps a lot to be able to use hardware echo.

They still sound nice dry once you get used to it, but turning the reverb back on breaks the illusion and shows you what you've been missing. I did that in the middle of Vigorous Town, and apparently SNESAmp emulates the echo even when it's turned off because the resulting sudden whoosh of audible space and reaction was breathtaking.

It is possible to come up with echo settings that sound good while playing, but not as an isolated reverb tail. Star Ocean has this problem, notably the track "Mother Ocean", which is super spacy and amazing music but man does it fall apart embarrassingly when the orchestra cuts out... I wonder if better filter settings could help smooth it out and shape the frequency profile a bit...

SNES hardware reverb uses up valuable ARAM (that can be better used) anyway, so /shrug.

Not just ARAM. ROM. You need a separate sample (ideally a longer sample) for every reverb setting you want to use in the game.

Wait, how?

How not? With DSP reverb, you can tweak it on the fly. With reverb pre-rendered into a sample, changing or removing it requires using an entirely different sample. Now you've got multiple samples instead of one, and since there's reverb on at least n-1 of them they're probably longer (perhaps a lot longer) than a dry sample would have been. If your game is 512 KB, this matters.

(Oh wait, I see the problem. I was unclear - it's not the DSP echo that eats ROM, it's pre-rendered reverb. Lazy phrasing.)

There's another thing. Sound effects and instruments can be (and on the SNES, often are) constructed out of raw samples by applying various synthesis techniques not expressible as linear filters, such as looping and modulation. Baking reverb into a sound produced in this way would typically require you to also bake in the synthesis process, potentially turning a short loop or two into a multi-second high-bitrate memory hog. Not only that, but any other sound effect or instrument that used the same short sample(s*) modulated differently would have to have a separate rendered version, and this is before considering the possibility of using multiple reverb settings...

Now, I'm not saying you shouldn't use pre-rendered reverb. It can be very effective under the right circumstances. But it can't do everything, not on a system as restricted as the SNES.

* You can play multiple short dry samples in quick succession and the DSP echo will smoothly span them all, but with baked reverb this requires either multiple channels or one giant sample.