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

[MarioKartFan]

You are correct @Rahkeesh. What a goof on my part. I agree that the GPU scaling actually looks better in some widescreen games. Though I do wish it was a tad lesss “smudgy” as some of the greatest games of all time like DQV are so font intensive that the smudge kinda interferes with the awesomeness that is widescreen.

 

[Randoug]

First and foremost @Sono thank you very much for your time and dedication to this project!! You're awesome man.
I just finished reading over 30 pages of the forum, and would just like to confirm a few things I'm still a bit confused on,

By selecting DMPGL Widescreen in patches, users do not have to hold X to enable widescreen too? Is there much of a difference between the two options? Also, by selecting GPU scaling, MTX options are disregarded/not used, correct?

Sorry if you've already explained these, I did my best to search your previous replies (saw a few from a while back on a much older version)
Thanks again!!!

 

[Sono]

First and foremost @Sono thank you very much for your time and dedication to this project!! You're awesome man.
I just finished reading over 30 pages of the forum, and would just like to confirm a few things I'm still a bit confused on,

By selecting DMPGL Widescreen in patches, users do not have to hold X to enable widescreen too? Is there much of a difference between the two options? Also, by selecting GPU scaling, MTX options are disregarded/not used, correct?

Sorry if you've already explained these, I did my best to search your previous replies (saw a few from a while back on a much older version)
Thanks again!!!

Yeah, if you select anything from the patch menu, don't hold any buttons other than START to patch. If you don't enter the patch menu however, the hold-X-for-widescreen keycombo should still work however. Holding X should be the same as enabling it in the patch menu.

Yeah, the GPU scaling patch completely disables upscaling, and uses the GPU for upscaling. Because upscaling is disabled, the filters aren't applied.

 

[JamesDaSpaghettiTaco]

I know that I might be asking for too much but could I have the source code to see if I can possibly make some improvements to the program?

 

[DualBladedKirito]

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

Question my good friend. Will your lgy agb be able to bypass the 32mib rom file size limit currently in place for agb firm?. There are a couple rom hacks that go over that by a miniscule but entirely necessary amount. The main one being Pokemon Adventure Red Chapter vol1. And trimming it breaks the rom. If so I would use both open_agb_firm and yours interchangeably

 

[ghjfdtg]

It's a hardware limit. The best that can be done is cut off the data beyond 32 MB with a risk of the game not working properly. Ask the author of the ROM hack to shrink it or someone who might be willing to try in case it has been abandoned.

 

[Sono]

Question my good friend. Will your lgy agb be able to bypass the 32mib rom file size limit currently in place for agb firm?. There are a couple rom hacks that go over that by a miniscule but entirely necessary amount. The main one being Pokemon Adventure Red Chapter vol1. And trimming it breaks the rom. If so I would use both open_agb_firm and yours interchangeably

It's a hardware limit. The best that can be done is cut off the data beyond 32 MB with a risk of the game not working properly. Ask the author of the ROM hack to shrink it or someone who might be willing to try in case it has been abandoned.

Basically this. GBA mode runs on actual GBA hardware, which doesn't support going higher than 32Megs due to how the ROM is presented to the CPU.
And there was never a need to bypass this limit, because all retail games fit into this space.

I know GBA Video is an exception, but it had a special chip inside the cartridge, which could change / "fool" how the CPU sees the cartridge. Effectively it still has seen a 32Meg cartridge, but what the CPU sees could be magically changed by "writing" into the cartridge in a way the magic chip understood, and it would present different data to the CPU depending on what was written.

But here is the kicker: even if there was a magical way to change the way the CPU sees the cartridge so it could see more ROM at once, you most likely still couldn't access more than 32Megs, because the cartridge is emulated in hardware on the 3DS, and it's most likely that Nintendo only hooked up 32Megs worth of ROM space to the cartridge emulator, so the GBA hardware can still only see 32Megs, even if more ROM space were unlocked somehow.

 

[ghjfdtg]

Did you mean 32 instead of 16? Because the biggest ROM supported by hardware is and always was 32 MB. For everything bigger they started to use a mapper to switch between 2 banks to double that. Details here. These ROM hacks all depend on emulator bugs or inaccurate emulation to support bigger ROMs. The mapper was not yet discovered at the time these ROM hacks were made.

 

[ccfman2004]

Did you mean 32 instead of 16? Because the biggest ROM supported by hardware is and always was 32 MB. For everything bigger they started to use a mapper to switch between 2 banks to double that. Details here. These ROM hacks all depend on emulator bugs or inaccurate emulation to support bigger ROMs. The mapper was not yet discovered at the time these ROM hacks were made.

I’m also pretty sure it’s 16MB as that one 32MB GameBoy Video rom could never be dumped until someone figured out how they bypassed the 16MB rom limit.

 

[Sono]

Did you mean 32 instead of 16? Because the biggest ROM supported by hardware is and always was 32 MB. For everything bigger they started to use a mapper to switch between 2 banks to double that. Details here. These ROM hacks all depend on emulator bugs or inaccurate emulation to support bigger ROMs. The mapper was not yet discovered at the time these ROM hacks were made.

Yes, I misremembered, oops! I meant 32Megs!

I’m also pretty sure it’s 16MB as that one 32MB GameBoy Video rom could never be dumped until someone figured out how they bypassed the 16MB rom limit.

Nope, I checked the memory map again, and it calculates to 32Megs.

 

[ccfman2004]

Then why was it so difficult to dump that one GameBoy Advance Video Rom?

 

[Sono]

Then why was it so difficult to dump that one GameBoy Advance Video Rom?

Because no other GBA cart includes a mapper chip, and it's a quite an esoteric mapper, even compared to systems where a mapper is a common thing... The mapper code had to be reverse engineered with a lot of guesswork.

 

[AceCuba]

I agree but it’s objective. Pick whichever filter you like best. None of them are really game changing. That said, widescreen is absolutely incredible. So too is the possibility of being able to move into TWL mode and map stylus movements to physical buttons.

how i can do that on my 3ds the map stylus movements

 

[Sono]

how i can do that on my 3ds the map stylus movements

Yeah uh...

While trying to get touchscreen working, I noticed that you can't actually emulate the position of the touch :/

Basically nohow.

 

[RocketRobz]

Since TWiLight Menu++ has no way of checking if the currently used TwlBg file contains widescreen, could you make TWPatcher generate a checksum file for the generated TwlBg.cxi file?
TWiLight Menu++ could then read the checksum file, and see if the TwlBg file is widescreen, based on a known checksum.

 

[ccfman2004]

Would the hashes even be the same if two different DS systems used the same patches?

 

[Sono]

Since TWiLight Menu++ has no way of checking if the currently used TwlBg file contains widescreen, could you make TWPatcher generate a checksum file for the generated TwlBg.cxi file?
TWiLight Menu++ could then read the checksum file, and see if the TwlBg file is widescreen, based on a known checksum.

I can generate a features file which contains a list of patches. I'll also try a way to embed it into the original file, if possible.

Would the hashes even be the same if two different DS systems used the same patches?

Not necessarily, considering I make my patches work on pre-1.0.0 TWL_FIRM all the way to the current version. And if I tweak a patch, it'd also change the checksum.

 

[eqagunn]

Hi Sono. I understand 3dsx version is not supported, however... It works for me. I'm using 3dsx version of all homebrew apps without parental controls pin lock. As HBL has it, it allows me to protected them through it. Would be nice if you could either implement it into cia or have 3dsx version populated with app name, author name, description, icon, etc. for the esthetic reasons. I don't want to be an ass but the icon could use a makeover. Thank you for your work!

 

[Tavisco]

I've followed the guide from TwilightMenu++ and installed successfully, but the game I'm currently playing (Pokémon Pearl) is clearly being stretched, is this the expected result?

 

[RocketRobz]

I've followed the guide from TwilightMenu++ and installed successfully, but the game I'm currently playing (Pokémon Pearl) is clearly being stretched, is this the expected result?

If it's a ROM hack, and the 3D field is stretched, then yes.