Homebrew TWPatcher - DS(i) mode screen filters and patches

[Sono]

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):

• 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!

 

[iGom]

I've waited for it

Sent from my SM-N960F using Tapatalk

 

[Rahkeesh]

Twilightmenu is so damn good now that I don't think forcing people to use it is such a burden. Particularly if its between that and never coming out. Also even if you somehow cram everything you're working on now into TwlBg you probably won' t have room to consider additional features later.

The other thing that's not clear to me is the need to use an .exe patcher. Having to extract stuff with gm9 and then maybe 3dstool severely limits your audience compared to a one-stop homebrew application. I think you should strive to avoid that kind of thing in your final product, there's way more people you would be missing out on than original cart purists.

 

[Sono]

Twilightmenu is so damn good now that I don't think forcing people to use it is such a burden. Particularly if its between that and never coming out. Also even if you somehow cram everything you're working on now into TwlBg you probably won' t have room to consider additional features later.

That's good to know

The other thing that's not clear to me is the need to use an .exe patcher. Having to extract stuff with gm9 and then maybe 3dstool severely limits your audience compared to a one-stop homebrew application. I think you should strive to avoid that kind of thing in your final product, there's way more people you would be missing out on than original cart purists.

I release the exe patchers because of TWPatch's extremely slow progress, and some people are willing to do the ridiculous dumping steps, get a PC, and use a patcher to try out the new features. I just have no other idea to release the new features without having to wait a lot of time until I can finish TWPatch

 

[iGom]

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):

• 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!

GBARunner2 with gyro support freezes on white screen with this patch :/

Sent from my SM-N960F using Tapatalk

 

[RocketRobz]

GBARunner2 with gyro support freezes on white screen with this patch :/

Sent from my SM-N960F using Tapatalk

That happens sometimes. Try again.

 

[iGom]

Actually no luck o both consoles

Sent from my SM-N960F using Tapatalk

 

[ghjfdtg]

I don't think you should let end users decide how and where stuff is implemented or at least give the poll less weight. The reason is because end users often don't see the work behind it and what would work out best from a dev perspective.

 

[Sono]

Actually no luck o both consoles

Press HOME Button:

• if it works, rtcom is not installed
• if it doesn't work (no response to HOME Button being pressed) then there is an incompatibility between the rtcom I pushed, and the one GBARunner2 uses

If it doesn't work, then sadly you'll have to wait for a newer version of rtcom which has this issue already fixed.
I'm an idiot, and accidently used the latest debug addresses instead of the older - now incompatible - addresses used by GBARunner2. I have attached a 64bit patcher ONLY for the latest public release GBARunner2. New payloads should use the new features.

Spoiler: Technical explaination

GBARunner2's ARM11 code is not linked as position independent code (which means that it can only run from a fixed place without crashing), and that's the source of the crash.

During rtcom's development, the address has changed THREE TIMES, during which GBARunner2 used an older address to link against, 201000h. Since I found a fix for the sleep mode crash (although not the cause, sadly), the patcher I included above accidently uses the new address, 131000h.

tl;dr for the above spoiler: the ARM11 payload included in GBARunner2 is too old, so I had to attach a downgraded patcher.

I don't think you should let end users decide how and where stuff is implemented or at least give the poll less weight. The reason is because end users often don't see the work behind it and what would work out best from a dev perspective.

Yeah, I'm using the poll only to try to offset my bias towards the "DS-side patches" route, and to see what the people want.

However, if the bias will be really high towards the 3DS-side patcher, then I'll have to sadly start removing functionality from it in order to fit more important ones in, just as a last resort, to speed up development time.

 

[Rahkeesh]

Not sure which of these plans enables it but I think per-game scaling settings or setting in-game on-the-fly would be very nice features that probably require something like twilightmenu. Widescreen alone is something that many would only want enabled for 3D games with widescreen hacks, plus I find myself wanting smoothing scaling for said 3D games but sharper for 2D, and there's no way a lone cxi file can switch itself like that. (right?) I would just make sure there's a readily available version of the current CIA patcher that spits out dumb cxi files (scale filters in original aspect) for DS card / GBA VC purposes, and then full steam ahead on twilightmenu / gbarunner2 integration for the advanced stuff.

 

[Sono]

Not sure which of these plans enables it but I think per-game scaling settings or setting in-game on-the-fly would be very nice features that probably require something like twilightmenu. Widescreen alone is something that many would only want enabled for 3D games with widescreen hacks, plus I find myself wanting smoothing scaling for said 3D games but sharper for 2D, and there's no way a lone cxi file can switch itself like that. (right?) I would just make sure there's a readily available version of the current CIA patcher that spits out dumb cxi files (scale filters in original aspect) for DS card / GBA VC purposes, and then full steam ahead on twilightmenu / gbarunner2 integration for the advanced stuff.

Per-game scaling can only be done DS-side. Any patches done 3DS-side are static, and can't be changed without uploading extra code to alter these patches.

There is not enough space to include a pattern changer. I can't even fit in a second pattern on the X axis for widescreen patches, let alone switching between multiple on the fly.

Also, thanks for the idea! I guess that would work that I don't actually finish the patch selector OR CTR_Redshift, but I just make you hold a key before pressing START to enable a hardcoded CTR_Redshift, hold another key to disable rtcom patching, and that'll be the 3DS-side. I hope that's what you meant.

As for *native* GBA VC, sadly that has no rtcom support yet, but even if it had, the games would have to be patched, or it would have to go ARM11 --> ARM9 --> ARM7, which we don't know if is even possible without hardlocking the entire system when poking a running ARM7 core.

 

[emcintosh]

Widescreen alone is something that many would only want enabled for 3D games with widescreen hacks, plus I find myself wanting smoothing scaling for said 3D games but sharper for 2D, and there's no way a lone cxi file can switch itself like that.

I keep both the Crisp and Widescreen cxi files in the luma/sysmodules folder and switch between them by renaming the one I want to use as TwlBg.cxi. I've just installed 3DShell to do this from the console itself rather than removing the SD card or using the n3DS microSD management to access from a computer.

I like having save-states, so use a DSTwo for NDS (locking me out of toggling widescreen with Twilight Menu++), and mGBA for GBA / GameYob for GB(C), which have their own scaling.

 

[Sono]

I keep both the Crisp and Widescreen cxi files in the luma/sysmodules folder and switch between them by renaming the one I want to use as TwlBg.cxi. I've just installed 3DShell to do this from the console itself rather than removing the SD card or using the n3DS microSD management to access from a computer.

I like having save-states, so use a DSTwo for NDS (locking me out of toggling widescreen with Twilight Menu++), and mGBA for GBA / GameYob for GB(C), which have their own scaling.

First, use CTRX (CTRExplorer, I think is the full name) to rename your files, or G9 also works if you're okay with rebooting 3 times (3DS --> G9 --> 3DS --> DS mode).
Edit: I didn't notice you can do this from the console, I read it as that you're still using SD management

Second, does your flashcart support return-from-homebrew? If it supports return-from-homebrew then it might be possible to use RTCode to upload ARM11 payloads to alter the filtering, return to the flashcart's menu, and launch a game from there.

 

[emcintosh]

Does your flashcart support return-from-homebrew? If it supports return-from-homebrew then it might be possible to use RTCode to upload ARM11 payloads to alter the filtering, return to the flashcart's menu, and launch a game from there.

I have a SuperCard DSTwo, which has an additional CPU it uses to do real-time saves, improved emulation (which is obsolete now I have a 3DS) and drain the battery while in sleep mode : p. It's possible to exit from a game to the flashcart menu - is this the same as return-from-homebrew?

 

[Sono]

I have a SuperCard DSTwo, which has an additional CPU it uses to do real-time saves, improved emulation (which is obsolete now I have a 3DS) and drain the battery while in sleep mode : p. It's possible to exit from a game to the flashcart menu - is this the same as return-from-homebrew?

If you can return from a GAME to the flashcart menu, then it most likely also has return-from-homebrew (which is not the same, but it's similar). Good, that means that you could copy RTCode.nds and ARM11 payloads to your flashcart, and apply patches using that. I'm working on it right now.

 

[Rahkeesh]

Also, thanks for the idea! I guess that would work that I don't actually finish the patch selector OR CTR_Redshift, but I just make you hold a key before pressing START to enable a hardcoded CTR_Redshift, hold another key to disable rtcom patching, and that'll be the 3DS-side. I hope that's what you meant.

Its not but whatever works. I just thought you could throw whatever quick bones you can to people/applications that Twilightmenu would leave out, so its not entirely an either/or situation.

 

[Gericom]

Press HOME Button:

• if it works, rtcom is not installed
• if it doesn't work (no response to HOME Button being pressed) then there is an incompatibility between the rtcom I pushed, and the one GBARunner2 uses

If it doesn't work, then sadly you'll have to wait for a newer version of rtcom which has this issue already fixed.
I'm an idiot, and accidently used the latest debug addresses instead of the older - now incompatible - addresses used by GBARunner2. I have attached a 64bit patcher ONLY for the latest public release GBARunner2. New payloads should use the new features.

Spoiler: Technical explaination

GBARunner2's ARM11 code is not linked as position independent code (which means that it can only run from a fixed place without crashing), and that's the source of the crash.

During rtcom's development, the address has changed THREE TIMES, during which GBARunner2 used an older address to link against, 201000h. Since I found a fix for the sleep mode crash (although not the cause, sadly), the patcher I included above accidently uses the new address, 131000h.

tl;dr for the above spoiler: the ARM11 payload included in GBARunner2 is too old, so I had to attach a downgraded patcher.



Yeah, I'm using the poll only to try to offset my bias towards the "DS-side patches" route, and to see what the people want.

However, if the bias will be really high towards the 3DS-side patcher, then I'll have to sadly start removing functionality from it in order to fit more important ones in, just as a last resort, to speed up development time.

You didn't tell me about this breaking change . I'll try to update it soon.

 

[Sono]

You didn't tell me about this breaking change . I'll try to update it soon.

Sorry xD I was still experimenting with it as uncommitted changes, so it was probably never going to end up in production if I decided to not muck around with address changes. Buuut I accidently uploaded those changes in the patcher, hence everyone got a white screen, including me xD

 

[CaioHenrique360]

Is it also possible to change the VC filter?

 

[DualBladedKirito]

@Sono will the 3rd option in your poll require a pc at all? Or can the patcher be run via twilightmenu?
Edit:nvm im blindlol