I just noticed that I forgot to push the rtcom patches, and nobody has yet complained about it
So here is the commit if you're interested.
Well anyways, I attached a temporary patcher, both 32bit and 64bit builds are included (use the 64bit one first as the 32bit build is buggy!).
The default settings are fine (no parameters passed to the exe), but if you insist on using bit bitmasks, then use 1000000
If you know how to develop for DS and want to try out rtcom yourself, then check out @Gericom 's Rtc3DS, and start tinkering with it (the best way to learn), read the internal source code, and see what you can come up with!
If you know how to develop for 3DS (userland), but don't want to do too much with the DS side, then I suggest waiting for RTCode (empty at the time of writing), my rtcom payload uploader DS homebrew, which is what I'll be personally using to make the DS-side equivalent of TWPatch.
Not sure about the fate of the cia patcher though, I need some input on it. Please see the newly added poll!
There is a tl;dr block below this huge wall of text if this looks frightening, but if you read the big wall of text, please read both!
Explainations on the possible votes (in order):
tl;dr:
Please vote on the poll!
So here is the commit if you're interested.
Well anyways, I attached a temporary patcher, both 32bit and 64bit builds are included (use the 64bit one first as the 32bit build is buggy!).
The default settings are fine (no parameters passed to the exe), but if you insist on using bit bitmasks, then use 1000000
If you know how to develop for DS and want to try out rtcom yourself, then check out @Gericom 's Rtc3DS, and start tinkering with it (the best way to learn), read the internal source code, and see what you can come up with!
If you know how to develop for 3DS (userland), but don't want to do too much with the DS side, then I suggest waiting for RTCode (empty at the time of writing), my rtcom payload uploader DS homebrew, which is what I'll be personally using to make the DS-side equivalent of TWPatch.
Not sure about the fate of the cia patcher though, I need some input on it. Please see the newly added poll!
There is a tl;dr block below this huge wall of text if this looks frightening, but if you read the big wall of text, please read both!
Explainations on the possible votes (in order):
- No change in plans, implement redshift, filters, and now rtcom patching
The problem with this one is that it takes a ridiculous amount of time to develop due to having to (re)make the UI for it. People have been waiting for MONTHS by now, and there is still barely any extra progress (there is indeed a little bit of progress, but all of it is uncommitted). And considering that I have a job now, taking this route is unfeasible, unless everyone wants to wait years until I can finish it, at which point probably nobody will care anymore.
HOWEVER! I'm open to suggestions on how I could speed up the development process
- Only redshift and rtcom
I can kinda do this one somewhat faster, because I can just take CTR_Redshift, make its UI work in TWPatcher, and the rtcom patching is just a few lines of code (shared codebase between the exe and the cia patcher, yay).
HOWEVER! This would mean that for scale filtering you'd need to use TWiLightMenu++ to launch a legit game cart too if you want to use scale filtering, which is a bit ridiculous.
Perhaps I could think of something else later, but this doesn't sound like a good middle ground to me, at all. Just putting this here in case others think otherwise.
- Only rtcom, the rest is DS-side
This should be the easiest one. Though if you think about it a little bit more, you may be saying "but you'll still have to make TWPatch anyways, why not just make it for the 3DS?", and you have a point there.
BUT! The reason doing this 3DS-side is more difficult is due to the space constraints inside TwlBg. I have to get really creative with how I store the patches inside it, otherwise I break sleep mode, or I just can't fit my code in AT ALL (booting will simply just fail on a black or white screen). Whereas at the DS side, I can just include the full patches inside the nds, upload the patches through rtcom to a dedicated volatile memory, apply them, and the result is the same as if I could fit all of this in the 3DS build in the first case.
Another upside is that patches can be applied WITHOUT WAITING 6 WHOLE MINUTES! You can INSTANTLY see the changes you have made. No more waithax!
HOWEVER! You'll be tied to some kind of chainloader which can apply these patches, and continue booting the game. The only downside of this are flashcarts, and original gamecart compatibility. While you can run the nds patcher on your flashcart, original gamecarts still require a chainloader.
tl;dr:
- Just finish TWPatch already!
It takes too much time. Though please suggest if you know how I could speed up the development process! - Just only do redshift and rtcom in TWPatch, move the rest to DS side
This should be somewhat faster, but you'll be tied to a chainloader for widescreen and scale filtering, which can have compatibility issues. - All-in DS-side patching, just make a patcher which spits out a magic TwlBg.cxi for me! I'm sick of the exe patcher!
This is the fastest to implement, even though I still need to remake TWPatch entirely on the DS-side. You'll be DEFINITELY tied to a chainloader, unless you can run RTCode on your flashcart. Original gamecarts still require a chainloader though.
Please vote on the poll!