Homebrew blargSnes -- SNES emulator for the 3DS (WIP)

[alexenochs]

Here's what I have to do:

Make sure there is a snes/rom.smc in the BigSD, start app, load rom.
If no rom is present in the BigSD:/snes/ folder, the app will lock-up your 3DS.
To exit, eject the GW3DS, as trying to return to the main menu will not work.
When you eject the card, the console will reboot. Just reinsert the GW3DS and reboot GW-mode to resume normal operation.

As I mentioned in my post earlier, this build is very buggy. You really should wait for the official release.

do you have problems with smw freezing after beating a stage? ive tested a few games on this also to anyone using this unofficial build do NOT turn the 3d slider on especially after booting the game up also dkc doesn't work for me... and all stars freezes but staplebutter mentioned he got them working? in this build?

 

[bobmcjr]

do you have problems with smw freezing after beating a stage? ive tested a few games on this also to anyone using this unofficial build do NOT turn the 3d slider on especially after booting the game up also dkc doesn't work for me... and all stars freezes but staplebutter mentioned he got them working? in this build?

Mario All-Stars works for me (using the version that doesn't have Super Mario World).
DKC Freezes on the 1993 copyright screen (I'm guessing he didn't commit the DKC fixes yet).
F-Zero boots but freezes on some tiles after starting a race.
Kirby Superstar freezes on a black screen (the intro uses fancy graphics).
Wario's Woods and Super Mario World work fine
Mario Kart is a black screen
Super Metroid is good.
Zelda freezes on links room.
Earthbound freezes, but that's a known issue.

BTW, you can start with 3D on and it displays fine. Just don't toggle 3D

 

[alexenochs]

Mario All-Stars works for me (using the version that doesn't have Super Mario World).
DKC Freezes on the 1993 copyright screen (I'm guessing he didn't commit the DKC fixes yet).
F-Zero boots but freezes on some tiles after starting a race.
Kirby Superstar freezes on a black screen (the intro uses fancy graphics).
Wario's Woods and Super Mario World work fine
Mario Kart is a black screen
Super Metroid is good.
Zelda freezes on links room.
Earthbound freezes, but that's a known issue.

BTW, you can start with 3D on and it displays fine. Just don't toggle 3D

it also appears that pausing the game by pressing on the screen and unpausing can freeze smw and probably some other games

 

[kyogre123]

Super Bomberman shows the backgrounds at 1/4 of their original length.

 

[PhoenixWrightX]

Let's all remember at this point compatibility doesn't even matter since its not an official release, codes/plugins are missing etc.

 

[Gadorach]

(I'm guessing he didn't commit the DKC fixes yet)

Exactly. I actually waited for a while before trying to compile the source, hoping he'd commit the new build, but he didn't so I just went ahead with it for now. I'll update it when he does. If nothing else, hopefully everyone who was thinking this was further ahead than it actually is, has been given a reality check, and now understands how much work is left before this becomes an actually viable emulator.

As an added note, I compiled this with the 4.8.2 gcc libraries, where it originally was set to use the 4.7.1 gcc libraries. This may be causing additional issues with the application, which is another reason why I stress that it is an unofficial build.

 

[Cyan]

I disabled your link for the moment, I think you should respect the developer's choice to wait before releasing it to users, for reasons he already stated.
I know it's open sources and anybody can do it (but until now, nobody did to release it), but if you can compile it then keep it for yourself as a test/beta build.

If StapleButter doesn't see any objection that other users release work he didn't want to release yet to users, I'll restore your post.

 

[Arisotura]

No, no prereleases please.

Outside of the emulator core, blargSnes is in a pretty bad state right now- closing your 3DS and reopening it causes screens to not display anymore, trying to return to the home menu without pausing first freezes in the home menu, pausing and resuming breaks games because it doesn't restart the SPC700 thread, and so on...

Long story short, there's a ton of problems with the interface. I don't want such a buggy version to spread on the internet. That would be a bad thing. See when I first announced blargSnes, how many sites posted about it? If something were to be released, it'd spread over the internet like a straw fire. I'd rather the build that spreads is a good, stable build.

And more importantly, I don't want a ton of noobs whining about all the problems I mentioned above. Not that I dislike bug reports, those are always welcome, but it's annoying to read posts about the same issues over and over again when they're already known.


The reason I go open-source is that I'm for sharing work and information. Especially in something like the 3DS scene. Please don't make me regret that. I don't want to be forced to go closed-source.


If you figure out how to build blargSnes on your own, good for you. But keep that build to yourself.

 

[alexenochs]

Staples I have to apologize I was somewhat the one that started the begging and people seen this and it ended up compiled unofficially I'm sorry fosmwt but I have to say just seeing smw. Running on my 3dad yesterday made my whole day he'll I even had 2.3b release from gateway I was happier to have this Yes there are a lot of glitches and problem but that doesn't overlook the fact that it runs and works with at least one game hey I'm getting some enjoyment out of your work thus far and I think when your done others will too!

 

[gamesquest1]

yeah i also have to agree it was nice having a sneak peek....even though it is incomplete.....your doing a great job and i know it doesn't represent the end product but it was fun to see non the less

but i do fully understand that if the masses got hold of it you might be swamped with pointless "this is broke" and "fix this game NOWWW" types of responces

 

[Cyan]

It's maybe too late, I don't know if I removed it in time.
I hope only users who understand the issue got it and will keep it for themselves.

Next time, ask before acting, instead of releasing and telling "tell me if you don't want"
even more if you knew no build was released yet and the developer wasn't ready for that.
it's like leaking SSSPwn because many users asked for it, but you would have removed the link if smealum asked after you posted it...
not the correct order to act

 

[Gadorach]

It's maybe too late, I don't know if I removed it in time.
I hope only users who understand the issue got it and will keep it for themselves.

Next time, ask before acting, instead of releasing and telling "tell me if you don't want"
even more if you knew no build was released yet and the developer wasn't ready for that.
it's like leaking SSSPwn because many users asked for it, but you would have removed the link if smealum asked after you posted it...
not the correct order to act

Apologies, I'll refrain in the future, and I already took down the link I put up. It'll be nice to see it in a more complete forum, and it's great that it led to a few more legitimate bug reports. Also, there were about 70 downloads total of the link while it was up. Whether or not it is shared, I don't know, but it did make me, and other users, happy to see it running, even with the current bugs. I also put it in the homebrew thread to limit its exposure, as putting it in the BlargSnes thread would have been a much worse idea overall in terms of exposure.

Additionally, though I agree that it shouldn't be shared again until StapleButter decides it should be, I wouldn't put this at the same level as releasing SSSPwn early.
Releasing BlargSnes was more of a "here's what it can do for now, so be more patient" kind of thing, where as releasing SSSPwn early would destroy it's spread completely by giving Nintendo the time to patch it before the legitimate users had the chance to hear about it and have a completed interface to use it with.

Homebrew < Exploits

That doesn't mean that I don't want to respect the authors wishes, but he also did not specifically say that he did not want anyone sharing his builds either, only that he would not make an official release yet. Now that he has said that, no more will be made, at least by myself, but it wasn't specified until now, so cut me a little slack.

And to conclude, I am thrilled that this is progressing, as are the other users here. I will be personally happy to contribute to it as soon as I finish re-learning C++, and can get back on the C train. Thanks again for all the work, and it's looking great so far!

 

[DiscostewSM]

From the look of things, Smea has GPU support for the release of SSSpwn, so when that releases, you can try taking advantage of that rather than doing it via software rendering.

 

[the_randomizer]

From the look of things, Smea has GPU support for the release of SSSpwn, so when that releases, you can try taking advantage of that rather than doing it via software rendering.

I didn't think that was possible because that could have tremendous impact on performance

 

[DiscostewSM]

I didn't think that was possible because that could have tremendous impact on performance

To be honest, I'm not sure how it can be done, but I would imagine it would need to follow the scanline render method. Can it be done with shaders, and would the 3DS's shaders be able to manage it? I'm not even sure which sort of shaders the 3DS has (programmable or fixed, and whether it makes a difference in this case).

 

[the_randomizer]

To be honest, I'm not sure how it can be done, but I would imagine it would need to follow the scanline render method. Can it be done with shaders, and would the 3DS's shaders be able to manage it? I'm not even sure which sort of shaders the 3DS has (programmable or fixed, and whether it makes a difference in this case).

Either way, I hope that we'll see many more emulators, like Genesis/Megadrive as well

 

[Arisotura]

Hardware rendering might (and only might) be done for sprites. But the fact they can have BG-relative priorities doesn't help.

The reason why hardware rendering isn't really possible is that on the SNES, you can change the PPU registers in the middle of a frame. Many games make use of this to for example, simulate additional layers by changing layers' positions. Hell, it's even possible to change the video mode in the middle of a frame (see SMW boss fights).

All of this is cool, but you just can't emulate it on a 3D GPU. Or maybe you can by some complex means, but the complexity of that would likely kill the performance benefits of hardware rendering.


Might look into it, though. It appears the SNES emulator on the PSP renders sprites in hardware. I'm not sure how it does it, though, and if/how sprite BG-relative priorities are handled.

 

[DiscostewSM]

Hardware rendering might (and only might) be done for sprites. But the fact they can have BG-relative priorities doesn't help.

The reason why hardware rendering isn't really possible is that on the SNES, you can change the PPU registers in the middle of a frame. Many games make use of this to for example, simulate additional layers by changing layers' positions. Hell, it's even possible to change the video mode in the middle of a frame (see SMW boss fights).

All of this is cool, but you just can't emulate it on a 3D GPU. Or maybe you can by some complex means, but the complexity of that would likely kill the performance benefits of hardware rendering.


Might look into it, though. It appears the SNES emulator on the PSP renders sprites in hardware. I'm not sure how it does it, though, and if/how sprite BG-relative priorities are handled.

But I think you're looking at it in a way of rendering tiles/sprites as-is (8x8 and 16x16) rather than looking at it from scanline point of view. If shaders could be used, then perhaps for the background layers (and even including sprites into it), you can set up 224 (240 or whatever) polygons that (based on screen dimensions) are 256 pixels wide and 1 pixel tall, and set each "polyline" with the necessary information for rendering the layers, and let the shaders handle the rest.

Then again, I could be completely wrong about how all this works.

 

[Arisotura]

If the PICA200 shaders can do integer arithmetic and bitwise logic, it might work.

It'd have to be tried out eventually.

 

[Gadorach]

If the PICA200 shaders can do integer arithmetic and bitwise logic, it might work.

It'd have to be tried out eventually.

From a general search, there doesn't appear to be any information stating that it does, or doesn't, support any general-purpose compute capability, so I'd ask a more in-the-know dev to check it out for you.