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

[Stellar]

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

What will this mean for performance overall? (what I mean is, will 800px mode end up being slower or have a different sort of visual artifacts?).

And also, is anyone implementing 800px mode, and if so where can we follow development (sorry, I came to this thread primarily for the screen scaling and unstart patches so I'm largely ignorant of adjacent topics).

Scratch all that. Rather, is there a way to just disable the code that causes the odd behavior I described in my last post (GBA games slicing off bottom portions of the screen and drawing it on top instead) without adverse effects? Or is the function that the code serves crucial to performance in some way?

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.

Okay nevermind, you've already mentioned what happens when that code is disabled.

 

[ghjfdtg]

Maxbe it's worth looking into open_agb_firm. It's in alpha but it doesn't have the refresh rate sync problem. But it doesn't have 800 pixel mode either (yet).

 

[wanderindirk]

I see.

As for the wide compat list: I don't need to see it, but I know that two things play a role so that a game could get on that list:
1) The game has to be using the 3D engine. Since almost all graphics on the DS is hardware-accelerated, games using the 2D engine can't be squished because the 2D hardware doesn't support aspect ratio correction. As for 3D engine, since the triangles and quads are calculated with the CPU, in most 3D games there is a variable to patch which controls the aspect ratio to squish the world. By patching that variable, the game gets even more squished, resulting in anamorphic widescreen.
2) Someone has to have found the variable and patched it Although some games require insane amount of patches, most games to my knowledge only need the aspect ratio correction, and sometimes a few patches to increase the rendering width so the triangles and quads normally outside the visible area are still rendered.

I never bothered to try the widescreen mode on any purely 2D DS game, but it must be the case then that these games can't be squished (your word is good enough by me). Not that it would concern me or anything

One thing that might be of my interest (though it sounds more like wishful thinking) is that whether or not widescreen mode in 2D sections (like the menu) or FMVs could possibly be temporarily deactivated back to normal resolution in games that are truly widescreen-compatible, and then switched back to widescreen in other in-game sections. Currently this is the only major reason which might discourage me from going full widescreen in every compatible game. My guess is of course that it's simply impossible but I'm still a bit curious as to why.

 

[emcintosh]

One thing that might be of my interest (though it sounds more like wishful thinking) is that whether or not widescreen mode in 2D sections (like the menu) or FMVs could possibly be temporarily deactivated back to normal resolution in games that are truly widescreen-compatible, and then switched back to widescreen in other in-game sections. Currently this is the only major reason which might discourage me from going full widescreen in every compatible game. My guess is of course that it's simply impossible but I'm still a bit curious as to why.

I don't believe this is possible, as the DS game doesn't know it's being rendered in widescreen. The widescreen codes force the game to render a wider viewport in 3D scenes but with all the objects squashed, which the 3DS (which doesn't know whether the 256x192 image the DS mode is sending is 3D objects, 2D sprites or a mix of both) then stretches back to the correct proportions. This is how we used to get widescreen on TV - 'anamorphic widescreen' squashes the 16:9 picture to 4:3 on the recording, and the TV stretches it.

 

[Sono]

Scratch all that. Rather, is there a way to just disable the code that causes the odd behavior I described in my last post (GBA games slicing off bottom portions of the screen and drawing it on top instead) without adverse effects? Or is the function that the code serves crucial to performance in some way?

Sadly I can't fix the timing issue, or at least not that I know of. That requires so extreme patching of the driver that I might as well attempt to make open_twl_firm and help out profi200 with it

I never bothered to try the widescreen mode on any purely 2D DS game, but it must be the case then that these games can't be squished (your word is good enough by me). Not that it would concern me or anything

One thing that might be of my interest (though it sounds more like wishful thinking) is that whether or not widescreen mode in 2D sections (like the menu) or FMVs could possibly be temporarily deactivated back to normal resolution in games that are truly widescreen-compatible, and then switched back to widescreen in other in-game sections. Currently this is the only major reason which might discourage me from going full widescreen in every compatible game. My guess is of course that it's simply impossible but I'm still a bit curious as to why.

I don't believe this is possible, as the DS game doesn't know it's being rendered in widescreen. The widescreen codes force the game to render a wider viewport in 3D scenes but with all the objects squashed, which the 3DS (which doesn't know whether the 256x192 image the DS mode is sending is 3D objects, 2D sprites or a mix of both) then stretches back to the correct proportions. This is how we used to get widescreen on TV - 'anamorphic widescreen' squashes the 16:9 picture to 4:3 on the recording, and the TV stretches it.

That is only possible in very rare circumstances:
- the game's ARM7 has to be rtcom-patched
- you must use the MTX-based upscaling, because GPU upscaling requires so many patches that it's practically impossible to patch it at runtime
- the game has to be patched so when the screen mode has changed, the ARM9 tells the ARM7 to tell the ARM11 to switch upscaling mode (lol at this ridiculous setup)
- the game has to be patched so it can switch the 3D aspect ratio on the fly when both the 3D and 2D engines are used (thanks @emcintosh for pointing that out!)

 

[Stellar]

I might as well attempt to make open_twl_firm and help out profi200 with it

I had no idea that project existed (open_agb_firm), thanks!

 

[BETA215]

Sadly I can't fix the timing issue, or at least not that I know of. That requires so extreme patching of the driver that I might as well attempt to make open_twl_firm and help out profi200 with it

Tbh, if you ever feel like trying to attempt something like open_twl_firm, we'll be more than happy to read about your journey! (whether it has a nice ending or not)

 

[RocketRobz]

Have you found out if the FF values (and the write-lock flag) in the GBA Slot ROM are set by either TWL_FIRM or the hardware?
Reason is because I found that NO$GBA loads the booted .nds file into the GBA ROM area in the memory map, if DS console is set.
But here's where it gets more interesting. It also works with DSi console set!
So this kinda gives me hope that we can use the GBA ROM area for memory/RAM expansion.

 

[Sono]

Have you found out if the FF values (and the write-lock flag) in the GBA Slot ROM are set by either TWL_FIRM or the hardware?
Reason is because I found that NO$GBA loads the booted .nds file into the GBA ROM area in the memory map, if DS console is set.
But here's where it gets more interesting. It also works with DSi console set!
So this kinda gives me hope that we can use the GBA ROM area for memory/RAM expansion.

Can you please tell me the related (DS(i)-side) registers so I can look them up on gbatek?

As for the 3DS, I have a feeling it's no longer possible since the GBA slot and DS Main RAM overlap on the same physical FCRAM locations.

 

[RocketRobz]

Can you please tell me the related (DS(i)-side) registers so I can look them up on gbatek?

The GBA ROM is located at 0x08000000-0x09FFFFFF.
As for the write lock flag, it doesn't exist. Was wondering if that was a thing in TWL_FIRM itself.

As for the 3DS, I have a feeling it's no longer possible since the GBA slot and DS Main RAM overlap on the same physical FCRAM locations.

Does that mean we can't map the GBA ROM area to somewhere in the 3DS RAM?

 

[Ihavegbasp]

Just found out about this patch and been playing Chrono trigger with the Sono crisp matrix and it looks amazing, thanks Sono!
But how do you access all other features listed in the post like screen swapping, button remapping and the blue light filter?
I'm using the version linked in the original post is it outdated or something?

And can AGB_FIRM be modified in the same way?

 

[Sono]

The GBA ROM is located at 0x08000000-0x09FFFFFF.
As for the write lock flag, it doesn't exist. Was wondering if that was a thing in TWL_FIRM itself.

Does that mean we can't map the GBA ROM area to somewhere in the 3DS RAM?

Ah.
Yeah no, GBA mode is just a clever hack using existing hardware and memory remapping tricks. According to profi200 and/or nocash, FCRAM is always removed from the 3DS-side bus, no matter what. In DS and DSi mode it becomes main RAM, and in GBA mode it becomes cartridge ROM. To my knowledge it hasn't been attempted yet if it's possible to somehow remap the FCRAM and/or if it's writable after having poked some regs.

Just found out about this patch and been playing Chrono trigger with the Sono crisp matrix and it looks amazing, thanks Sono!
But how do you access all other features listed in the post like screen swapping, button remapping and the blue light filter?
I'm using the version linked in the original post is it outdated or something?

And can AGB_FIRM be modified in the same way?

Yes, it is very outdated, others have also fallen into this "trap". Just keep looking for a puu.sh URL everyone keeps posting every 1-2 pages and that'll be most likely it.

Button remapping patch is not available yet, as I don't have time, and mode 800 patch has a higher priority now anyway. Screen swapping is also not user-accessible. The patch itself is compiled into the patcher, but no code exists to patch the screen swap code into TwlBg itself.

AgbBg patching is not officially supported by me, but I develop the patches both for TwlBg and AgbBg at the same time, so almost all patches are available for one or the other.
You can hold - I think - Y while TWPatch is booting to unlock the secret "AGBG" patching mode.

 

[KaduPSE]

Ah.
Yeah no, GBA mode is just a clever hack using existing hardware and memory remapping tricks. According to profi200 and/or nocash, FCRAM is always removed from the 3DS-side bus, no matter what. In DS and DSi mode it becomes main RAM, and in GBA mode it becomes cartridge ROM. To my knowledge it hasn't been attempted yet if it's possible to somehow remap the FCRAM and/or if it's writable after having poked some regs.



Yes, it is very outdated, others have also fallen into this "trap". Just keep looking for a puu.sh URL everyone keeps posting every 1-2 pages and that'll be most likely it.

Button remapping patch is not available yet, as I don't have time, and mode 800 patch has a higher priority now anyway. Screen swapping is also not user-accessible. The patch itself is compiled into the patcher, but no code exists to patch the screen swap code into TwlBg itself.

AgbBg patching is not officially supported by me, but I develop the patches both for TwlBg and AgbBg at the same time, so almost all patches are available for one or the other.
You can hold - I think - Y while TWPatch is booting to unlock the secret "AGBG" patching mode.

There´s actual hope for a 800px mode though? From your previous posts I assumed the system didn´t like it

 

[Ihavegbasp]

Yes, it is very outdated, others have also fallen into this "trap". Just keep looking for a puu.sh URL everyone keeps posting every 1-2 pages and that'll be most likely it.

Button remapping patch is not available yet, as I don't have time, and mode 800 patch has a higher priority now anyway. Screen swapping is also not user-accessible. The patch itself is compiled into the patcher, but no code exists to patch the screen swap code into TwlBg itself.

AgbBg patching is not officially supported by me, but I develop the patches both for TwlBg and AgbBg at the same time, so almost all patches are available for one or the other.
You can hold - I think - Y while TWPatch is booting to unlock the secret "AGBG" patching mode.

Thanks for the help Sono got everything figured out now.
Will be looking forward to 800px mode

 

[Sono]

There´s actual hope for a 800px mode though? From your previous posts I assumed the system didn´t like it

It does work™, but it's unusable. It's either extremely stretched, or parts of the screen are cut off and black or flickering.
I'll make a funny video compilation with my attempts and post it here.

 

[Raylight]

whats 800px mode? GBA taking up the entire screen or somthing for DS?

 

[KaduPSE]

whats 800px mode? GBA taking up the entire screen or somthing for DS?

All 3DS models (except the o2DS) have a screen with a particular matrix where pixels are slightly distant vertically, and you have double the horizontal resolution (800px). When using 3D, each doubled horizontal pixel goes to a different eye using a parallax barrier, so two different images can be formed. When you´re not using 3D those pixels try to create one single pixel (400px as the horizontal resolution) by behaving in pairs, this works... But you´re essentially throwing away 400px of horizontal resolution, and these duplicated pixels don´t look like proper squares so pixel art gets slightly messed up. Some people (Robz8?) figured out a flag you can enable to build your apps to run in 800px without 3D, essentially using every single pixel in the screen. Try Hori-HD or build Mario 64 with this mode enable to compare.

 

[Raylight]

All 3DS models (except the o2DS) have a screen with a particular matrix where pixels are slightly distant vertically, and you have double the horizontal resolution (800px). When using 3D, each doubled horizontal pixel goes to a different eye using a parallax barrier, so two different images can be formed. When you´re not using 3D those pixels try to create one single pixel (400px as the horizontal resolution) by behaving in pairs, this works... But you´re essentially throwing away 400px of horizontal resolution, and these duplicated pixels don´t look like proper squares so pixel art gets slightly messed up. Some people (Robz8?) figured out a flag you can enable to build your apps to run in 800px without 3D, essentially using every single pixel in the screen. Try Hori-HD or build Mario 64 with this mode enable to compare.

Wait so theres a way to get a crisper picture in DS and GBA using this mode?

 

[Sono]

whats 800px mode? GBA taking up the entire screen or somthing for DS?

Wait so theres a way to get a crisper picture in DS and GBA using this mode?

For GBA, kinda yes. Sadly this is only true for GBA width, not GBA height, but instead of 1.5 x 1.5 upscaling, with mode 800 it's possible to get 3 x 1.5 upscaling, which still looks much better than without the patch.

 

[Vague Rant]

Wait so theres a way to get a crisper picture in DS and GBA using this mode?

For GBA, kinda yes.

Technically DS can also benefit from it if you're playing in widescreen. Similar to the GBA, you can do a non-matching 3x by 1.25y scale.

Horizontal: 3*256 = 768
Vertical: 1.25*192 = 240

768*240 is, remembering that the pixels are half as wide as normal square pixels, a 16:10 aspect ratio, identical to how DS widescreen support operates on 3DS currently. This means, at least for games with widescreen support, you'd be able to get a clean triple-resolution scale on the horizontal axis, which should look a lot crisper. On the vertical, you are still stuck with the awkward 1.25 times scale.

If you don't mind that it's an awful idea, you could do a 3x by 1y scale, 768*192, for a 2:1 aspect ratio image with black borders on all sides.