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

[Sono]

Is there documentation for configuring which patches are applied? The quality of the top screen isn't that great (IMO) when I am playing Pokemon Black 2, so I'd like to play around with it and see which filters will work best.

The patches are printed really fast when they get applied. As for what patches get applied, you can see them in the patch menu (applied patches will have a (x) instead of a (.)).

You can also somewhat see the expected quality of the scale filter while you're scrolling through it. Hold and release X to see the difference between default and the selected one.

 

[dhh]

The patches are printed really fast when they get applied. As for what patches get applied, you can see them in the patch menu (applied patches will have a (x) instead of a (.)).

You can also somewhat see the expected quality of the scale filter while you're scrolling through it. Hold and release X to see the difference between default and the selected one.

I'm able to see the difference between filters when I hold and release X, but I'm not sure which ones are actually being installed.

Should there be an (x) next to the item in the scale list? I'm trying to see the difference between sono's crisp, zero interpolation, etc. inside the game.

 

[Sono]

I'm able to see the difference between filters when I hold and release X, but I'm not sure which ones are actually being installed.

Should there be an (x) next to the item in the scale list? I'm trying to see the difference between sono's crisp, zero interpolation, etc. inside the game.

The highlighted one with the arrow is what gets installed.

What You See Is What You Get

Don't forget to enable Luma patching!

 

[dhh]

The highlighted one with the arrow is what gets installed.

What You See Is What You Get

Don't forget to enable Luma patching!

Ah that makes sense now. Thank you!

The nice thing about requiring Luma patching, is that it is an easy way to toggle the widescreen feature.

 

[placebo_yue]

Is there documentation for configuring which patches are applied? The quality of the top screen isn't that great (IMO) when I am playing Pokemon Black 2, so I'd like to play around with it and see which filters will work best.

I suggest linear filtering 2, if you're like me, seeing stretched pixels is an eyesore and that's (i think) the only filter that doesn't have any of that

 

[Lolight4]

Hello! I created this account just to say thank you for working on this! This makes playing DS/GBA/ETC. FAR more playable on a 3DS
I would also like to ask (I imagine this is a pretty tough thing to do) if something akin to a Sharp bilinear would be possible?
I believe its a shader in Retroarch and I am most familiar with it from Adrenaline which is a PsVita app that upscales and plays PSP games on the vita's huge screen with multiple filtering options (One being of course, sharp bilinear like i mentioned above).
Thank you for your work! It is super appreciated!

 

[Rahkeesh]

Sharp bilinear doesn't even do anything until you are going over 2x magnification. DS->3DS is like, 1.2x and GBA->3DS is 1.5x so they don't really apply.

There is a linear sharpen effect on the DS side but the "sharpen" mentioned here is a fundamentally different technique. There's also something similar used in open_agb_firm for GBA.

 

[Sono]

Hello! I created this account just to say thank you for working on this! This makes playing DS/GBA/ETC. FAR more playable on a 3DS
I would also like to ask (I imagine this is a pretty tough thing to do) if something akin to a Sharp bilinear would be possible?
I believe its a shader in Retroarch and I am most familiar with it from Adrenaline which is a PsVita app that upscales and plays PSP games on the vita's huge screen with multiple filtering options (One being of course, sharp bilinear like i mentioned above).
Thank you for your work! It is super appreciated!

Sadly it's not possible to do sharp AND bilinear, because they do the opposite. Unless you meant those interpolators in NES and GBA emulators, in which case it's really difficult due to timing difficulties. And don't even think about me patching this into Nintendo's code, as it's bad and bloated, it's impossible. However in homebrew it is somewhat possible.

Sharp bilinear doesn't even do anything until you are going over 2x magnification. DS->3DS is like, 1.25 and GBA->3DS is 1.50 so they don't really apply.

There is a linear sharpen effect on the DS side but the "sharpen" mentioned here is a fundamentally different technique. There's also something similar used in open_agb_firm for GBA.

I know that I have once seen a page where there are functions for a fixed magnification upscaling, and it definitely included 1.5x upscaling, but I don't remember 1.25x being a thing.

 

[Lolight4]

Sharp bilinear doesn't even do anything until you are going over 2x magnification. DS->3DS is like, 1.25 and GBA->3DS is 1.50 so they don't really apply.

There is a linear sharpen effect on the DS side but the "sharpen" mentioned here is a fundamentally different technique. There's also something similar used in open_agb_firm for GBA.

Ah i see, i still figured i would ask since I really enjoyed how the filter on the vita, but i must admit i wasn't aware that the Vita outscaled the PSP at least 2x.
I appreciate the response, it is interesting hearing more about the technical side of it through terms i can understand haha!

Sadly it's not possible to do sharp AND bilinear, because they do the opposite. Unless you meant those interpolators in NES and GBA emulators, in which case it's really difficult due to timing difficulties. And don't even think about me patching this into Nintendo's code, as it's bad and bloated, it's impossible. However in homebrew it is somewhat possible.



I know that I have once seen a page where there are functions for a fixed magnification upscaling, and it definitely included 1.5x upscaling, but I don't remember 1.25x being a thing.

Yes i must admit I was thinking of what would be called filters/shaders in emulators, which just change the upscaling algorithm (I think, i don't know very much about any of this admitedly, this is just an end user's perspective haha)
Still, thank you very much for the work you have put in! I personally really enjoy the "linear interpolation 2" and the "linear sharpen 1" scaling patterns!

 

[Rahkeesh]

The "sharp bilinear" being referred to is effectively the same as doing the highest integer scale you can, then taking that result and doing a bilinear scale to fill the screen. So its not a sharpen effect as is being used on 3DS, just integer and then bilinear. On the vita you can do around 2.4x on most home consoles for example.

I know that I have once seen a page where there are functions for a fixed magnification upscaling, and it definitely included 1.5x upscaling, but I don't remember 1.25x being a thing.

DS is 192p and 3DS is 240p. 192 x 1.25 = 240p. Or is Nintendo doing it slightly off?

 

[RocketRobz]

The "blinear sharpen" being referred to is effectively the same as doing the highest integer scale you can, then taking that result and doing a bilinear scale to fill the screen. On the vita you can do around 2.25x on most home consoles for example.



DS is 192p and 3DS is 240p. 192 x 1.25 = 240p. Or is Nintendo doing it slightly off?

Nope, you're right on that one.

 

[jFar920]

I'm pretty new to using stuff like this on my 3DS, so this may not be possible or isn't the place to ask, so sorry ahead of time if that's the case.

I was wondering if something exists to replace the Start/Select 1:1 toggle with a widescreen/normal scaling toggle instead? I really like the added option to have widescreen with some games, but obviously all of them don't have support for it, and since I don't typically use 1:1 scaling, it'd be nice to just be able to quickly boot a game into whichever option fits.

Additionally, I'm just using home screen icons to load games, not TWiLight Menu, which does appear to have more control over this from what I read, I think

 

[Sono]

Somewhat related to TWPatcher's future: I have an announcement to make. Those who have been following my profile posts know that I've been experimenting with 3DS drivers, and actually got both GBA mode and DS/DSi mode working.

Well, today I have reached 100% GBA mode compatibility, including savefile support!

Well, here is the thing: making a GPU driver is not an easy task. But I'm also at a point, where I have to reject most patch ideas due to the limits of what I can patch in Nintendo's awfully bodged code.

So if a lot of people are still interested in DS and GBA mode on the 3DS, and not satisfied with Nintendo's default code, here are 4 choices: (same order as in the poll)

1) Finish the GPU driver, and work towards better DSi compatibility.
Currently DSi mode boots, but there are a few things broken about it, like touch screen issues, the calendar is stuck at 2000 0th month, and I'm missing some important-looking DSi-exclusive memory region setups (which don't seem to affect DSi-exclusive games, but who knows what they do). If people favor my broken (and potentially dangerous if booting a very badly coded DSi-exclusive or a bad homebrew) code over Nintendo's janky code because I can finally freely include all suggestions, then I'll do it, even if it'll take yet another few months to do.

2) I won't make this project too much out of the techdemo phase. Although I'll work on it, I'll repurpose the code for private use, and won't release a compiled build, but instead will use it for testing the hardware in legacy mode. I'll still add some patches to TWPatcher, but keep in mind that there is like almost nothing else we can add into Nintendo's janky code.

3) I'll only release GBA mode replacement homebrew with all the benefits of what TWPatch can currently offer, plus more things we finally have space for. DS(i)-mode patches will stay the same in TWPatcher.

4) Similar to 2, except I'll still try to make DS(i) mode functional in homebrew, but no guarantees I can get it working properly.


I'll still work on the GPU driver because I need it for other projects as well, but once I'm done with the GPU driver, the poll results will decide what will happen.

DS is 192p and 3DS is 240p. 192 x 1.25 = 240p. Or is Nintendo doing it slightly off?

DS is 256x192, 3DS is 320x240 (and 400x240, but we don't care of the unused space now). Yes, it's 1.25x

No, I meant that there is a webpage where there is an upscale algo (used by emulators) which definitely includes 1.5x, and I don't remember there being 1.25x

I'm pretty new to using stuff like this on my 3DS, so this may not be possible or isn't the place to ask, so sorry ahead of time if that's the case.

I was wondering if something exists to replace the Start/Select 1:1 toggle with a widescreen/normal scaling toggle instead? I really like the added option to have widescreen with some games, but obviously all of them don't have support for it, and since I don't typically use 1:1 scaling, it'd be nice to just be able to quickly boot a game into whichever option fits.

Additionally, I'm just using home screen icons to load games, not TWiLight Menu, which does appear to have more control over this from what I read, I think

Sadly it's not possible due to the limitations of the patch, and the entire graphics system Nintendo is using. In fact, it's so limited, that the widescreen patch breaks 1:1 mode (it'll look really stretched and messed up).

Although I could try making an option in the patcher which says "Widescreen 16:10 (no 1:1 mode)", but you're limited to MTX upscale only, as the GPU upscale patch rewrites a good chunk of math functions, and it would break like almost every patch other than rtcom and redshift because I have to patch out and remove 1:1 mode support completely from TwlBg. Also no scale filter on the Y axis, so the vertical lines won't be filtered, and will have to do line doubling.

If you're okay with these limitations then I could look into it.

 

[Nutez]

I'm pretty new to using stuff like this on my 3DS, so this may not be possible or isn't the place to ask, so sorry ahead of time if that's the case.

I was wondering if something exists to replace the Start/Select 1:1 toggle with a widescreen/normal scaling toggle instead? I really like the added option to have widescreen with some games, but obviously all of them don't have support for it, and since I don't typically use 1:1 scaling, it'd be nice to just be able to quickly boot a game into whichever option fits.

Additionally, I'm just using home screen icons to load games, not TWiLight Menu, which does appear to have more control over this from what I read, I think

I have a pseudo-solution for that here. It adds some new functionality to Luma's Rosalina menu that allows you to switch between different versions the TwlBg.cxi patch that you have made. So you could created a collection of patches with different filters/settings and names (e.g. widescreen.cxi, nightmode.cxi) that you could choose between in 3DS mode via Rosalina, before booting into a DS game. It requires a little bit of setup/understanding but if the instructions aren't clear then feel free to ask here .

Somewhat related to TWPatcher's future: I have an announcement to make. Those who have been following my profile posts know that I've been experimenting with 3DS drivers, and actually got both GBA mode and DS/DSi mode working.

Well, today I have reached 100% GBA mode compatibility, including savefile support!

Well, here is the thing: making a GPU driver is not an easy task. But I'm also at a point, where I have to reject most patch ideas due to the limits of what I can patch in Nintendo's awfully bodged code.

So if a lot of people are still interested in DS and GBA mode on the 3DS, and not satisfied with Nintendo's default code, here are 4 choices: (same order as in the poll)

1) Finish the GPU driver, and work towards better DSi compatibility.
Currently DSi mode boots, but there are a few things broken about it, like touch screen issues, the calendar is stuck at 2000 0th month, and I'm missing some important-looking DSi-exclusive memory region setups (which don't seem to affect DSi-exclusive games, but who knows what they do). If people favor my broken (and potentially dangerous if booting a very badly coded DSi-exclusive or a bad homebrew) code over Nintendo's janky code because I can finally freely include all suggestions, then I'll do it, even if it'll take yet another few months to do.

Congratulations, very cool! I'll ask the dreaded question: would this allow for N3DS ZL/ZR and C-Stick use in DS/GBA games? XD I know you mentioned before that you weren't interested in writing a driver for this, but would option 1 open up this possibility for hypothetical future development of this by someone else? Also, would it allow for controlling the LCD backlight levels? Thanks again for your great hard work .

 

[Sono]

Congratulations, very cool! I'll ask the dreaded question: would this allow for N3DS ZL/ZR and C-Stick use in DS/GBA games? XD I know you mentioned before that you weren't interested in writing a driver for this, but would option 1 open up this possibility for hypothetical future development of this by someone else? Also, would it allow for controlling the LCD backlight levels? Thanks again for your great hard work .

Since TwlBg is rewritten from scratch (including drivers!), I can do whatever the ARM11 can.

So yes, if I write a CStick driver (old3DS and new3DS drivers are different, and I don't own an actual CPadPro, so CStick only) then it would be possible to make a driver and do button remapping.
And since I initialize the LCD with my own driver, it's obviously possible to set any arbitrary brightness level, including redshift already built-in.

 

[Nutez]

Since TwlBg is rewritten from scratch (including drivers!), I can do whatever the ARM11 can.

So yes, if I write a CStick driver (old3DS and new3DS drivers are different, and I don't own an actual CPadPro, so CStick only) then it would be possible to make a driver and do button remapping.
And since I initialize the LCD with my own driver, it's obviously possible to set any arbitrary brightness level, including redshift already built-in.

Fantastic! I suspected as much, I just wanted to be clear on all the possibilities . Option 1 definitely gets my vote then and hopefully many others. I don't mind how long it takes because the result would be unlocking the full potential of the N3DS. All the intermediate steps would be interesting to follow and even if it's not possible to include all the features: it's still going to be better than the bare-bones Ninty modes.

 

[Lv44ES_Burner]

I'm going to go with Option 1 on the poll, so as accordingly, I cast my vote on it. No matter the time it would take, it would be entirely worth it to have that functionality on the N3DS line. I did just order a New 2DS XL the past week to replace my O3DS, and a new home-coded TwlBG.cxi would be amazing to cap the system off when I finish setting it up.

However long it takes you, I wish you fervently the best of luck and thank you tremendously for the progress you've made thus far.

 

[ghjfdtg]

Just for the record there is already a working reimplementation for GBA mode that doesn't rely on any Nintendo code. The only problem with it is some stuff isn't configurable yet and save type detection is not reliable (being worked on).

 

[Rahkeesh]

If you want useful feedback you might want to explain or link what exactly this scope of these "drivers" are? Like for GBA, did you basically build your own open_agb_firm, or is this just something that kicks in when you launch a VC injection? Is it strictly graphics Did you gain control over controller remapping or cheats editing memory or managing save files?

If your new replacement approach opens up 800px wide scaling you could practically dump the old stuff, it will just completely smoke it. And if GBA is basically done go and release it! DS can come out later when its ready.

 

[Sono]

If you want useful feedback you might want to explain or link what exactly this scope of these "drivers" are? Like for GBA, did you basically build your own open_agb_firm, or is this just something that kicks in when you launch a VC injection? Is it strictly graphics Did you gain control over controller remapping or cheats editing memory or managing save files?

If your new replacement approach opens up 800px wide scaling you could practically dump the old stuff, it will just completely smoke it. And if GBA is basically done go and release it! DS can come out later when its ready.

Yeah, we have talked over this with profi200, and he has a valid point that it's weird that there are two projects doing the same thing but differently. I'll definitely promote open_agb_firm in my thread because there are things which open_agb_firm already does, but mine never will, or the opposite.

First I'll list both the pros and cons of both projects:

• LgyBg AGB:
  • Pros:
    • Drag-and-drop replacement for AgbBg *[1]
      
    • Includes all TWPatcher patches and scale kernels, and the ability to change between them in real time
      
    • Allows you to save and quit (currently works only once without rebooting) or exit without saving
    • Has a config menu while GBA mode is running
    • Button remapping (not yet implemented)
    • Has the same save compatibility as original AgbBg
  • Cons
    • Uses slightly more power than open_agb_firm because instead of using a fully custom optimized kernel, LgyBg still relies on LgyHorizon (ARM11) and LgyProcess9 (ARM9) which keep running in the background, and are bloated
    • Relies on Luma's patches to LgyProcess9 to patch signature checks
    • *[1] requires one-time additional patches to LgyHorizon (via TWPatcher) for LgyBg to work at all
    • Requires additional patches to LgyProcess9 if we want to have more control over GBA mode
    • No file explorer (relies on GBA injects)
    • Can't save if SD has been ejected and re-inserted (requires Process9 patches to work around this, if even possible)
• open_agb_firm:
  • Pros:
    • Amazing graphics (seriously, try it out, it's much better than anything I could do with patches!)
    • Has a file browser
    • Saves savefiles directly to the SD
    • Is a standalone FIRM *[1]
    • Extremely low-latency graphics (although still not real-time, but there is just no workaround for this)
  • Cons:
    • Save type detection is spotty at times (community help is welcome to help fix that)
    • Doesn't have a config menu (yet), so screen settings and brightness are fixed for now
    • *[1] might not be possible to work as a drop-in replacement for AGB_FIRM because Luma could patch things it shouldn't

By the drivers I meant that instead of having to patch Nintendo shitty code, I can just edit the source code of my (shitty) code if I want to add more functionality
And yes, this means that I can easily add 800px mode without having to tear my hair out. Or I can add additional drivers which don't even exist at all in Nintendo's code, like CStick or gyro driver, and I can do whatever crazy stuff I want.

As for the other things you mentioned:

• yes, my code is a replacement for TwlBg and AgbBg, and it goes to the same place TWPatcher's patched files go, so you need GBA injects
• savefile management is possible if I patch LgyProcess9, but on stock LgyProcess9 it's only possible to save once without rebooting
• it's a hardware limitation that we can't use cheats and other hacky stuff, because there is a real GBA inside the 3DS, so no matter what we try, we can't (and so can't open_agb_firm even if it wanted), because once GBA is started, we're locked out, and the memory associated to the GBA is physically removed from the 3DS hardware until you reboot, so the only thing we can do is patch the ROM after load, but not after it has been started
• savefile management is not (yet?) possible in my code, but even then you can only save to one place. open_agb_firm could technically save as often as it wants to, provided that you don't choose save while the game is saving, because only one CPU can access the save hardware at a time
• and yes, I can do mode800 support with ease now