Yeah, I'm just waiting for Luma wiki to update or someone else to figure out and share how to use the new way to use DS(i) scalers.
same im not gonna bother with Python given i am clueless with that sort of stuff.Yeah, I'm just waiting for Luma wiki to update or someone else to figure out and share how to use the new way to use DS(i) scalers.
Should really update OP with this and suggestion of keeping with lower builds to keep using these patches, at least until something changesEveryone, please stop spreading misinformation!
With the release of Luma v13, a lot of people are complaining about a black screen when launching anything in DS(i) mode.
If you think about it, if your patched TwlBg.cxi has worked in previous Luma versions, but the latest one breaks it, then it must be a regression in Luma's code, not in mine.
I'm able to pull the "this is not my fault" card here, as I've been doing these patches in a way where it should also work on a sigpatch-only stock system, so it should really not be my fault:
TWPatcher decompresses TwlBg.cxi, patches the .code section, then re-compresses it in a way, where if the original .firm had its sysmodule section replaced with a TwlBg.cxi patched by TWPatch, then you'd only need signature patches to make it work, meaning that TWPatcher is already as compliant as possible, and always has been.
So please don't spread stuff like "TWPatch uses the old method" or "TWPatch is not compatible with the new method", as there is no such thing as "old method" and "new method". Luma should only patch some things in the kernel and Process9 (sigpatches mostly), and should just load the patched and compressed TwlBg.cxi from the SDCard unharmed. There isn't much other way of doing it without doing some heavy-duty patches to 3 sections out of 4.
If you do find an actual mistake in TWPatch which you think might cause these issues, please ping me in this thread, and I'll look into fixing it, and I'll add a clarification into this post in form of an edit if such thing really ends up happening.
Should really update OP with this and suggestion of keeping with lower builds to keep using these patches, at least until something changes
Fix a v13.0 regression where external FIRM module loading (such as TwlBg) was broken
Please delete "TwlBg.cxi" and re-follow the widescreen guide then.I updated to 13.01 but now everything is Widescreen like the normal Cartridges and Twilightmenu which normally isnt.
It was fixed, tested and confirmed by yours trulyLooks like they fixed it?
https://github.com/LumaTeam/Luma3DS/releases/tag/v13.0.1
I updated Luma and TWLPatch. I created a new TwlBg.cxi with Interpolation 1 because it seemed to look better than the default one, and revert START+SELECT, put it in the correct place for Twilight Menu with the correct name and such...
...But now when I boot certain games like Super Mario 64 DS, I see some corrupted graphics and glitchy upper screen for a few seconds. Is this normal, I am missing something, or something is wrong with Interpolation 1?
Edit: Okay, nope, it also happens with the default one. I wish I did a backup of my old Widescreen.cxi...
Edit: I fortunately found that the previous, 2022 version was here and tried. The cxi file created with that older version does not show any glitch.
I hope this helps somehow to find what could be the issue.
would there be a way to change the Gamma in dsi mode its really washed out in comparison to the screen comparision in TWLPatcher
Don't worry, I just am glad that's not a hard to fix thing!
I remember there being issues with enabling a lot of patches or some simultaneously due to not having enough space. Can this be solved with the new Luma version that supposedly allows arbitrarily sized TWL_FIRM?Everyone, please stop spreading misinformation!
With the release of Luma v13, a lot of people are complaining about a black screen when launching anything in DS(i) mode.
If you think about it, if your patched TwlBg.cxi has worked in previous Luma versions, but the latest one breaks it, then it must be a regression in Luma's code, not in mine.
I'm able to pull the "this is not my fault" card here, as I've been doing these patches in a way where it should also work on a sigpatch-only stock system, so it should really not be my fault:
TWPatcher decompresses TwlBg.cxi, patches the .code section, then re-compresses it in a way, where if the original .firm had its sysmodule section replaced with a TwlBg.cxi patched by TWPatch, then you'd only need signature patches to make it work, meaning that TWPatcher is already as compliant as possible, and always has been.
So please don't spread stuff like "TWPatch uses the old method" or "TWPatch is not compatible with the new method", as there is no such thing as "old method" and "new method". Luma should only patch some things in the kernel and Process9 (sigpatches mostly), and should just load the patched and compressed TwlBg.cxi from the SDCard unharmed. There isn't much other way of doing it without doing some heavy-duty patches to 3 sections out of 4.
If you do find an actual mistake in TWPatch which you think might cause these issues, please ping me in this thread, and I'll look into fixing it, and I'll add a clarification into this post in form of an edit if such thing really ends up happening.
Edit: v13.0.1 fixes the regression, please update to fix the black screen issue!
I remember there being issues with enabling a lot of patches or some simultaneously due to not having enough space. Can this be solved with the new Luma version that supposedly allows arbitrarily sized TWL_FIRM?
I have been looking online and have read through several dozen pages of this thread to no avail.OH, I FORGOT TO DISABLE THE RASTER BARS!
I'll disable them next update, my bad!
Use Redshift patch.
Enable Redshift from the patch menu (Y+B), press Y+B again, press X to reset the settings, and increase gamma for all 3 colors.
It's most likely an overlooked bug during the TwlBg patching process and/or no code space left to retain the Redshift settings.I have been looking online and have read through several dozen pages of this thread to no avail.
I am using Redshift to increase the gamma for DS games in addition to the widescreen patch and am running into the same issue using both TWLMenu and NDS forwarded games on the homescreen. If shut off the screen by closing the lid it seems that the Redshift screen settings will disappear and the gamma values will be back to the stock DS default colors. It will still retain the widescreen patch setting just not the gamma values. It will only retain the values as long as I have the screen open and the only way to bring back the patched Redshift settings is by closing the game completely and relaunching.
In case it's worth noting, I am using the version of Luma with built-in Redshift configuration and on native 3DS games it seems to be retaining the settings just fine so this seems to only be an issue when running in DS mode. Have I set up something incorrectly?
I have been looking online and have read through several dozen pages of this thread to no avail.
I am using Redshift to increase the gamma for DS games in addition to the widescreen patch and am running into the same issue using both TWLMenu and NDS forwarded games on the homescreen. If shut off the screen by closing the lid it seems that the Redshift screen settings will disappear and the gamma values will be back to the stock DS default colors. It will still retain the widescreen patch setting just not the gamma values. It will only retain the values as long as I have the screen open and the only way to bring back the patched Redshift settings is by closing the game completely and relaunching.
In case it's worth noting, I am using the version of Luma with built-in Redshift configuration and on native 3DS games it seems to be retaining the settings just fine so this seems to only be an issue when running in DS mode. Have I set up something incorrectly?
It's most likely an overlooked bug during the TwlBg patching process and/or no code space left to retain the Redshift settings.