Hacking Unofficial Luma build discussion

  • Thread starter Thread starter Nutez
  • Start date Start date
  • Views Views 66,311
  • Replies Replies 252
  • Likes Likes 12
You can open the flashcard without reinserting it via TWiLightMenu++, or using this app (https://gbatemp.net/threads/twl-slot-1-launcher-first-custom-dsiware-app.414501/). Just open the app and it'll boot.
Apparently, my 3DS has to be TWL_FIRM patched and I don't desire to do so. Out of simple personal reasons. So the app doesn't really works for me. :/
 
Apparently, my 3DS has to be TWL_FIRM patched and I don't desire to do so. Out of simple personal reasons. So the app doesn't really works for me. :/

na you do not need to patch anything... just install the TWLSlot1LauncherV3.cia and you can launch your flashcard with it... works flawlessly for me.
 
github/iSharingan/CTRPF-AR-CHEAT-CODES/blob/master/Luma3DS%209.1%20-%20Plugin%20Loader.7z
Would it be possible for you to include .plg support?
This one is 9.1 so I havent tried it; however, it'd be awesome if this would work!

new to GBAtemp, cant use links
 
Last edited by Ryu_Okami,
New update:
Permanent brightness recalibration

Hello.
Thank you so much for ur builds, my body never felt so ready like this before, works like a charm.

I just got two stupid questions:
"over bright at your own risk" what kind of risk are we are talking about? radiation/nuclear or could be worse like burn my screen?

My brightness settings from rosalina resets to default evertyme i reboot the 3ds, its that a bug?

thanks sir.
So I've reworded the descriptions to be more clear. 172 is the upper limit that exists in code, so it's presumably safe to use but maybe it will reduce the lifespan of the LCDs in the long term. There are some rare (and seemingly unavoidable) glitches with low brightness settings that can actually cause levels to spike above 172. These are the potentially dangerous levels that people should avoid using.

Your query inspired me to have a look into the brightness defaults and it seems that we can edit them in NAND so that they will be applied even after reboot. I split this functionality out into a new interface for space and because I don't want people to recalibrate frequently.

github/iSharingan/CTRPF-AR-CHEAT-CODES/blob/master/Luma3DS%209.1%20-%20Plugin%20Loader.7z
Would it be possible for you to include .plg support?
This one is 9.1 so I havent tried it; however, it'd be awesome if this would work!

new to GBAtemp, cant use links
I did originally try to merge that old .plg loader in with the .3gx but it was an absolute nightmare that I couldn't get working. I gave up when I realised that the .plg loader doesn't actually support all .plg plugins and it is particularly unstable when compared with the .3gx loader. So I just use BootNTR Selector for full .plg plugin support as that is still updated.
 
Last edited by Nutez,
Is permanent brightness recalibration possible for different screens? as it is already done by the brightness editor.
 
Is permanent brightness recalibration possible for different screens? as it is already done by the brightness editor.
No, unfortunately not, since there is only a single config block that is applied for both screens. Well, actually, it probably could be done by screwing with the coeffs to change the brightness curves used by the top and bottom screen individually. But I'm going to keep that out of scope here, because of the "danger" of people permanently desynchronising the calibration of their screens and the hassle of trying to resynchronise accurately.
 
  • Like
Reactions: BETA215
There's been quite a few times Ive been playing online and wanted to glance at the time, but either a separate clock is out of view, and/or my 3ds wont go home, at least not without disconnecting.

So, would it be possible to include a clock in rosalina, perhaps using the internal RTC?

Also, though Idk if Universal-Team may wish to add this to Universal-db, are you considering adding releases to GitHub?

(sent from my N2dsXl running this Luma build)
 
Last edited by Ryu_Okami,
Additionally, would it be possible to add the "nullify user RTC changes" and "dump dsp_firm" options from the nightly official Luma?

finally, a bug: while debug is enabled, Volume: xx% is displayed as "1Volume: xx%" also, the battery/volume info flicker...

I hope my suggestions are helpful, thank you for all the features you've already implemented.

(sent from my n3dsXl running nightly official Luma)
 
New update:
Permanent brightness recalibration




Your query inspired me to have a look into the brightness defaults and it seems that we can edit them in NAND so that they will be applied even after reboot. I split this functionality out into a new interface for space and because I don't want people to recalibrate frequently.

best part about this to me is it also effects ds/gba mode which I always found to be too dark
 
  • Like
Reactions: Nutez
best part about this to me is it also effects ds/gba mode which I always found to be too dark
That's epic! I didn't even realise that it would work in ds/gba mode :lol:. Thanks for letting me know. A new selling point and now I can comfortably play all VC injects in the pitch black.

Additionally, would it be possible to add the "nullify user RTC changes" and "dump dsp_firm" options from the nightly official Luma?

finally, a bug: while debug is enabled, Volume: xx% is displayed as "1Volume: xx%" also, the battery/volume info flicker...

I hope my suggestions are helpful, thank you for all the features you've already implemented.

(sent from my n3dsXl running nightly official Luma)
So the official Luma branch now uses an updated version of the 3ds homebrew library to allow their new SD card speed features to work. I was going to wait until these were officially released before merging them in, but I'll see if I have time to do that earlier.

I'm guessing that in debug enabled mode it is trying to print some text in the same location as I chose to display the volume. Any ideas on where to relocate the texts?

Yeah the flicker is a pain, but I'm not sure how to get rid of it. You can see the same issue on other screens such as the new software volume and brightness recalibration... The problem is with how to handle information that you want to update quickly and repeatedly. You can either clear the whole frame (like I do with software volume and brightness recalibration) or periodically write blanks over a position (like is done for the battery info). Both seem to cause a bit of flicker... Otherwise you end up with info writing over itself (like the debug mode volume display issue). An example would be, going from a value of "10" to "9" gets displayed as "90". Hopefully though, this is just me being a noob and maybe by describing the problem here some smarter mind could solve the problem for me :D.

There's been quite a few times Ive been playing online and wanted to glance at the time, but either a separate clock is out of view, and/or my 3ds wont go home, at least not without disconnecting.

So, would it be possible to include a clock in rosalina, perhaps using the internal RTC?

Also, though Idk if Universal-Team may wish to add this to Universal-db, are you considering adding releases to GitHub?

(sent from my N2dsXl running this Luma build)
Yeah that could be a feature but I think trying to update a clock display in real time would cause lots of flicker as mentioned above...

Potentially, I started tinkering with this before I used GitHub so I'm just in the habit of "releasing" here. Though, I kind of like how it is a GBATemp "exclusive" for now, because it is more fun to interact with people on here.
 
Hello, I been using your Luma build for a while and I really like it. I have a question, before using your build I using the tool for the volume. I'm wondering is there a way to save the volume level ? so when I close the console and re-open it's already at that level ? that's not a big deal but I was just wondering Hehe.

thank you ヾ(。・ω・)ノ
 
  • Like
Reactions: Nutez
Hello, I been using your Luma build for a while and I really like it. I have a question, before using your build I using the tool for the volume. I'm wondering is there a way to save the volume level ? so when I close the console and re-open it's already at that level ? that's not a big deal but I was just wondering Hehe.

thank you ヾ(。・ω・)ノ
Hi, sorry for the delayed response. Thanks for the kind words on the build.

Do you mean reapplying a volume change similar to how the screen filters are reapplied upon reopening? I should be able to get that to work. Thanks for the idea.
 
  • Like
Reactions: EvilFear
Hi, sorry for the delayed response. Thanks for the kind words on the build.

Do you mean reapplying a volume change similar to how the screen filters are reapplied upon reopening? I should be able to get that to work. Thanks for the idea.

yes that's exactly what I was saying and nice !!
 
I was wondering, with permanent brightness control, could you set a button to restore the values to default?

I've already checked, and even though the changes were written to NAND, there seems to be no problems while running Native_Firm. (Meaning seemingly no brick risk if cfw was removed)

Though this isn't exactly a vital feature to prevent bricking, I would still love to see it in a future release
 
I was wondering, with permanent brightness control, could you set a button to restore the values to default?

I've already checked, and even though the changes were written to NAND, there seems to be no problems while running Native_Firm. (Meaning seemingly no brick risk if cfw was removed)

Though this isn't exactly a vital feature to prevent bricking, I would still love to see it in a future release

I don't remember if these values are stored in HWCAL (factory callibration files), but I do know that there are default values hardcoded into either cfg (config manager sysmodule) or gsp (graphics server process, responsible for turning on the GPU, managing LCD power and brightness, and managing the GPU between games, but it's NOT a graphics driver), meaning there will be always a default value to restore to, so it's not necessary to back up the default values, as they already come with your 3DS.

However when you initialize a 3DS from a factory state (either by formatting it or unboxing it), the aftermentioned settings do get copied over to the global configuration. The brightness level adjustment changer does the same thing, it edits the global configuration in a way where it's done via Nintendo's built-in mechanism, meaning that you could not only do this on an unmodded 3DS (if you could get privileged access to the config), but it is completely safe, and persists until you format the 3DS, meaning you won't even have to worry about restoring it if you intend to ever sell the 3DS.
 
Last edited by Sono,
  • Like
Reactions: Nutez
I Love You. I have replaced my new 2DS upper screen for an screen bought on AliExpress, but it looks less brighter than the bottom screen, it was anoying. but now i can adjust every screen to a different level of brightness.
 
yes that's exactly what I was saying and nice !!
I was testing the software volume feature out again and the volume adjustment is actually maintained through sleep mode already (on o3DS and n3DS). So could you maybe explain in more detail if you are experiencing different behaviour? The only issue I noticed was that in order to set 0 volume you need to adjust the volume up first, then back down. I should probably fix that by having the starting volume the same as the current though.
 
I was testing the software volume feature out again and the volume adjustment is actually maintained through sleep mode already (on o3DS and n3DS). So could you maybe explain in more detail if you are experiencing different behaviour? The only issue I noticed was that in order to set 0 volume you need to adjust the volume up first, then back down. I should probably fix that by having the starting volume the same as the current though.

You can disable volume slider by setting min to FF and max to 00. I documented this behavior on 3dbrew as well (see regs 58h and 59h).
 
Perhaps you can implement a "quick mute" button on the volume menu?

Also, idk if its possible, but if you needed more space on the main Rosalina menu, perhaps you could move debug info and possibly process-list into the debugger options sub-menu?
 
  • Like
Reactions: jeffyTheHomebrewer
Perhaps you can implement a "quick mute" button on the volume menu?

Also, idk if its possible, but if you needed more space on the main Rosalina menu, perhaps you could move debug info and possibly process-list into the debugger options sub-menu?
What I think would be a better option is a quick mute button combo, something like [L]+DOWN+(X)
 

Site & Scene News

Popular threads in this forum