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

[Vague Rant]

Funnily enough you can derive the aspect ratio from the DS' original resolution too, because it has the same aspect ratio Also, I said matrix hardware, not TwlBg. Of course the software has to care, because it's using OpenGL to draw the image. But since the matrix unit it just a very clever image stretcher, we can ignore the resolution entirely because the aspect ratio remains the same.

But yeah, I get your point.

Right, but I'm suggesting scaling the screen by different ratios vertically and horizontally, so the aspect ratio would be changing/different from either the DS (4:3) or 3DS (5:3)'s native aspect ratios. Sorry about my terrible understanding of the terminology here, you're doing well to understand what I'm saying anyway.

Nope. Unless you are okay with partial stretch (instead of 400 wide, which is 25/12 stretching, you get 384, which is 24/12, which can be simplified to 8/4 for the matrix hardware).

Is this math right, because that sounds super confusing to me. The original DS's resolution was 256*192, but (24/12)*256 = 512, not 384. What exactly is the matrix hardware multiplying by?

 

[Sono]

Right, but I'm suggesting scaling the screen by different ratios vertically and horizontally, so the aspect ratio would be changing/different from either the DS (4:3) or 3DS (5:3)'s native aspect ratios. Sorry about my terrible understanding of the terminology here, you're doing well to understand what I'm saying anyway.

Oh, now I see what you meant. Yeah...

Is this math right, because that sounds super confusing to me. The original DS's resolution was 256*192, but (24/12)*256 = 512, not 384. What exactly is the matrix hardware multiplying by?

WTFFFFFFFFFFFFFFFFFFFFFF, now I re-did the math, and now I'm not getting 2.08333333* Damn, sleep deprevation is clearly hindering my progress

Now that you made me realize my math was completely wrong, I re-did it, and got 25/16, which is also 12.5/8, or 8/5.12, which is... awful, because the matrix unit can only operate with integer numbers.

However, it seems like my point still stands, and the resolution closest to 400, but not above is still 384, which is 6/4.

There is also a ratio which is VERY close to 400, but it's slightly above it, and it outputs an awful non-integer pixel count: 409.6, which gets truncated to 410 by the hardware, and WILL result in AWFUL scaling, and most likely very blurry without some proper kernels. And ofc it'll also hang off the side of the screen, which is less than ideal...

 

[Vague Rant]

For another comparison, here's Mario Kart DS displayed at 8:5 (just via emulator & cheat, but theoretically doable on hardware).

Original 256*192 (1x scale) <---> "Normal" 3DS 320*240 (1.25x scale)

Widescreen cheat 256*192 (1x scale) <---> Widescreen cheat 384*240 (1.5/1.25x scale)

EDIT: Quick demonstration of the size of the tiny black pillars on left/right with 384​

This was made using the widescreen cheat from the thread I linked earlier, modified specifically for 8:5 (16:10) widescreen instead of the 16:9 which the cheat used by default.

 

[Raylight]

I hope the sharp filter gets put into twlight menu looks awesome and this widescreen is amazing

 

[Reynardine]

A widescreen option like in Vague Rant's mockup would be awesome.
Even with the tiny black borders left and right its still bigger than the topscreen of a DSi XL.

If this is going to work I can finally shelve my DSi XL with it's awful soft buttons...

 

[Vague Rant]

@Sono If it's any help to you, I quickly threw together a spreadsheet of what I think should be every possible scaling value:
https://docs.google.com/spreadsheets/d/1kMbn1cBD5a7W9zalBLTN-ig1vgqS6fuuBGlm45FRN6M/

Numbers in red are anything I personally deemed useless (e.g. anything less than 1x scale or over 1.6x scale), yellow are any duplicates (e.g. 8/6 is the same thing as 4/3), green are all of the values I figured have at least got potential to be useful.

As annotated, the first table is the scale factor, second table is the scale factor multiplied by 256 (horizontal), and the third table is the scale factor multiplied by 192 (vertical).

 

[Sono]

@Sono If it's any help to you, I quickly threw together a spreadsheet of what I think should be every possible scaling value:
https://docs.google.com/spreadsheets/d/1kMbn1cBD5a7W9zalBLTN-ig1vgqS6fuuBGlm45FRN6M/

Numbers in red are anything I personally deemed useless (e.g. anything less than 1x scale or over 1.6x scale), yellow are any duplicates (e.g. 8/6 is the same thing as 4/3), green are all of the values I figured have at least got potential to be useful.

As annotated, the first table is the scale factor, second table is the scale factor multiplied by 256 (horizontal), and the third table is the scale factor multiplied by 192 (vertical).

Btw, after I have done the basic patches I'll look into scaling X and Y individually, so try to do a separate "useful scale values" for both.

Also, for the Y co-ordinate, 1.5x is already off-screen, so take that into consideration.

Edit: I'm blind, sorry

Edit2: you can adjust the decimal points in the formatting or edit menu afaik.

 

[Waygeek]

Sono should sleep and finish this up later.

 

[Reynardine]

I have manually applied the sharp 1.25x scaling to multiple 3DS systems now and noticed that for the original 3DS and original 3DS XL the offsets in the code.bin file were exactly as written in Sono's tutorial.

For the small New 3DS, the New 3DS XL and the New 2DS XL the offsets were as I reported a few pages back, at 0xC9A for the unused 1.5x scaling and at 0x4B094 for Sono's sharp 1.25x scaling.

All systems were EU region on the most recent firmware 11.10.0-43E.

Seems like the offsets only differ depending on whether you have an old 2/3DS model or a New 2/3DS model.
I assume that a different firmware also results in different offsets, but I couldn't test that.

Maybe that info will be helpful when it comes to writing an auto patcher.

 

[plug313]

this is so exciting and one of the few things I've been wanting from the 3DS hacking scene thank you so much for your work Sono. I can't wait to play my ds games with less blur! and to try that wide-screen mode as well. I don't have a pc so I have to wait until there's something I can directly put on my 3DS.

also did you know sono means sleep in portuguese?

 

[Sono]

I have manually applied the sharp 1.25x scaling to multiple 3DS systems now and noticed that for the original 3DS and original 3DS XL the offsets in the code.bin file were exactly as written in Sono's tutorial.

For the small New 3DS, the New 3DS XL and the New 2DS XL the offsets were as I reported a few pages back, at 0xC9A for the unused 1.5x scaling and at 0x4B094 for Sono's sharp 1.25x scaling.

All systems were EU region on the most recent firmware 11.10.0-43E.

Seems like the offsets only differ depending on whether you have an old 2/3DS model or a New 2/3DS model.
I assume that a different firmware also results in different offsets, but I couldn't test that.

Maybe that info will be helpful when it comes to writing an auto patcher.

My patcher uses pattern searching, so it works despite the version. I tested pre-1.0.0 up to 11.0, and it seems to work just fine.

 

[Reynardine]

My patcher uses pattern searching, so it works despite the version. I tested pre-1.0.0 up to 11.0, and it seems to work just fine.

That's great news.
Best of luck to you with this project!

It's amazing how a change like this enhances the playing experience.

 

[DSoryu]

My patcher uses pattern searching, so it works despite the version. I tested pre-1.0.0 up to 11.0, and it seems to work just fine.

I expected that method to be the most convenient as well. So, the other upscaling modes you mentioned through this thread will be included as well?

 

[gohan123]

I want to try it but I can't find the dump twl_firm in godmode9 or do I really need the older tool?

 

[AkikoKumagara]

I want to try it but I can't find the dump twl_firm in godmode9 or do I really need the older tool?

The first post details exactly where to get it using GM9. The file you need won't be called twl_firm when you find it on the system.

 

[gohan123]

The first post details exactly where to get it using GM9. It won't be called twl_firm when you find it on the system.

oh right I should have started there instead of ahezard github

 

[Sono]

I expected that method to be the most convenient as well. So, the other upscaling modes you mentioned through this thread will be included as well?

The initial patcher will come with 1.25x modes because of the difficulties I have with thinking and existing.

Later I'll also add the rest of the suggestions to the patcher, including but not limited to 1.5x, START+SELECT swap, stretched top screen, and custom matrix maker.

 

[gohan123]

I tried guide mixed with sono and ahezard, not sure if it even allowed to mix them? one guide got a .firm file, the other a .bin.

I'm not even sure I see a difference, I might have done something wrong.



next time I will try taking photo without hdr on.

 

[Sheimi]

When I run ahezard twl_firm_patcher. I get this.

IndentationError: unexpected indent
load: twlBg.exefs.header
ERROR: open file twlBg_patched_exefs/code.bin failed

 

[Sono]

I tried guide mixed with sono and ahezard, not sure if it even allowed to mix them? one guide got a .firm file, the other a .bin.

I'm not even sure I see a difference, I might have done something wrong.



next time I will try taking photo without hdr on.

Try the patcher first, then do the scale kernel patch.

When I run ahezard twl_firm_patcher. I get this.

IndentationError: unexpected indent
load: twlBg.exefs.header
ERROR: open file twlBg_patched_exefs/code.bin failed

Try downloading and unzipping the repo instead of copypasting the Python script.