No, I will only release the patches separately.
And in case you're wondering, yes, this will also mean that I'll try to support custom patch loading (made by the community), and depending on what patches are enabled, it might be possible for both the DS and TWPatch to apply the same patches as-is, either at runtime, or at patch-time.
I'm currently designing a patch file format, and a new patcher (project name "AutoPatcher", not related to TWPatch yet), and I'll unhardcode the patches, so they can be updated and downloaded separately on the SDCard, if I were to stop supporting TWPatch in the future, and no "open_twl_firm" ever comes out.
So to answer your question, no, I will not release an .nds, but once I'm done with this refactor, anyone could implement the bare minimum to upload and apply patches via rtcom. So this means that TWiLightMenu++ could finally ditch this .cxi copying nonsense, and just apply patches at runtime at will.
I am several years too late, but it would be nice to have a way to set the destination address/offset when uploading code via RTCom. This would allow multiple uploaded patches to coexist and not overwrite each other (if that's even a problem). And the most important thing: when uploading takes too long, audio hardware or software sort of goes out of sync and weird cracking/popping sound distortions start to appear. Maybe chunking the uploading data would help with it.
The code is always uploaded to a fix address due to some limitations I can't overcome without rewriting the entirety of TWL_FIRM / AGB_FIRM.
You could upload a payload uploader, into which you could upload the address as well via the continue opcode to stream data into an offset.
Once you have uploaded everything, you can upload a branch execution payload, into which you could upload the first four bytes of address via the continue opcode, and from the 4th byte you could just stream bytes into the parameters of that function.
If you can think of a better way, please tell me, and I can add modifications.
Note though, that the reason the functionality is so limited is because I'm already very short on instruction space.
Thanks. That's a great idea. I should definitely try that.
And I wanted to ask the last question. Are there any feasible ways to know where Arm11 crashed? I forget what this thing is called, but nds-boostrap, when Arm9 crashes, shows you the values of all registers. I guess the worst case would be to do something with the exception vectors, but maybe something already exists?
There used to be an exception handler (find the leaks of TWPatcher source code, it's almost up-to-date with what I have), but it's broken now, and I can't make it work without a rewrite.
Wow this is amazing. Sadly im a complete noob abaut this stuff. If i download and install the .cia, will it replace Twilight Menu ++? Will i be able to update TM++ normally after installing this patch? Also... how do i install it lol? Do i just have to upload the .cia file to my sd and then install it whit FBI? Sorry for the bad english btw
TWPatch and TWiLight are mostly* unrelated, so they won't affect each other at all
*TWiLight does have special features relating to widescreen, these require special setup to work optimally – that said you can still update TWiLight as normal
Wait, so the filters don't work if you're using TWMenu, or only the widescreen?
If so, Is there any way to get them to work outside of having the physical cart?
Thanks, sorry for the alarmism
makes me wonder if GPU upscaling works since it's a patch instead of a filter
The build i have is from 2021/02/21
Any updates or new versions since then? Twpatch is my favorite homebrew application on my system. Gbu scale is probably the best one, especially if widescreens being used.
Any updates or new versions since then? Twpatch is my favorite homebrew application on my system. Gbu scale is probably the best one, especially if widescreens being used.
I've checked, and the latest build is from 2022.
Not many new updates, other than bugfixes.
Since that version however, no new updates. Still working on the autopatcher, on which progress is almost nonexistant.
I gave up on playing DS games on my 3DS altogether.
I realize this isn't very topical but I had to vent somewhere. As much as I appreciate the massive work that went into making this homebrew possible, I'm convinced the 3DS simply can't pull off any kind of scaling that isn't awful due to its lack of resolution (no integer scaling possible) and lack of power (no xbrz or any fancy interpolation of the sort).
I purchased a second hand DSi XL in what honestly looks like mint condition and couldn't be happier. Should teach me not to sell my handhelds in the future, I've literally sold and repurchased every god damn handheld known to man.
Anyway I love you Sono, this little piece of software at least allowed me to play DS games on my 3DS for a while without having to hold start and crush my thumb every time.
I realize this isn't very topical but I had to vent somewhere. As much as I appreciate the massive work that went into making this homebrew possible, I'm convinced the 3DS simply can't pull off any kind of scaling that isn't awful due to its lack of resolution (no integer scaling possible) and lack of power (no xbrz or any fancy interpolation of the sort).
I purchased a second hand DSi XL in what honestly looks like mint condition and couldn't be happier. Should teach me not to sell my handhelds in the future, I've literally sold and repurchased every god damn handheld known to man.
Anyway I love you Sono, this little piece of software at least allowed me to play DS games on my 3DS for a while without having to hold start and crush my thumb every time.
There are two linear interpolations which should have less sharpening applied than Nintendo. The one I tweaked to my liking has more sharpening than Nintendo however.
You can compare the selected to Nintendo's by holding and releasing X. Holding X makes it show Nintendo's, releasing it shows the selected one.
Actually, the 2nd core could probably pull off CPU upscaling from VRAM, but in my code, not in Nintendo's.
But otherwise yeah, vertical will always suffer due to lack of resolution, but horizontally it's possible to enable 240x800 mode, and have double the horizontal resolution, but sadly for the DS that still won't result in integer scaling :/
Yes, but either TWPatcher, or TwlBg.cxi itself would need to be modified for that.
Damn, I still need to do the user loadable scale matrixes
I guess a matrixes.bin file could try, where you can use an editor GUI to pack user-generated matrixes into matrixes.bin (kind of like usercheats.dat works), and have a separate menu for selecting those matrixes.
Someone could make this tool in Python, and if they do, I'll try to implement my side in TWPatcher to load those matrixes.bin
Similar threads
-
- Locked
-
AncientBoi
-
K3Nv2
-
Xdqwerty
what are you looking at?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
A @ Aglae Pheryl:Is anyone familiar with former forum opg.life ? I missed the transition to the new forum over the week end (was scuba diving in the sticks with no internet connection). If anyone in touch with any members please pm me.
-
-
-
-
-
-
-
-
-
-
(
