blargSNES revival??

[Arisotura]

Any of you folks remember blargSNES?

Hmm...

I got it to build against modern libctru/etc. At some point during the process, it produced these interesting graphics... it's mostly working now. There are still some issues to work out.

This made me realize:
- This codebase is 8 years old. Time flies.
- The renderer is cursed, especially the part that attempts to hardware-accelerate SNES graphics.
- I still write cursed renderers (see: melonDS).

I feel like messing with blargSNES some. I have a few ideas in mind to hopefully improve performance and accuracy, we'll see how this goes.

 

[the_randomizer]

It had so much potential, too bad it was tragically cut short, same with that Snes9x that bubble2k16 made, leaving only Snes VC injection if you wanted Snes emulation with accurate audio.

 

[Arisotura]

Like many of my projects, it fell to a lack of motivation from me. Probably also doesn't help that this happened throughout late 2015 and 2016, that's been a troubled time for me (started with me getting sick of univ shenanigans, mom's shenanigans, and ended up with me moving out, some ensuing shitfest, and the existance of melonDS).

If I recall right, blargSNES would benefit from more compatibility, especially fixing the CPU/SPC sync issues that break some games. And other thing; after all, this emulator's core is custom and it's not as mature as, say, melonDS.

Another issue would be, well, getting it faster without relying on frameskip. I can probably use the better GPU knowledge to try making things faster. I have some other, more exotic ideas. We'll see...

 

[AleronIves]

It had so much potential, too bad it was tragically cut short, same with that Snes9x that bubble2k16 made, leaving only Snes VC injection if you wanted Snes emulation with accurate audio.

What's wrong with the audio in Snes9x?

 

[the_randomizer]

What's wrong with the audio in Snes9x?

Snes9x 1.51/1.43 is inaccurate. It predates Blarg's S-SMP core and is Zsnes like, that's why. Snes9x 1.52 and above use cycle accurate audio.

 

[AleronIves]

I know older versions are inaccurate, but how does it manifest? Does the audio actually sound off key, or something? I've played through some games on 3DS, and the audio sounds fine. If you want perfect SNES emulation, you're not going to get it on a 3DS.

 

[the_randomizer]

I know older versions are inaccurate, but how does it manifest? Does the audio actually sound off key, or something? I've played through some games on 3DS, and the audio sounds fine. If you want perfect SNES emulation, you're not going to get it on a 3DS.

Yes, and games that require pinpoint audio accuracy don't play sound effects at all, Earthworm Jim 2 for example. Uses audio streaming from the S-SMP/SPC700, if it's broken, there are no sound effects. Cursor sounds in FF games are off and sound weird, the Lavos Scream in Chrono Trigger also broken.

 

[Flame]

Any of you folks remember blargSNES?

Flame remembers.

 

[AleronIves]

SNES VC doesn't have those problems? I wonder how Nintendo did it. My understanding is that newer Snes9x versions with accurate audio are too slow on 3DS, so it seems unlikely Nintendo went that route...

 

[orangy57]

your emulator was great, what exactly were the limitations? I played tons of Kirby's Dream Course with this on the o3DS back in 2015 but i don't remember if superFX games worked. My only wish back then was for 3D support by moving the closest graphics layers closer to your face. Even if the project didn't get completed to your standards it was pretty impressive to run the SNES with good sound(!!) on weaker hardware than Nintendo allowed before Nintendo even announced SNES VC.

 

[the_randomizer]

SNES VC doesn't have those problems? I wonder how Nintendo did it. My understanding is that newer Snes9x versions with accurate audio are too slow on 3DS, so it seems unlikely Nintendo went that route...

No, they optimized VC ROMs on a per-game basis as with the Wii VC. NERD likely worked on the emulation. SPC700 wasn't cycle-accurate but good.

 

[AleronIves]

That's what I expected Nintendo would do, but you said you can use VC injects to get accurate audio. Wouldn't the level of audio bugs vary widely from game to game since you don't have a custom set of emulation hacks for each game you're injecting?

 

[the_randomizer]

That's what I expected Nintendo would do, but you said you can use VC injects to get accurate audio. Wouldn't the level of audio bugs vary widely from game to game since you don't have a custom set of emulation hacks for each game you're injecting?

No, some games have broken audio or missing channels on Snes VC.

 

[Arisotura]

You can follow the revival branch in the blargSNES repo if you want to stay updated.

I've been optimizing the hardware renderer some, mostly reorganizing the way things are done in order to reduce the amount of render target/shader changes. I think it's paying off, even though I can't really compare -- older blargSNES releases don't run correctly on my 3DS.

 

[MarioKartFan]

This is incredibly exciting! Thanks!

 

[Arisotura]

Lil' update...

I felt like trying to address some of the shortcomings of the hardware renderer. Namely, the graphical glitches that plague Cool Spot (and other games).

The game does a couple fun things:

1. Some of the screen area between the HUD and the game area is force-blanked, the game uses that area to upload a new color palette for the game area.

2. See the black bar at the bottom? Same shenanigans -- the game force-blanks the bottom of the screen to give itself an artifically longer VBlank time. Notably, it will begin updating its VRAM and OAM as soon as that black bar begins.

These are a problem for the blargSNES hardware renderer because it always does all the rendering upon VBlank, and uses the palette/VRAM/OAM as they are at that time. Hence the glitches in Cool Spot, for example.

What I'm trying to do here is change the renderer to render screen sections as needed. In a 'typical' game, the behavior should be the same (renders upon VBlank and that's it), but in a game like Cool Spot, whenever the forced-blank mode is turned on, we immediately render a whole screen section as required.

It's looking promising, but it's not done yet. Namely, I need to rework the way palette changes are detected. Right now, the tile cache considers that a tile is invalid if there has been any modifications to its corresponding palette, regardless of the actual palette contents. This could well be problematic for cases where the palette is modified midframe.

 

[Arisotura]

Some more work on the renderer! Cool Spot is nearly perfect. Two issues remain:

1. on the explanation screen, the spot character animation is glitched. It's because the game starts DMAing new VRAM contents a bit too early (scanline 208, while forced-blank is enabled at 209). blargSNES doesn't emulate DMA timings, and that's something I might want to look into (prolly gonna do it in a way similar to how melonDS does it, but that means I need to add a proper scheduler).

2. there are glitches in the subscreen, which manifest in things like the translucent balloon sprites. I'm sure this is caused by accessing the tile cache while it's still in use by the previous frame, and I'm not sure how to address this in a way that doesn't kill performance.

 

[Arisotura]

Okay, so for the day's progress:


You know the n°2 glitch I mentioned in the previous post? That one has been a ride. I spent all of yesterday trying to track it, messing with things all over the place, fixing some other bugs in the process...

In the end, it happened because the tile cache was being updated while still in use for the previous frame. I added a clever double-buffering mechanism to the tile cache, it fixed that issue and it doesn't seem to impact performance negatively. Well, I was told the DMA is pretty fast.

So there's that.


You know, that screen in Tetris Attack that was glitched? Well...

It's rendering correctly in the hardware renderer now. Took a bit of extra fix0ring.


I was reminded of another fun glitch: the sky background gradient thing in Donkey Kong Country. Issue there is, it changes the palette midframe, but there are atleast two entries involved. Entry 0 is the backdrop color, and the renderer is equipped to deal with that, no problem. But it also changes some other entries, that are used by the background layer, to achieve a fun fog-like color effect. That's problematic because I don't really see a simple way to support that in the hardware renderer as it is. It would imply somehow keeping track of the different per-line palette colors and integrating them in the tiles as they're decoded, and the tile decoder has no idea where a given tile is going to land onscreen (because, really, it could be used anywhere), so this sucks major balls.

Oh well.


Regarding blargSNES itself, I was considering finishing backporting DiscostewSM's fixes from the veryhard branch, fixing up the APT shito so that home-menu suspend and all work correctly, and making that a 1.4 release. How does that sound?

I've been having fun with this, but I feel like I'm a few years late to the party, and it doesn't help that the blargSNES emu core isn't as competent as the more mature emulators out there (though I feel it's mostly really plagued by CPU/SPC sync issues).

To be honest, my last commit to blargSNES was in November 2015, and that was when 'fun' things happened to me. Long story short, I got sick of univ (and mom being an annoyance about it), moved out of my parents' home, dealt with jobhunting and depression... and then there's my typical ADHD. Probably how I ended up creating melonDS in November 2016.

 

[MarioKartFan]

I find this thread really interesting. Like one of Daves threads covering his DS development work. We haven’t had one on the 3DS side for a long time. I hope you keep plugging away and keep sharing your findings.

 

[drewby]

Super happy to see this! Something exciting for the 3DS scene in 2022 is a rare sight nowadays.