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

[Sono]

Pardon me please, what exactly is "un-START" and where can I read about it?

Toggling this patch boots TWL_FIRM (DS mode) and, if you use the secret menu, AGB_FIRM (GBA mode) with their native resolution without having to keep START or SELECT pressed while booting, which is the default behaviour. This is good for people that want to avoid any scaling whatsoever.

Pretty much this. The only thing I'll add is that un-START doesn't fully disable the functionality, it just inverts it. So if you want to temporarily turn on scaled mode, you hold START *and* SELECT as opposed to holding START *or* SELECT without the patch to disable scaling.

 

[HailAndStormCats]

Just a quick question (I hope this hasn’t been asked already), how do we apply filters in the widescreen mode using the on-device patcher without the filter looking bad? I’ve tested with a LOT of filters but for some reason the filter always glitches and causes these weird “anti-alias” lines up the screen, even with the default scaler.

 

[Sono]

Just a quick question (I hope this hasn’t been asked already), how do we apply filters in the widescreen mode using the on-device patcher without the filter looking bad? I’ve tested with a LOT of filters but for some reason the filter always glitches and causes these weird “anti-alias” lines up the screen, even with the default scaler.

Sorry, but I still haven't done the necessary edits which would enable filtering to be used on the horizontal axis in 16:10 mode.

 

[Rahkeesh]

Just a quick question (I hope this hasn’t been asked already), how do we apply filters in the widescreen mode using the on-device patcher without the filter looking bad? I’ve tested with a LOT of filters but for some reason the filter always glitches and causes these weird “anti-alias” lines up the screen, even with the default scaler.

I would try the GPU scaling patch for now, this scales correclty in both directions in widescreen. A bit blurry but that's kind of what you want for 3D polygon games anyway.

 

[HailAndStormCats]

How do we access GPU scaling mode? My N3DS XL refuses to acnowledge Y -> B, so IDK.
(BTW I'm just updating to the version posted on page 68 so here goes nothing)

 

[Sono]

How do we access GPU scaling mode? My N3DS XL refuses to acnowledge X -> B, so IDK.
(BTW I'm just updating to the version posted on page 68 so here goes nothing)

I don't know where you got X-->B from (I hope I never said X+B), it's Y+B, and the UI is laggy, so you have to hold Y for a second before holding B for a second. You also will need to update TWPatcher if it doesn't say "Hold Y+B to open the patch menu" or you don't see "16:10 384x240 wide" on the patch selection screen.

 

[HailAndStormCats]

Good news, it turns out the old version I was using didn't have Y -> B (I made an error in my previous post), so that's fine. I'm compressing the file as of now.
Even if it works well, I'm still gonna be picky about which games use the patched version and which don't.

--------------------- MERGED ---------------------------

Works like a charm!
Also, small suggestion: next time you update the application, couldn't you add a percent done into the 0x bytes done prompt?

 

[Sono]

Also, small suggestion: next time you update the application, couldn't you add a percent done into the 0x bytes done prompt?

Not sure I can. I'll try looking into it.

 

[KaduPSE]

Now with GPU scaling for AGB_FIRM and TWL_FIRM... Could we enable 800px mode? This would (finally!) display correct pixel art on the 3DS, as in, square pixels would be actually square. Even without any upscaling, just native res at 800px mode would look amazing. How feasible is it?

 

[Sono]

Now with GPU scaling for AGB_FIRM and TWL_FIRM... Could we enable 800px mode? This would (finally!) display correct pixel art on the 3DS, as in, square pixels would be actually square. Even without any upscaling, just native res at 800px mode would look amazing. How feasible is it?

If you could peek into the code of TWPatcher, you'd see that it already has that mode in its code (PAT_SQUISH), but it's very broken, so I have disabled it.

As for what you said, that's only partially true.
In 240x400 mode, two rectangular pixels are combined into a square pixel via line doubling. In 240x800 mode, you can scale GBA (not DS) to a perfect width because each GBA pixel covers exactly 3 rectangle pixels (so 1.5 real pixels). Sadly the height can't be increased in the same way as width, but every little improvement helps, I guess.

 

[Sono]

Well, back to the "good news and bad news" template...

Good news:

Spoiler: Big images

The first sreenshot is blurrier, but shows how it looks currently.
The second screenshot is detailed enough to see the rectangle pixels if you zoom in really close. It's pretty amazing stuff...

Edit: direct links just in case the 'temp proxy is still broken:
- https://puu.sh/Gbgzf/1e95ec0743.jpg
- https://puu.sh/GbgBz/1416bc3131.jpg

Bad news:

Spoiler: Text

Sadly this is all we might get due to how awfully bad and hardcoded DMPGL is. I'll still try, but so far I haven't had much luck. I either glitched out DMPGL or the PDC itself (display controller in the GPU), or everything just crashed due to the GPU writing to memory where it shouldn't.

 

[Joom]

3) Fixed widescreen GPU scaling! Now you can use MTX widescreen and GPU widescreen too.

4) This is really important! By default, the anti-wear patch will be applied from now on to every TwlBg.cxi TWPatcher generates. You can disable it like you can disable rtcom, but it is not recommended at all. It turns out that DS(i) mode bricks when the flash inside the DS WiFi dies. That flash stores settings like username, time, touch screen callibration, and other stuff you can set in the DS BIOS on a real DS. This has been a problem since before 1.0.0 was released, hasn't been fixed in 11.6, and it's probably still present in the latest firmware. There are no checks in the code to prevent rewriting the flash if the data written is the exact same which was already there. Because of this, each time you launch into DS(i) mode, it'll write to the flash, slowly wearing it out until it can no longer hold any of the settings. This problem is only present in TWL_FIRM, so both AGB_FIRM (GBA mode firmware) and homebrew replacements (like open_agb_firm) are unaffected.

I'm incredibly glad I checked this thread on a whim after reading this. I've been holding off on trying this out so development could blossom further, and now I feel fortunate to have done so. Wonderful to know this now. Also, I was wondering, since the GPU is handling upscaling, do we still need to use the widescreen cheats from the other thread?

 

[Rahkeesh]

Yes you still need widescreen cheats. Just because its using the GPU for scaling doesn't mean said scaling is interacting with the 3D render stuff at all. At the end of the day its still rendering DS resolution and then stretching it to fill the 3DS widescreen, the GPU scaling just does a cleaner job at the moment.

 

[HailAndStormCats]

A little bit of info: compression on the New 3DS takes about 1.5 to 2 mins depending on how large the file is at the end (the highest I can think of being linear sharpening with DPGML widescreen and GPU scaling).

 

[Sono]

A little bit of info: compression on the New 3DS takes about 1.5 to 2 mins depending on how large the file is at the end (the highest I can think of being linear sharpening with DPGML widescreen and GPU scaling).

That's weird, because it must take the same time to compress and produce the same output size file regardless of what settings or patches you select.

And that big of a difference in the compression speed is very suspicous.

 

[Statesman]

So the WIFI wear issue is supposed to be caused by normal 3ds use, a DS-mode use, Twilight Menu use or Widescreen use?

 

[Stellar]

So this is almost certainly not the best place to ask, but on the off chance that it is, I have a question:

https://gbatemp.net/threads/how-do-i-fix-this-gba-cia-screen-crunch.458161/

This is a semi-common problem for me. I've tried the many suggestions in terms of cluster sizes but I have a feeling there's no actual correlation between that and whatever actually causes AGB_FIRM to glitch the screen. Maybe I'm wrong but I've tried more than one card, a 64GB and a 128GB to be exact, both Samsung, at 16k, 32k and 64k cluster sizes, and sooner or later the issue pops up again.

Since you seem to have an understanding of AGB_FIRM I was wondering if you had any theories as to why this happens at all. The way I fix my issues when they crop up is to close the game, scale it back up with Start+Select, which tends to display correctly, close it and relaunch unscaled again.

To be clear, I'm not suggesting your patches cause this bug, I know they don't. I just figured I'd ask.

@Sono

 

[Sono]

-snip-

Some people have some wild imagination for sure
One thing is for sure: there is no correlation between SD parameters and a graphical glitch.

This happens because of how strict the timing is for the capture card, and bad code.

To put it simply, hardware timings align to whack the capture card out of sync, but the code responsible for synchronization is so bad that it can't recover, so it'll get stuck in this cycle where it tries to whack the 3DS LCD into sync, but fails miserably due to a small amount of lag messing up the timing, and it'll stay like this until the capture card is reset and restarted.

The code is so complex that it's easier to just disable the code responsible for this. You can notice when this code is disabled because if you're looking at 60FPS fluid motion, you'll see stutter every once in a while because the LCD timings can NOT be matched without artifacts or within the 3DS LCD's limit.

In 800px mode this code is always disabled because it crashes the GPU.

 

[KaduPSE]

There´s always something to learn from Sono´s posts, I´d read a damn book made by this user on 3DS hardware.

 

[DualBladedKirito]

Some people have some wild imagination for sure
One thing is for sure: there is no correlation between SD parameters and a graphical glitch.

This happens because of how strict the timing is for the capture card, and bad code.

To put it simply, hardware timings align to whack the capture card out of sync, but the code responsible for synchronization is so bad that it can't recover, so it'll get stuck in this cycle where it tries to whack the 3DS LCD into sync, but fails miserably due to a small amount of lag messing up the timing, and it'll stay like this until the capture card is reset and restarted.

The code is so complex that it's easier to just disable the code responsible for this. You can notice when this code is disabled because if you're looking at 60FPS fluid motion, you'll see stutter every once in a while because the LCD timings can NOT be matched without artifacts or within the 3DS LCD's limit.

In 800px mode this code is always disabled because it crashes the GPU.

Does this "bad code" cause the twlbg bug as well? Or are they unrelated?