Neimod has full kernel control from an unmodified 3DS

[431unknown]

hate to be that guy...
but when is neimod gonna stop being a dweeb and release somthing...?

When its ready.
Things take time and I'm sure he does other things also besides hacking.

 

[AeroblitzR]

yeah, that's true...
I don't even want 3ds roms, I just want homebrew like emulators

 

[RupeeClock]

yeah, that's true...
I don't even want 3ds roms, I just want homebrew like emulators

It'd be one thing just to release the exploit as it is, but making an emulator or anything takes time too.

Anyway there's the possibility that they haven't released anything yet, because they are waiting for Nintendo to issue another firmware update.
There we will see if it is safe to update or not, and take appropriate action.

 

[Rydian]

hate to be that guy...
but when is neimod gonna stop being a dweeb and release somthing...?

When are YOU going to release something?

 

[DaniPoo]

As I said, there is no need to stretch at all. There is only a 4 pixel difference on either side, just clipping those 4 pixels off would prevent any leaking of the layers while at the same time preserving a 1:1 pixel ratio, keeping the image almost exactly as it would be on SNES hardware (ish). My point still stands.

Are you against stretching or anything? you only stretches very litte to fill the gaps and its only on the background layers.
Basicaly you will still have the 1:1 experience if you dont stretch the layer the sprites interact with and that layer and the sprites at 0 depth.

 

[spinal_cord]

Are you against stretching or anything? you only stretches very litte to fill the gaps and its only on the background layers.
Basicaly you will still have the 1:1 experience if you dont stretch the layer the sprites interact with and that layer and the sprites at 0 depth.

Stretch = blur, blur = ugly. Especially on a low resolution system like the SNES, even more so when there will be only a small amount of stretch. It also seems that I misunderstood your original statement, I assumed that you meant the stretching would be required for the 3D effect to work, not that it could be used to hide some of the edges.

As for what SparroHawc said about it being too much work, I can't see how. SNES9x already allows the user to enable/disable each bg layer, which proves a couple of things, 1. the layers are already rendered separately and 2. the emulator already knows the priority of each layer, or else it wouldn't be displayed correctly to start with.
Really all that needs to be done, even i it is on a per game basis, would be to render one display as-is, then a second with the layers shifted to the side (by different amounts of course). All of which can be don automatically as the emulator already knows which layer is in front, which is second etc. "It's a minor gain for a lot of work" is just a way of saying "I don't want to", which is fair enough.

 

[Rydian]

I agree that clipping four pixels from the side would be much more preferable to stretching the layer.

 

[DaniPoo]

Stretch = blur, blur = ugly. Especially on a low resolution system like the SNES, even more so when there will be only a small amount of stretch. It also seems that I misunderstood your original statement, I assumed that you meant the stretching would be required for the 3D effect to work, not that it could be used to hide some of the edges.

As for what SparroHawc said about it being too much work, I can't see how. SNES9x already allows the user to enable/disable each bg layer, which proves a couple of things, 1. the layers are already rendered seperatly and 2. the emulator already knows the priority of each layer, or else it wouldn't be displayed correctly to start with.
Really all that needs to be done, even i it is on a per game basis, would be to render one display as-is, then a second with the layers shifted to the side (by different amounts of course). All of which can be don automatically as the emulator already knows which layer is in front, which is second etc. "It's a minor gain for a lot of work" is just a way of saying "I don't want to", which is fair enough.

Yeah but I used to play snes back in the days before HD on a fatty TV and boy was it blurred lol! but you dont have to "blur" in order to stretch.

I understand what you are trying to explain but I dont think that the emulator itself knows what order the layers are placed as it may be a part of each game-engine, I could be wrong here.
But there is also one other problem, there is no way the emulator could automaticaly understand by itself how to set the optimal offset. This has to be done for each game by a human.
Like I said earlied, This could be done by having some kind of "3D config database file" that stores layer offset information for each rom title.
The final problem I could think of is that 3D cant be applied for every game because layers can actually be too complex.
EXAMPLE: TLOZ - A link to the Past. The background layer that shows the ground is actually the same layer the shows the trees and the treecrowns (you can run under those)
So if you elevated link to be higher up than the ground then you would automatically be higher up than the treecrowns aswell and that would look very ugly.

But I guess it would be possible in a game like mario world if you turn the 3d off at the worldmap Because the worldmap uses the same layers in a different way.
And I dont think the emulator could change 3d settings based on game events. That would be cool thou!

 

[McHaggis]

Stretch = blur, blur = ugly. Especially on a low resolution system like the SNES, even more so when there will be only a small amount of stretch. It also seems that I misunderstood your original statement, I assumed that you meant the stretching would be required for the 3D effect to work, not that it could be used to hide some of the edges.

As for what SparroHawc said about it being too much work, I can't see how. SNES9x already allows the user to enable/disable each bg layer, which proves a couple of things, 1. the layers are already rendered separately and 2. the emulator already knows the priority of each layer, or else it wouldn't be displayed correctly to start with.
Really all that needs to be done, even i it is on a per game basis, would be to render one display as-is, then a second with the layers shifted to the side (by different amounts of course). All of which can be don automatically as the emulator already knows which layer is in front, which is second etc. "It's a minor gain for a lot of work" is just a way of saying "I don't want to", which is fair enough.

I was thinking about this a long time ago too, and I thought about the layers dilemma. If someone could come up with a system so that it could be left up to the community to define how the 3D works, then it wouldn't be much work for the developers, they'd only have to implement the engine. So, a basic system might be a config file that defines layer offsets for a particular mode or when a memory offset is at a particular value. A more advanced system could use a scripting engine, like V8 or something (JavaScript is a very easy to learn language), using callbacks and host functions to change the display as and when necessary.

EXAMPLE: TLOZ - A link to the Past. The background layer that shows the ground is actually the same layer the shows the trees and the treecrowns (you can run under those)
So if you elevated link to be higher up than the ground then you would automatically be higher up than the treecrowns aswell and that would look very ugly.

That makes little sense. If the layer for the ground is the same as the layer for the trees, how would Link be able to run behind them?

 

[DaniPoo]

I was thinking about this a long time ago too, and I thought about the layers dilemma. If someone could come up with a system so that it could be left up to the community to define how the 3D works, then it wouldn't be much work for the developers, they'd only have to implement the engine. So, a basic system might be a config file that defines layer offsets for a particular mode or when a memory offset is at a particular value. A more advanced system could use a scripting engine, like V8 or something (JavaScript is a very easy to learn language), using callbacks and host functions to change the display as and when necessary.


That makes little sense. If the layer for the ground is the same as the layer for the trees, how would Link be able to run behind them?

If you dont believe me you should check it out yourself by switching on and of layers within the Snes9x emulator for PC.
I have seen many interesting funktions in layers. You should also take a look at the layers at the first stage of Donkey Kong Country 3
There is a layer there that both acts as the background and the foreground water which you can swim in. Interesting stuff is going on there and I dont know how it works.

 

[spinal_cord]

... If the layer for the ground is the same as the layer for the trees, how would Link be able to run behind them?

Interrupts. The layers can change priority even during rendering the screen (I assume).
Similar to how Mode7 works. 'Mode7' was how games like Mariokart rendered perspective, the scale of the layer was changed on the hblank, so for every scan line, the background could be a different scale, the higher up the screen, the smaller the bg, the lower down the screen the larger the bg.
I would assume that the background in Zelda, would be set behind the sprites if the player is in front of the trees or infront if the player is behind. Although I didn't know that the same layer was used for trees and grass, seems a bit silly when you have 4 layers + sprites to play with.

 

[DaniPoo]

Interrupts. The layers can change priority even during rendering the screen (I assume).
Similar to how Mode7 works. 'Mode7' was how games like Mariokart rendered perspective, the scale of the layer was changed on the hblank, so for every scan line, the background could be a different scale, the higher up the screen, the smaller the bg, the lower down the screen the larger the bg.
I would assume that the background in Zelda, would be set behind the sprites if the player is in front of the trees or infront if the player is behind. Although I didn't know that the same layer was used for trees and grass, seems a bit silly when you have 4 layers + sprites to play with.

Something like that sound about right. But the fun thing is that you could actually be halfway under the treewhile still be over the ground.
Anyway, I think this discussion need its own thread. Anyone wanna have the honor of putting up a thread in the forum about "2D to Stereoscopic 3D"?

 

[McHaggis]

Interrupts. The layers can change priority even during rendering the screen (I assume).
Similar to how Mode7 works. 'Mode7' was how games like Mariokart rendered perspective, the scale of the layer was changed on the hblank, so for every scan line, the background could be a different scale, the higher up the screen, the smaller the bg, the lower down the screen the larger the bg.
I would assume that the background in Zelda, would be set behind the sprites if the player is in front of the trees or infront if the player is behind. Although I didn't know that the same layer was used for trees and grass, seems a bit silly when you have 4 layers + sprites to play with.

I knew how Mode7 worked, but to be honest I've never given SNES development much of a look. Interrupts seem like they would be glitchy: what happens, for instance, when your player is half-in and half-out?

If you dont believe me you should check it out yourself by switching on and of layers within the Snes9x emulator for PC.
I have seen many interesting funktions in layers. You should also take a look at the layers at the first stage of Donkey Kong Country 3
There is a layer there that both acts as the background and the foreground water which you can swim in. Interesting stuff is going on there and I dont know how it works.

I'll take your word for it.

Anyway, I started a thread for you guys. I even put a special video in there for you... get your glasses on.

 

[Anlex]

I do not care much for roms and the like. And homebrew may be interesting, but what I really want to get rid of is the STUPID REGIONLOCK. Let's hope there is a release soon.

 

[Chase-san]

I honestly don't care if 'piracy' is doable or not. I would love to be able to get inside my 3ds and tinker around with some custom programs of my own without going through Nintendo.

 

[Anlex]

I just hope there will be a release before Nintendo manages to fix this and even all the "good" guys are screwed.

 

[pwsincd]

Even nintendo would struggle to fix something before anyone releases a hack, as they don't know what the hack is.

 

[yuuna]

they might have known, iirc someone here said it is like twilight hack.

 

[Maxternal]

they might have known, iirc someone here said it is like twilight hack.

The problem is there are LOTS of ways something can be like the Twilight Hack. It's knowing which game, where in the game and what kind of exploit it uses. There are lots and lots of combinations

 

[yuuna]

true, I was referring to pwsincd's post. let's just wait and see when the upcoming update released if nintendo manage to patch it.