Why no SNES homebrew scene?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Why no SNES homebrew scene?

Post by thefox »

rainwarrior wrote:
Hojo_Norem wrote:To paraphrase the SID's designer, audio chips of the time were designed with an engineer's mindset. The SID was designed with a musician's.
Enh, this is just a marketing slogan. Also I think the NES APU is somewhat distinct from other audio chips of the same time.
I don't think it's just marketese... the guy who designed SID went on to found Ensoniq. Obviously he paid a lot of attention to what musicians would want.

One could say that NES APU is designed with a musician's mindset, too, though. I don't think an engineer would implement things like the length counter lookup table without specifically being asked to.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Why no SNES homebrew scene?

Post by psycopathicteen »

93143 wrote:
syboxez wrote:Also the SNES's 64KB of audio RAM is extremely limiting.
It's not so bad if you're careful, skilled, and/or clever. The limits of a sound chip are what make it interesting to use, after all. And on top of the standard tricks of efficient sample use, there are all sorts of cool things you can do with the S-SMP, and some of them are recent or ongoing developments - KungFuFurby's loop switching and distortion techniques, psycopathicteen's software FM synthesizer, and so on. Even some commercial games used stuff like granular synthesis, pitchmod and FIR filter exploits, not to mention Square's famous wind noise generator. If the S-SMP had been given direct cartridge access, there might have been less interest in exploring some of the more obscure possibilities.

Besides, if you really need to bust the limit there are multiple streaming solutions out there fast enough for (low-fi) real-time playback or at least on-the-fly sample replacement. There's even commercial precedent in Tales of Phantasia and Star Ocean.

I maintain that an HDMA streaming scheme could be written to be capable of stable 2x32 kHz BRR, or 3x22 kHz, in parallel with a reasonably full-featured high-precision (>60 Hz) music engine. But I still haven't had a chance to test the streaming code I wrote, never mind write a music engine able to maneuver around it at high bandwidth. So until I do that, or someone else steps up to tackle the problem, the state of the art is (AFAIK) either N-Warp Daisakusen's stack-based HDMA scheme or SNESMOD's lazy-sync block transfer scheme (or am I out of date on what Super SNESMOD can do?). blargg's 2x32 kHz uncompressed demo doesn't count, as it requires the full attention of both CPUs and cannot be downscaled, and is thus all but useless in a game scenario...
The spc700 is frustrating to program though. There's no interrupts so if you're doing anything in real time, you have to make sure everything is within a frame.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Why no SNES homebrew scene?

Post by Oziphantom »

You do realize the SPC-700 was designed by Kutaragi , and is a "Kutaragi Special" so being a pain to program is its M.O.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Why no SNES homebrew scene?

Post by tokumaru »

Oziphantom wrote:When I said more colours I meant "more colours on screen" something like Mayhem in Monsterland is known to have 20 colours on screen at once thanks to various blending tricks.
The NES can show 25 colors per screen without tricks.
which means we can scroll without artifacts
The NES can scroll without artifacts too. Check out Jurassic Park, Felix the Cat, Alfred Chicken or Super Cars for various different ways in which it can be done. It's not the console's fault if Nintendo got "lazy" with its flagship title SMB3.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why no SNES homebrew scene?

Post by lidnariq »

Oziphantom wrote:Give then C64 divides the TV into 402x292 pixels of which we than take 320 out of those 402, in multicolour you get 201 pixels vs 256 pixels but we take 160 out of them.
I always thought the C64's dramatic underscanning looked rather unfortunate.

Nothing a modern HDTV's "zoom" feature can't fix, but...
Another thing is the C64s 16:10 aspect ratio means [...] it still works on a 16:9/16:10 tv/monitor without warping.
Different PARs in PAL/NTSC mean different DARs...
NTSC C64 320x200 : SDTV- PAR is 3:4 , DAR is 6:5 ; HDTV stretch- PAR is 1:1 , DAR is 16:10
PAL C64 320x200 : SDTV- PAR is ≈0.94, DAR is ≈1.5 ; HDTV stretch- PAR is ≈1.25 , DAR is ≈2

And you don't get vertical chroma blending in NTSC-land ... although maybe the reduced horizontal chroma bandwidth helps there?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Why no SNES homebrew scene?

Post by psycopathicteen »

Oziphantom wrote:You do realize the SPC-700 was designed by Kutaragi , and is a "Kutaragi Special" so being a pain to program is its M.O.
If you try to manipulate BRR samples in real time, you'd have to cut corners such as only using "filter 0". I don't know how long it would take the SPC700 to check which of the 4 filter types is best for an arbitrary waveform.
User avatar
Punch
Posts: 365
Joined: Sat Feb 16, 2013 11:52 am

Re: Why no SNES homebrew scene?

Post by Punch »

Oziphantom wrote: is a "Kutaragi Special" so being a pain to program is its M.O.
Citation needed
This is a block of text that can be added to posts you make. There is a 255 character limit.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why no SNES homebrew scene?

Post by lidnariq »

psycopathicteen wrote:If you try to manipulate BRR samples in real time, you'd have to cut corners such as only using "filter 0". I don't know how long it would take the SPC700 to check which of the 4 filter types is best for an arbitrary waveform.
That'd be going about it the wrong way. Instead, if you assume that you'll use the same filter for all blocks, then you can treat it as known filtering relative to the sample rate you play back at.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Why no SNES homebrew scene?

Post by psycopathicteen »

If you want to blend a square with a saw and an FM synth wave (crazy example), it might get a little less clear what filter is best.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why no SNES homebrew scene?

Post by lidnariq »

Filters 1, 2, and 3 are just nothing more than one of three fixed lowpass filters applied to filter 0.

It's really only useful for fidelity when you can switch from block to block: if you use a constant setting you're instead just saying that you want that lowpass filtering.

Actually, that's probably a good model for which filter to choose. The lower the pitches the softsynth is mixing, the stronger the lowpass filtering.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Why no SNES homebrew scene?

Post by Oziphantom »

tokumaru wrote:
Oziphantom wrote:When I said more colours I meant "more colours on screen" something like Mayhem in Monsterland is known to have 20 colours on screen at once thanks to various blending tricks.
The NES can show 25 colors per screen without tricks.
Hmm the docs I've read said 13... but I guess they meant per Background/Sprites to which sprites get 12?
C64 I can have 16 in the background(12 normally in multicolour mode), 16 in sprites. I can then use blending to push either or both above 16. Colour splits are trivial. And the colour is per 8x8 block for background, but 24x21 on sprites.. seems like the fortunes are reversed ;)
tokumaru wrote:
which means we can scroll without artifacts
The NES can scroll without artifacts too. Check out Jurassic Park, Felix the Cat, Alfred Chicken or Super Cars for various different ways in which it can be done. It's not the console's fault if Nintendo got "lazy" with its flagship title SMB3.
:) I though it was only with enchantment chips, MMC3 etc but some of those are NROM so I was wrong ;)
lidnariq wrote:
Oziphantom wrote:Give then C64 divides the TV into 402x292 pixels of which we than take 320 out of those 402, in multicolour you get 201 pixels vs 256 pixels but we take 160 out of them.
I always thought the C64's dramatic underscanning looked rather unfortunate.

Nothing a modern HDTV's "zoom" feature can't fix, but...
Well loosing the side of the a screen and the bottom on a NES oh well(Its possibly even a feature).. even on the PS3 we still had a "safe area", but on a word processor, spreadsheet not acceptable
lidnariq wrote:
Another thing is the C64s 16:10 aspect ratio means [...] it still works on a 16:9/16:10 tv/monitor without warping.
Different PARs in PAL/NTSC mean different DARs...
NTSC C64 320x200 : SDTV- PAR is 3:4 , DAR is 6:5 ; HDTV stretch- PAR is 1:1 , DAR is 16:10
PAL C64 320x200 : SDTV- PAR is ≈0.94, DAR is ≈1.5 ; HDTV stretch- PAR is ≈1.25 , DAR is ≈2

And you don't get vertical chroma blending in NTSC-land ... although maybe the reduced horizontal chroma bandwidth helps there?
the Programmers Reference Guide does have a table of "don't put this colour next this colour" (p152 if you are interested) not sure what spares the NTSC from blending vertically though, we use it in PAL as one of the blending techniques. lines of Pink and light blue make a nice purple for example, sadly all the online screenshots are emulator grabs and not photos.
Punch wrote:
Oziphantom wrote: is a "Kutaragi Special" so being a pain to program is its M.O.
Citation needed
http://www.interactive.org/special_awar ... lAwards=13
https://en.wikipedia.org/wiki/Super_NES_CD-ROM
See also the PS1 uses a high bit depth BBR as its main sample format like the SPC-700
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Why no SNES homebrew scene?

Post by tokumaru »

Oziphantom wrote:I though it was only with enchantment chips, MMC3 etc but some of those are NROM so I was wrong
Actually, none of those are NROM (can't remember what Super Cars uses, though!), but Jurassic Park is the only one that uses mapper features (MMC3's scanline IRQs and CHR bankswitching) for hiding scrolling artifacts, the other techniques are possible in NROM. There are a few other ways to do this without mapper assistance, even though I can't think of any games that demonstrate them all.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Why no SNES homebrew scene?

Post by Oziphantom »

:roll: *UNROM
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Why no SNES homebrew scene?

Post by psycopathicteen »

lidnariq wrote:Filters 1, 2, and 3 are just nothing more than one of three fixed lowpass filters applied to filter 0.

It's really only useful for fidelity when you can switch from block to block: if you use a constant setting you're instead just saying that you want that lowpass filtering.

Actually, that's probably a good model for which filter to choose. The lower the pitches the softsynth is mixing, the stronger the lowpass filtering.
If you have a 64 sample loop, it could happen where one part of the loop is busier than the other.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Why no SNES homebrew scene?

Post by lidnariq »

Oziphantom wrote:Well loosing the side of the a screen and the bottom on a NES oh well(Its possibly even a feature).. even on the PS3 we still had a "safe area", but on a word processor, spreadsheet not acceptable
Sure ... it'd just be nice if games had been able to use the whole width. The NES (and almost all the 3rd-generation-and-newer consoles) targeted an active portion of the scanline of 75%; the C64 (and Apple 2) targets an active duty of 60%. IBM CGA, Atari 2600, and Amiga OCS target a 70% active duty.
Oziphantom wrote:the Programmers Reference Guide does have a table of "don't put this colour next this colour" (p152 if you are interested)
Yeah, that would be the low chrominance bandwidth.

Too bad the dots for "excellent" and "fair" in the scanned copy I found are indistinguishable:
suggested-screen-and-character-color-combinations.png
not sure what spares the NTSC from blending vertically though, we use it in PAL as one of the blending techniques.
PAL and SECAM explicitly decode chroma using vertical subsampling, averaging the decoded chroma from any given scanline with the one before.

NTSC just doesn't. Better vertical color bandwidth, but worse horizontal color bandwidth.

End-of-SDTV NTSC sets often added a so-called "comb filter", i.e. the same thing as what PAL sets do, for the same reason (improving horizontal chrominance bandwidth at the cost of vertical). But that wasn't there in the 1980s.
Post Reply