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

[mvmiranda]

 

[DiscostewSM]

The current method for making this list (that gets sent to the GPU to render the tiles) is to figure out where the tiles start (like what tile occupies the top-left corner), and then from left to right, top to bottom, figure out what tiles are there and send those to the GPU. This is done each and every frame (in the simplest form). What it does when it examines each tile is it looks up the background layer information, which is already a linear sequence of tile references. The thing is, not every single tile changes each frame, so the data needed from one frame to another may not change, at least for the entire layer. The idea is to have this list already premade, and directly change this list as tiles on the layer are changed, so rather than examine each tile per frame, it'll simply take the existing list and send that off. It may put more pressure on the GPU (because you may be sending off lists that have a large portion not on-screen), but from what I understand, there's a lot left unused by it, and that most of the stress is on the CPU (having to examine each tile among other things like actual emulation).

Sorry if that still doesn't explain it.

 

[Xenon Hacks]

The current method for making this list (that gets sent to the GPU to render the tiles) is to figure out where the tiles start (like what tile occupies the top-left corner), and then from left to right, top to bottom, figure out what tiles are there and send those to the GPU. This is done each and every frame (in the simplest form). What it does when it examines each tile is it looks up the background layer information, which is already a linear sequence of tile references. The thing is, not every single tile changes each frame, so the data needed from one frame to another may not change, at least for the entire layer. The idea is to have this list already premade, and directly change this list as tiles on the layer are changed, so rather than examine each tile per frame, it'll simply take the existing list and send that off. It may put more pressure on the GPU (because you may be sending off lists that have a large portion not on-screen), but from what I understand, there's a lot left unused by it, and that most of the stress is on the CPU (having to examine each tile among other things like actual emulation).

Sorry if that still doesn't explain it.

That makes more sense lol had me confused

 

[themperror]

Loading Kirby's Dream Land 3 makes the app and 3DS completely freeze (have to hold the power button till it turns off) on 1.2, Will try 1.3 now

-Edit-

Same case on 1.3

Loading Kirby's Dream Land 3 (USA).sfc..
ROM type: headerless LoROM
ROM size: 4096KB / 128 banks
SRAM size: 32KB
ROM loaded, running...

Then total freeze, no image is displayed, top screen stays black and lower screen only has aforementions text.

Ok read a bit back on the thread.. Seems Kirby's Dream Land 3, uses an enhancement chip.. That's why it doesn't work.. NVM

 

[TheZoroark007]

Will roms with enhancement chips ever work ?

 

[Onion_Knight]

Will roms with enhancement chips ever work ?

I believe that it is in the future plans, but what sense would it make to start working on chip enhancements when he's still not done getting the core functionality itself good to go? I believe he is still working on the SPC timing.

 

[Arisotura]

StapleButter, would it be possible to have a pre-made display list regarding background layers that changes when writes are made to the lower 32KB section of VRAM, and then take from this list when forming the true list instead of having to examine each tile within view of the screen manually per frame? I've been thinking about this kind of thing for a bit for improving list generation, but only speculation, no actual proof. And something like this would only work with Modes 0, 1, 3, and 5 (because the others either use offset-per-tile or affine transformations).

I'm not sure pre-built display lists would give much of an improvement. We'd end up drawing a lot of shit offscreen (and it turns out that we're already taking a lot of GPU time per frame because there's a yet undetermined cause that makes homebrew get subpar GPU performance). The code would get more complex. Also, tilemaps aren't always static-- a prime example would be the level layer in SMW. The game updates the tilemap as you move forward or backward.

Something we really need is 1. figuring out what's wrong with GPU performance (it should be more performant) and 2. find out how to use the bumpmapping crapo to simulate color palettes. Both things on which I'm getting nowhere.


I'm losing motivation. Should work on something else for a while.

 

[Hattr]

I'm losing motivation. Should work on something else for a while.

Perhaps you can pickup gameyob?

 

[davhuit]

I'm losing motivation. Should work on something else for a while.

:/ Why not rather focus on the SPC timing which break a lot of games? Then, you could have a pretty good working version and take a break from it.

Unfortunately, it seems all the emulators developped on the 3DS are cursed, because I don't remember to have seen one developped until the end yet (so working fine, with sound, good framerate and good compatibility) yet :/

But of course, if you don't feel motivated anymore, there is no reason to force yourself to keep working on it.

 

[Arisotura]

It doesn't mean the project is dead. I just need to go do something else.

And then there's the typical 'too many projects' syndrome. Blarg.

Oh and in the meantime that doesn't keep DiscostewSM from doing changes. I will still be accepting pull requests and all.

 

[DiscostewSM]

I'm not sure pre-built display lists would give much of an improvement. We'd end up drawing a lot of shit offscreen (and it turns out that we're already taking a lot of GPU time per frame because there's a yet undetermined cause that makes homebrew get subpar GPU performance). The code would get more complex. Also, tilemaps aren't always static-- a prime example would be the level layer in SMW. The game updates the tilemap as you move forward or backward.

Something we really need is 1. figuring out what's wrong with GPU performance (it should be more performant) and 2. find out how to use the bumpmapping crapo to simulate color palettes. Both things on which I'm getting nowhere.


I'm losing motivation. Should work on something else for a while.

I understand that tilemaps aren't static, but the idea was to have this pre-made list that is basically a map of the VRAM, that when VRAM is updated, the list updates along with it. While sending off these lists would force to GPU to cull a good amount of off-screen tiles (putting more stress on the GPU), I think the idea could benefit both CPU and GPU. You believe that the GPU has a problem, resulting in subpar GPU performance, but what if it isn't the GPU? Currently, the GPU has to wait for the CPU because the CPU has to fill in the list, but the sooner the list is ready, the sooner the GPU can begin work. A game like Super Metroid works pretty well in various areas, achieving 60fps, but the moment you go into other areas like Maridia, it starts to get choppy. That's because 2 out of 3 background layers are changing per scanline. Counting just those 2 layers, that would be up to 33 tiles per scanline, ~224 scanlines. That's 14784 tiles the GPU has to render per frame, which isn't a lot considering that's less than 1 million per second, but that's how many tiles the CPU has to examine to put into the list. Compare that to areas that don't change per scanline (again, just looking at 2 layers). Up to 33 columns, 29 rows. That's only 1914 tiles to examine/render per frame, which is almost 1/8 the work the CPU has to deal with in the previous example. If I do get the time and formulate a point of attack, I'll attempt to try this pre-made list idea.

As for color palette simulation via bumpmapping, I really can't help you there because I don't know much about how that works other than what I've read. Reading is different from implementing, and I don't even know how such implementation of that is done with our current homebrew tools.

 

[Idaho]

It doesn't mean the project is dead. I just need to go do something else.

And then there's the typical 'too many projects' syndrome. Blarg.

Oh and in the meantime that doesn't keep DiscostewSM from doing changes. I will still be accepting pull requests and all.

Well Blarg is already in great state, sure it could be improved further but you contributed well, thank you !
I hope your future projects will be 3DS related, keep us informed anyway

 

[BETA215]

Still would be nice to have something that didn't require an expensively priced little cartridge.

Yeah, like an R(3D)4!

 

[davhuit]

I also think BlargSnes already work pretty good. Just manage to fix the spc timing problem might fix most games that doesn't work right now and it would become a pretty good emulator.

At least, it's open source so progress won't be lost if the project is dropped one day.

 

[DiscostewSM]

While no enhancement chips have been implemented (that I know of), I have at least got the system to examine whether a game does use one of the many that exist, and reports it on load. Say, you try to load Super Mario Kart. Before, it wouldn't tell you anything. Now it'll tell you...

** DSP-1 chip detected **
This chip is not implemented.

It'll still attempt to run the game, but it won't get very far. I tried at least one game per enhancement chip, and so far, they all report something, except for one that crashed the emulator. That title is Daikaiju Monogatara II, which uses the S-RTC chip.

 

[WeedZ]

I'm losing motivation. Should work on something else for a while.

How about 3d rendering in blarg? I'd be motivated to cheer you on.

 

[Pa0l0ne]

Hi, first of all i would like to thank StapleButter and DiscostewSM for the BlargSnes existence, than i would like to ask about a compilation problem that exist with the actual ctrulib on my Win DevkitPro Environment.

Have you any idea how to fix this?

Any help is appreciated!

 

[CalebW]

Hi, first of all i would like to thank StapleButter and DiscostewSM for the BlargSnes existence, than i would like to ask about a compilation problem that exist with the actual ctrulib on my Win DevkitPro Environment.

Have you any idea how to fix this?

Any help is appreciated!

Update ctrulib from git and recompile.

 

[Arisotura]

I think that's the opposite thing, too recent ctrulib. Apparently they refactored the CSND API.


And 3D rendering isn't likely to be in any time soon. I'm thinking about writing up a document explaining in detail all the obstacles so it's covered once for all. Per-tile priority, midframe changes to graphics, and so on... SNES graphics often look like they're just a set of flat layers and sprites applied to the whole screen, but it's often more complex than that.

A prime example in SMW's Yoshi Island 4. The water and the HUD are both on BG3; the position of that layer is changed midframe to achieve the desired effect. Unaware people would think they are separate layers, but technically they're not.

But the main deal breaker is per-tile priority, really. It would just look weird to have a BG with certain tiles popping out.

And 3D wouldn't work at all in Earthbound. The map is on BG1, and the tiles that need to cover sprites (houses, signs, whatnot) are duplicated on BG2. Attempting to make this 3D would completely ruin it.

 

[ShadowOne333]

StapleButter IMHO, I think the priority for any emulator that's in WIP, should be compatibility first, fancy shit afterwards.
And I think 3D support for blargSNES should be at the bottom of the list of the to-do stuff... That's if it even makes it.

Of course, every SNES ROM works with its BG and Sprites in different layers and layouts, so not every game will work in the same way with a 3D effect as everyone thinks they would.

Same applies for NES ROMs, people that have fucked around with ROMs for hacking purposes like I have, know that each game handles Background sprites and Foreground sprites differently, sometimes background could be trees and sky, sometimes ground and a brick, who knows?

It's awful, and 3D would only work properly for some games that share the same sprite layouts, in order to make 3D work for most games, it would require special 3D coding for EACH GOD DAMN game to make it work with a proper 3D effect.

Heck no. XD
I would much rather prefer to play my beloved classics with great sound and no framerate drops (like it is for most games right now) than to worry about 3D support.