That's a decent humble brag. One like from me.No I'm fine with having over 8,000 posts already. Getting the last title at 10,000 posts is not worth this.
That's a decent humble brag. One like from me.No I'm fine with having over 8,000 posts already. Getting the last title at 10,000 posts is not worth this.
In that case, same thing applies.I'm pretty sure they were referring to old mobile Java games.
It can also mean exploiting some part of the boot process, which is more likely to happen. Anyway, the 3DS was supposed to be secure and we still got multiple boot time exploits and eventually were even able to sign our own code to run as if it was signed by Nintendo. No one ever expected that to happen. So it's certainly not impossible. Unlikely, but not impossible. Given how much interest there is in the Switch, if there is a boot time exploit, someone is gonna find it. The Switch is not very secure, they clearly have not learned from their mistakes, and you probably know Nintendo has a history of screwing up security.I think I get where the confusion is coming from. You quoted the wrong post. You meant to reply the post where I stated permanent CFW is impossible. It is impossible. Permanent CFW would be to sign the CFW so it can be installed to the internal NAND without the need for an exploit which is likely to never happen in our lifetimes.
A permanent or untethered coldboot exploit is completely different from permanent CFW because the exploit has nothing to do with CFW except for launching it. You also cannot make the exploit untethered/permanent unless the exploit happens to work like that.
And in case you are wondering why I am stressing the difference, I have already explained the reasoning in my previous post.
I never said an untethered coldboot exploit was impossible. I said a permanent CFW was impossible.It can also mean exploiting some part of the boot process, which is more likely to happen. Anyway, the 3DS was supposed to be secure and we still got multiple boot time exploits and eventually were even able to sign our own code to run as if it was signed by Nintendo. No one ever expected that to happen. So it's certainly not impossible. Unlikely, but not impossible. Given how much interest there is in the Switch, if there is a boot time exploit, someone is gonna find it. The Switch is not very secure, they clearly have not learned from their mistakes, and you probably know Nintendo has a history of screwing up security.
That is what a permanent CFW is though.I never said an untethered coldboot exploit was impossible. I said a permanent CFW was impossible.
I would argue differently as technically you are just rebooting the exploit whenever you turn the console on (especially with trinkets and AutoRCM) but that would just be reduced to a semantic dispute.That is what a permanent CFW is though.
Then you better go look up the definition of "permanent"I would argue differently as technically you are just rebooting the exploit whenever you turn the console on (especially with trinkets and AutoRCM) but that would just be reduced to a semantic dispute.
fat32 isn't perfect. I had small games crash because of corruption. Yeah its less likely to corrupt but it does. Sadly the only way i want a game to work without crash is installing to the nand. If only the nand size for emuand on sx os can be increasedfat32 works fine on high capacity micro SD cards . exFat corruption isn't ever going away unless Nintendo fixes their exFat driver (which I doubt will happen since they literally have no reason to do so) or somebody reimplements FS
It's closed source, so the only people you can ask for that are the original devs.Proper PSX emulation, please a port of ePSXe the only one emulator that can run my precious Tomba 2! The right way.
That would be coolIt's closed source, so the only people you can ask for that are the original devs.
I don't think I have many grand wishes at the moment. I need to get around to getting my chip fitted, so then I'll have untethered coldboot. I'm happy we now have the ability to use docked clocks in handheld mode, as I almost always play handheld plugged in, but for games that vary what they actually display between docked and handheld, it could be nice to have a patch/module that tells games it's docked when it's not.
That would cause the games to try to push 1080p, not sure if that would scale automatically or what would happen, it might require more patches in order to scale it. But games would look more blurry due to non integer scaling and some text might be harder to read.It's closed source, so the only people you can ask for that are the original devs.
I don't think I have many grand wishes at the moment. I need to get around to getting my chip fitted, so then I'll have untethered coldboot. I'm happy we now have the ability to use docked clocks in handheld mode, as I almost always play handheld plugged in, but for games that vary what they actually display between docked and handheld, it could be nice to have a patch/module that tells games it's docked when it's not.
The relatively high chance of people randomly having their memory cards corrupt isn't reason enough to fix it? Sure, saves aren't stored on the MicroSD, but it can still be a big problem for those with slow internet or limited bandwidth.Yea, initial mariko support was added in 5.x, so I also heavily doubt they'll be on 4.x
I'd be very surprised if Mariko shit was even in devkit stuff right now
--------------------- MERGED ---------------------------
fat32 works fine on high capacity micro SD cards . exFat corruption isn't ever going away unless Nintendo fixes their exFat driver (which I doubt will happen since they literally have no reason to do so) or somebody reimplements FS
Ah good point, hadn't thought about the resolution difference. There probably aren't even that many games where it's relevant, so maybe per-game patching would work better.That would cause the games to try to push 1080p, not sure if that would scale automatically or what would happen, it might require more patches in order to scale it. But games would look more blurry due to non integer scaling and some text might be harder to read.
The corruption doesn't happen when doing official/non-homebrew stuff, it only happens with unofficial homebrew stuffThe relatively high chance of people randomly having their memory cards corrupt isn't reason enough to fix it? Sure, saves aren't stored on the MicroSD, but it can still be a big problem for those with slow internet or limited bandwidth.
Maybe. On that small and sharp screen you might not even notice the extra blurriness so it could work out actually.Ah good point, hadn't thought about the resolution difference. There probably aren't even that many games where it's relevant, so maybe per-game patching would work better.
That doesn't make sense, if it's a problem with Nintendo's exFAT implementation it should be happening regardless.The corruption doesn't happen when doing official/non-homebrew stuff, it only happens with unofficial homebrew stuff
That option doesn't change the resolution that games render at.I guess you could set the HDMI output to 720p actually. That would work and you wouldn't get the lag that some games suffer from in 1080p.
I'm sure people said it improved their FPS in BotWThat option doesn't change the resolution that games render at.
it didn'tI'm sure people said it improved their FPS in BotW
halfBut the exploit has nothing to do with the CFW
Open rollercoaster Tycoon 2 port
Android for San Andreas
Goldeneye full speed emulation
That isn't what I meant. An exploit and CFW are developed and found independently of each other. Fail0verflow and Ktemkin discovered the Fusee Gelee/shofel2 exploit while SciresM is developing Atmosphere. Any exploit can be used to load any CFW and vice-versa. The CFW is only dependent on an exploit being discovered but after that, they are completely different things.half
Its a method to load a secondary CFW.
ah okThat isn't what I meant. An exploit and CFW are developed and found independently of each other. Fail0verflow and Ktemkin discovered the Fusee Gelee/shofel2 exploit while SciresM is developing Atmosphere. Any exploit can be used to load any CFW and vice-versa. The CFW is only dependent on an exploit being discovered but after that, they are completely different things.