Hacking Lost Super Stable 3d

[cearp]

Super stable 3D works just fine in emunand as long as i've closed the lid and reopened it

that rumour about "frying" the screen sounds fake as hell

you can test, leave your 3ds on for a few hours, full 3d, without doing the 'fix'

 

[Deleted member 333767]

I found the original post where i heard that theory about the glitched 3D effect after entering emuNAND

I think this is merely a byproduct of 3D mode not working until you sleep the console in emunand mode. The brightness level of 3D before you sleep it is too bright, much brighter than maximum brightness on sysnand. My personal speculation is that this is because the system ups the voltage to the screen to enable the parallax barriers, but since the services governing the barriers don't go into effect until you sleep the system, the top screen effectively runs on overdrive.

Needless to say it is very, very bad to enable 3D on the top screen before you sleep it, as I'm nearly sure you risk burning out your screen.

 

[Deleted-19228]

LCD burn-in. Nothing new.

 

[Typhin]

After I installed the the MSET exploit, I've lost Super Stable 3d on on my N3ds. It's still present in classic mode, but once I get into emunand it fucks up. Anyone know how to fix this?

I've tried using the OOT exploit but it still fucks up for some reason.

It's possible you might have installed the MSET exploit to your emuNand instead of your sysNand. The instructions are not as clear as they should be, so you would not be the first to make that mistake. When preparing to install MSET, did you hold B before pressing A, so the text changed to "BOOT GATEWAY SYSNAND MODE"? The MSET contains an altered version of the System Settings app, so after installing, you shouldn't have an option for Super Stable 3D on sysNand. (The settings are still saved, but the menu button to access them is gone, and the version of System Settings in emuNand should still have the button and settings.)

I haven't done it myself, but there should be guides on how to grab a newer version of the System Settings app and install it into your emuNand to restore that button (or you can just restore from backup if you have made one recently). And since I don't own a new 3DS, I'm afraid I have no information on the "fuzzy screen" issue, or the feature at all, other than what I've seen in other threads.

 

[Allied]

I found the original post where i heard that theory about the glitched 3D effect after entering emuNAND

Who say's it's brighter? Not that I've noticed. They probably have auto-brightness (which is just terrible - stationary, in a constantly lit room and it goes dark bright dark bright..... darrrrk... pause... bright) on in Sys and off in Emu or something.

 

[CIAwesome526]

It's possible you might have installed the MSET exploit to your emuNand instead of your sysNand. The instructions are not as clear as they should be, so you would not be the first to make that mistake. When preparing to install MSET, did you hold B before pressing A, so the text changed to "BOOT GATEWAY SYSNAND MODE"? The MSET contains an altered version of the System Settings app, so after installing, you shouldn't have an option for Super Stable 3D on sysNand. (The settings are still saved, but the menu button to access them is gone, and the version of System Settings in emuNand should still have the button and settings.)

I haven't done it myself, but there should be guides on how to grab a newer version of the System Settings app and install it into your emuNand to restore that button (or you can just restore from backup if you have made one recently). And since I don't own a new 3DS, I'm afraid I have no information on the "fuzzy screen" issue, or the feature at all, other than what I've seen in other threads.

Sounds like a good explanation...

 

[KingOfHell]

I could have sworn I read that it was an issue with the head tracking service (QTM) in which closing the lid and re-opening it fixed the service. I forgot to fix it once, and Majora's Mask looked like I was playing it on an o3ds...

 

[tony_2018]

Thank you Apache Thunder for clearing that up. it wasn't my intention to scare monger, but just something I read in another thread

Which would be?

 

[WulfyStylez]

For the record, nothing dangerous happens when you're in that messed up 3D mode. The system's state for head-tracking is just partially messed up on boot, and doesn't get fixed by QTM until it's forced to suspend and re-init. The observation of some sort of overvoltage likely comes from someone noticing the screen gets brighter, which is something that usually happens when the 3D is turned on (though you don't notice since the parallax barrier is working in that case.)

It's... kind of a really simple bug to fix though? (We did around the time they released their N3DS support, if anyone remembers.) GW kinda rushed their New3DS release, and they're probably too busy with 9.6+ stuff to go back and fix that at the moment.

 

[hippy dave]

It wouldn't actually hurt you or your project to post how to fix it, just a thought.

 

[Deleted member 333767]

Which would be?

-> Here <-

It's just some users theory, which i thought might be relevant to this thread.

 

[WulfyStylez]

It wouldn't actually hurt you or your project to post how to fix it, just a thought.

I totally would, but it's not a thing users can fix on their end. Gateway needs to fix their launcher to get rid of the bug.

 

[tony_2018]

-> Here <-

It's just some users theory, which i thought might be relevant to this thread.

OH.....users theory...... null

 

[The Real Jdbye]

LCD burn-in. Nothing new.

Regular LCDs don't normally have a problem with burn-in. AMOLED however is a different matter.

 

[hippy dave]

I totally would, but it's not a thing users can fix on their end. Gateway needs to fix their launcher to get rid of the bug.

I know, I understand that. But gateway also read the forum and are quick to implement things when the work has been done for them.

 

[CreativeMan]

For the record, nothing dangerous happens when you're in that messed up 3D mode. The system's state for head-tracking is just partially messed up on boot, and doesn't get fixed by QTM until it's forced to suspend and re-init. The observation of some sort of overvoltage likely comes from someone noticing the screen gets brighter, which is something that usually happens when the 3D is turned on (though you don't notice since the parallax barrier is working in that case.)

It's... kind of a really simple bug to fix though? (We did around the time they released their N3DS support, if anyone remembers.) GW kinda rushed their New3DS release, and they're probably too busy with 9.6+ stuff to go back and fix that at the moment.

I'm digging that topic... It seems nobody as of today found a fix for the SS3D bug, but the SALT team ?

 

[WulfyStylez]

This is something fixed by writing good code that assumes nothing about the state of the system at payload runtime. We completely sanitize the state of the GPU and screen by always de-initializing the screen, resetting the GPU, and re-initializing the screen, framebufs, etc. On exit, you also properly need to properly take the screen down in the same way GSP would.
The best payload code for running on bare metal must make absolutely no assumptions about system configuration.

 

[EmuAGR]

Regular LCDs don't normally have a problem with burn-in. AMOLED however is a different matter.

I've been using Samsung Galaxy S mobile phone family since my first smartphone. I also own a PSV. Neither of the screens has signs of burn-in.

For that to happen you have to leave a static screen for days. Normal usage won't damage the screen at all.

 

[mungry]

This is something fixed by writing good code that assumes nothing about the state of the system at payload runtime. We completely sanitize the state of the GPU and screen by always de-initializing the screen, resetting the GPU, and re-initializing the screen, framebufs, etc. On exit, you also properly need to properly take the screen down in the same way GSP would.
The best payload code for running on bare metal must make absolutely no assumptions about system configuration.

I don't understand this, so is this enough information for a CFW dev to implement a fix now?

 

[SirByte]

Cool. When the SuperStable3D fix shows up in CFWs with source code, we'll see it in GW next update as well! *ducks*