Aaendi
Members-
Posts
53 -
Joined
-
Last visited
Recent Profile Visitors
317 profile views
Aaendi's Achievements
Star Raider (3/9)
58
Reputation
-
BRR is another name for the ADPCM-A sample format the SNES uses. You can find information here: https://wiki.superfamicom.org/bit-rate-reduction-(brr) Doing a full software conversion from wave to brr that makes use of all it's features is pretty processor intense, but there is a 4-bit PCM mode that simplifies it a lot, but is slightly noisier. The SPC700 also has it's own little CPU inside of it, but isn't as fast as the main CPU, but it can run it's own programs while the main CPU is busy. I'm attempting to do an additive synth on the SPC700.
-
I got my software synth code down to just 3 second to draw a 16384 sample long BRR sample. I think this as fast as I can get under the restrictions I placed on it, such as only using 8-bit precision and only using filter 0 and filter 1. The only way to make this even faster is if I restrict it to just using filter 0, and give every block the same range settings, so it acts like a 4-bit PCM. (Or make the 65816 do it, but this would be a lot easier.)
-
Blargg was able to get 16-bit stereo PCM at 32000kHz, which means that it can update 128000 bytes per second. However, that keeps the 65816 busy the entire frame, so it's not practical during gameplay. A more reasonable approach would be to HDMA 4 bytes per scanline, which would theoretically be able to use up to 4*224*60 = 53,760 bytes per second, if the spc700 is in a timed loop that is 65 cycles per loop. However, the spc700 uses a stupid ceramic resonator that isn't synced up with anything else in the system, so if you are doing 4 bytes per scanline you would need to sync it up every several lines in order for it to work, in case of drifting, so you would loop through several scanlines with 65 cycles per loop, then wait for a "sync pulse" so it can resync itself every several lines.
-
It seems to be more of a problem on my desktop computer than my laptop computer for some reason. The biggest issue right now is how long it takes the SPC to synthesize BRR samples. Luckily I was able to get it down to 6 seconds for 16384 samples (9kB). Originally it was over 10 seconds. I got it down by using a bunch of lookup tables, unrolled loops, self-modifying code, etc.
-
Axelay
Aaendi replied to Wayler's topic in Super Nintendo Entertainment System (SNES) / Super Famicom
From looking at the screenshot, I think I can tell what Konami was trying to do. I think the game is trying to remove sprites that are hiding behind other sprites. If the fireballs were shaped like squares, you wouldn't be noticing sprites in the back disappearing, only the sprites in the front. -
Axelay
Aaendi replied to Wayler's topic in Super Nintendo Entertainment System (SNES) / Super Famicom
The torso and head are on a background layer. I'm guessing each of the fire balls that make up his arms are 48x48 and use 9 16x16 plus 2 hands that are 64x32 so that means that his arms already take up to 88 sprites. -
Axelay
Aaendi replied to Wayler's topic in Super Nintendo Entertainment System (SNES) / Super Famicom
I think the game is surpassing 128 sprites too, since I can see individual 16x16 sprites disappearing, and it looks like Konami randomized it too.