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
28
Location
center of the Sun
Website
kuribo64.net
XP
2,451
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
0
Age
48
XP
585
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,159
Trophies
0
Age
31
Website
normmatt.com
XP
1,853
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,291
Trophies
2
Age
35
Location
Levelland, Texas
Website
www.mariopc.co.nr
XP
6,128
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
35
XP
364
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
Global Moderator
Joined
Sep 23, 2013
Messages
15,153
Trophies
2
XP
12,226
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
795
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,177
Trophies
0
Age
41
Location
somewhere
Website
spinalcode.co.uk
XP
2,608
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
35
XP
364
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,177
Trophies
0
Age
41
Location
somewhere
Website
spinalcode.co.uk
XP
2,608
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.
General chit-chat
Help Users
    KenniesNewName @ KenniesNewName: https://www.reddit.com/r/Eminem/comments/ae9ts3/eminem_fan_mail/?utm_medium=android_app&utm_sourc...