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

Status
Not open for further replies.

Arisotura

rise of melonism
OP
Member
Joined
Dec 5, 2009
Messages
839
Trophies
1
Age
29
Location
center of the Sun
Website
kuribo64.net
XP
2,488
Country
France
A little progress report of the last days: banging my head against an obscure crash bug. Debugging those with no debugging facilities and a retail console that just freezes when crashing, is real fun.

The cause of it may still be present in the code so I need to patch more places against that.


Other than that, I got sprites somewhat working. Except they don't flip and are all 16x16. I'll do the rest tomorrow.
 

sgtkwol

Well-Known Member
Member
Joined
Oct 29, 2008
Messages
222
Trophies
0
XP
270
Country
United States
Sprites, in 3D? That would be a great use of 3DS hardware, once this is in a more stable form. Bottom screen for configuring the oddly configured sprite layers.
 
  • Like
Reactions: Margen67

ferret7463

Well-Known Member
Member
Joined
Sep 21, 2010
Messages
613
Trophies
1
Age
50
XP
618
Country
United States
A little progress report of the last days: banging my head against an obscure crash bug. Debugging those with no debugging facilities and a retail console that just freezes when crashing, is real fun.

The cause of it may still be present in the code so I need to patch more places against that.


Other than that, I got sprites somewhat working. Except they don't flip and are all 16x16. I'll do the rest tomorrow.
That is what being the first to try something new means. You doing great and don't stress over it.
 

Normmatt

Former AKAIO Programmer
Member
Joined
Dec 14, 2004
Messages
2,161
Trophies
1
Age
33
Website
normmatt.com
XP
2,131
Country
New Zealand
A little progress report of the last days: banging my head against an obscure crash bug. Debugging those with no debugging facilities and a retail console that just freezes when crashing, is real fun.

The cause of it may still be present in the code so I need to patch more places against that.


Other than that, I got sprites somewhat working. Except they don't flip and are all 16x16. I'll do the rest tomorrow.


Wait 3dmoo and citra can't run your emu?
 

Apache Thunder

I have cameras in your head!
Member
Joined
Oct 7, 2007
Messages
4,392
Trophies
3
Age
36
Location
Levelland, Texas
Website
www.mariopc.co.nr
XP
6,693
Country
United States
I would assume that pixels hidden behind a different layer like a sprite or player character are actually being rendered anyway. Why would the SNES waste CPU cycles removing/adding back background layers? layers on top always have priority, so for example the player character which likely has it's own layer or is on some kind of sprite layer would be the layer that refreshes while layers below them are loaded with all pixals being rendered and it only calculates where the top layer data is. It's automatically obscured by the end result, but in memory, I'm sure the obscured pixels are actually still there. ;)
 

planetarian

Well-Known Member
Member
Joined
Aug 5, 2014
Messages
143
Trophies
0
Age
37
XP
384
Country
United States
I would assume that pixels hidden behind a different layer like a sprite or player character are actually being rendered anyway. Why would the SNES waste CPU cycles removing/adding back background layers? layers on top always have priority, so for example the player character which likely has it's own layer or is on some kind of sprite layer would be the layer that refreshes while layers below them are loaded with all pixals being rendered and it only calculates where the top layer data is. It's automatically obscured by the end result, but in memory, I'm sure the obscured pixels are actually still there. ;)

Sorry, my wording was a bit off. What I'm concerned about is not whether lower-layer objects get rendered, but something a bit different.

For example... this isn't SNES, but illustrates the problem well (and I'm most familiar with it on a technical level): If I recall correctly, Sonic games use two sets of tiles for for levels: one for the actual tile artwork, and a matching set that contains metadata like solidity, surface angles, and more importantly, foreground/background mask. That latter bit determins which pixels in the art tileset are drawn on the foreground layer, and which are drawn on the background layer, so they don't need to draw separate foreground and background tiles.

This means that in cases similar to this (obviously sonic isn't on SNES but the same principles may apply to some games), behind pixels marked as 'foreground', there's literally nothing to render (except sprite data, anyway). The result is that if you make it 3D without doing some sort of additional work, you may end up seeing some of the 'empty' background behind the foreground. Just an example.
 

loco365

Well-Known Member
Member
Joined
Sep 1, 2010
Messages
5,457
Trophies
0
XP
2,927
And even if it didn't, preloading the rom image into memory should be a minor tradeoff for debug facilities

Actually, looking at this, would it be possible to have a second version of this emulator as a .dat that has a rom preinjected (Sorta like that GB emulator)? Or would that area of the console not have enough permissions to properly work?
 

gamesquest1

Nabnut
Former Staff
Joined
Sep 23, 2013
Messages
15,153
Trophies
2
XP
12,237
No, have a way to run with ARM11, my Chip8 work in ARM11 .dat
ahhh okies, i seem to remember seeing stuff about that, but correct me if im wrong but there is some technical reasons why .dat homebrew didn't really take off, im not a dev so im not clued up on the specifics, but basically from reading up a while back the .dat homebrew is running on bare bones whilst .3ds has access to 3ds services or something along those lines :lol:
 

st4rk

nah
Member
Joined
Feb 11, 2014
Messages
542
Trophies
0
Website
st4rk.net
XP
815
Country
Brazil
ahhh okies, i seem to remember seeing stuff about that, but correct me if im wrong but there is some technical reasons why .dat homebrew didn't really take off, im not a dev so im not clued up on the specifics, but basically from reading up a while back the .dat homebrew is running on bare bones whilst .3ds has access to 3ds services or something along those lines :lol:

Exact, with .dat you can't use some services from ARM11, then it is a big problem..

Sorry Off-topic.
 

spinal_cord

Knows his stuff
Member
Joined
Jul 21, 2007
Messages
3,219
Trophies
1
Age
42
Location
somewhere
Website
spinalcode.co.uk
XP
3,286
Country
Sorry, my wording was a bit off. What I'm concerned about is not whether lower-layer objects get rendered, but something a bit different.

For example... this isn't SNES, but illustrates the problem well (and I'm most familiar with it on a technical level): If I recall correctly, Sonic games use two sets of tiles for for levels: one for the actual tile artwork, and a matching set that contains metadata like solidity, surface angles, and more importantly, foreground/background mask. That latter bit determins which pixels in the art tileset are drawn on the foreground layer, and which are drawn on the background layer, so they don't need to draw separate foreground and background tiles.

This means that in cases similar to this (obviously sonic isn't on SNES but the same principles may apply to some games), behind pixels marked as 'foreground', there's literally nothing to render (except sprite data, anyway). The result is that if you make it 3D without doing some sort of additional work, you may end up seeing some of the 'empty' background behind the foreground. Just an example.


From the little I remember from older SNES emulators, each layer is rendered fully and displayed in a specific order depending on the game. There may or may not have been many games with tiles within a background having different priorities to sprites, I know some games did, which is evident on some incomplete emulators. I would think simply rendering each layer at a different offset for the 'other' eye should would quite well, maybe even have a .ini file or something per game with offset settings that the user can adjust. There's a youtube video out there somewhere that shows some SNES emulation rendered in 3D so the theory is perfectly sound. But I think it would be best to get the emu fully working first before adding 3D into the mix.
 

planetarian

Well-Known Member
Member
Joined
Aug 5, 2014
Messages
143
Trophies
0
Age
37
XP
384
Country
United States
From the little I remember from older SNES emulators, each layer is rendered fully and displayed in a specific order depending on the game. There may or may not have been many games with tiles within a background having different priorities to sprites, I know some games did, which is evident on some incomplete emulators. I would think simply rendering each layer at a different offset for the 'other' eye should would quite well, maybe even have a .ini file or something per game with offset settings that the user can adjust. There's a youtube video out there somewhere that shows some SNES emulation rendered in 3D so the theory is perfectly sound. But I think it would be best to get the emu fully working first before adding 3D into the mix.

Right, we know all that already. The issue is when you encounter games that actually don't have anything in the art tiles for what's behind foreground tile art. Let me use an illustration to demonstrate:

On the left, a typical game which has art for background and foreground, and simply draws one to foreground and the other to background.

On the right, a game such as those in the Sonic series where a single art tile is used, and a mask determines which pixels get sent to foreground layer and which get sent to background.

Top row: actual tile data.
Middle row: what gets drawn to the foreground and background layers)
Bottom row: example 3D result, simulated by offsetting the background 4px right and 2px up.

95f4d229104f31c07b892d6fc78229ea.png


Make sense?

Obviously, it'd be best to wait until the emulator is fully functional until we start prodding the dev to implement 3D to begin with. It's still fun to discuss though =)
 
  • Like
Reactions: Margen67

spinal_cord

Knows his stuff
Member
Joined
Jul 21, 2007
Messages
3,219
Trophies
1
Age
42
Location
somewhere
Website
spinalcode.co.uk
XP
3,286
Country
Right, we know all that already. The issue is when you encounter games that actually don't have anything in the art tiles for
what's behind foreground tile art. Let me use an illustration to demonstrate:

On the left, a typical game which has art for background and foreground, and simply draws one to foreground and the other to background.

On the right, a game such as those in the Sonic series where a single art tile is used, and a mask determines which pixels get sent to foreground layer and which get sent to background.

Top row: actual tile data.
Middle row: what gets drawn to the foreground and background layers)
Bottom row: example 3D result, simulated by offsetting the background 4px right and 2px up.

95f4d229104f31c07b892d6fc78229ea.png


Make sense?

Obviously, it'd be best to wait until the emulator is fully functional until we start prodding the dev to implement 3D to begin with. It's still fun to discuss though =)

Sure, your explanation makes sense, but I really don't think any SNES games did that. Load up an snes emulator that allows removing layers (usually with num keys 1-5) I don't remember ever sing a game where the back/foreground is masked out in any way. Usually the whole layer is drawn, quite often if there was more than one background layer used, it was for parallaxling so would scrol at different speeds anyway.
 
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • Sicklyboy @ Sicklyboy:
    sshfs allows you to mount networked storage on a machine as a FUSE filesystem. It's sftp under the hood but has all of the interactivity and usability you'd expect of a locally mounted filesystem. Downside, it can slow down a little bit with massive directories, but I haven't personally run into that yet
  • Sicklyboy @ Sicklyboy:
    This perspective is all linux oriented fwiw. I believe there's an sshfs driver for Windows, but I haven't used it yet. and no idea for MacOS
  • K3Nv2 @ K3Nv2:
    Ftp is life if not on wifi
  • wolffangalchemist @ wolffangalchemist:
    yeah ftp and occasionally samba at the house.
  • impeeza @ impeeza:
    By the way under Windows you can use Total Commander to access so many sources as drives, SFTP, FTP, WebDav, Cloud shares, etc.
    +1
  • Veho @ Veho:
    Total Commander rules.
  • Xdqwerty @ Xdqwerty:
    I think i can't sleep
  • BakerMan @ BakerMan:
    jailbreaking windows and android is op
  • Xdqwerty @ Xdqwerty:
    Wut
  • BakerMan @ BakerMan:
    i thought that's what they were talking about
  • Xdqwerty @ Xdqwerty:
    Ohkay
  • HiradeGirl @ HiradeGirl:
    Funny.
  • Xdqwerty @ Xdqwerty:
    I heard the first súper meat boy game is better
  • HiradeGirl @ HiradeGirl:
    Free is good.
  • Xdqwerty @ Xdqwerty:
    I almost never use steam, just gonna pirate it
  • Xdqwerty @ Xdqwerty:
    And I heard the steam client makes your pc go slow
  • Xdqwerty @ Xdqwerty:
    Oh and it stopped working with Windows 8.1
  • HiradeGirl @ HiradeGirl:
    That's fair.
  • HiradeGirl @ HiradeGirl:
    I don't know if the epic games store still works in Windows 8 or not
  • Xdqwerty @ Xdqwerty:
    I heard epic is worse
  • K3Nv2 @ K3Nv2:
    Epics given more free shit out than my mom and people still want to bitch about them
    +1
  • wolffangalchemist @ wolffangalchemist:
    i probably n
    eed to make a epic games account, just have never been arsed too, i have as steam backlog that is pretty endless, on top of other games on my consoles.
    wolffangalchemist @ wolffangalchemist: i probably n eed to make a epic games account, just have never been arsed too, i have as steam...