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

[Retro_Mod_Gamer]

Not enough code space, sorry.

Sono, once again, incredible work. I have a suggestion. Is it possible to also map the ABXY buttons to the "c-stick"? This would allow for dual analog support in games like Metroid Prime Hunters.

 

[Vague Rant]

@Sono That's true, I know Mario 64 DS runs at 30FPS anyway (there is a 60FPS hack available), so in theory you wouldn't be losing anything by having it run at 30FPS on 3DS. Something like Mario Kart DS which is originally 60FPS would definitely be severely impacted.

 

[Sono]

Sono, once again, incredible work. I have a suggestion. Is it possible to also map the ABXY buttons to the "c-stick"? This would allow for dual analog support in games like Metroid Prime Hunters.

There is not enough code space, and I don't know the protocoll for the C-Stick, sorry :/ The fake input is already kinda complex, let alone adding a new input method.

@Sono That's true, I know Mario 64 DS runs at 30FPS anyway (there is a 60FPS hack available), so in theory you wouldn't be losing anything by having it run at 30FPS on 3DS. Something like Mario Kart DS which is originally 60FPS would definitely be severely impacted.

Welp... in that case it was displaying at 15FPS, not 30FPS. The game still runs unaffected, but the patch messes with the timings, so it misses two VBlanks.

 

[deisuke1234]

@Sono incredible work of yours. I just wonder something if you stretch the resolution let say to 370 and not to 380 would it still get this FPS issue?

 

[Sono]

@Sono incredible work of yours. I just wonder something if you stretch the resolution let say to 370 and not to 380 would it still get this FPS issue?

Trying to add a custom resolution is the culprit. Just using the already existing 1.5x scale mode works just fine, but anything beyond the 3 resolutions included in the binary will result in bad side effects :/

 

[Reynardine]

I'd still like to see a widescreen option if you think it is worth the effort!
I've been wanting this for so long, I could live with the tradeoff if it doesn't affect games to the point of being unplayable.

Would using the CPU boost in TwilightMenu++ help against the slowdown or is that unrelated to this problem?

 

[Sono]

Would using the CPU boost in TwilightMenu++ help against the slowdown or is that unrelated to this problem?

It's unrelated. This is a software problem in TwlBg running on the ARM11. The DS hardware is unaffected as long as you don't try to steal FCRAM bandwidth.

 

[Vague Rant]

Trying to add a custom resolution is the culprit. Just using the already existing 1.5x scale mode works just fine, but anything beyond the 3 resolutions included in the binary will result in bad side effects :/

This is interesting to me, since the widescreen resolution you're shooting for (384*240) is smaller than that used by the 1.5x scaling mode. (384*288). EDIT: So it's not that the 3DS can't handle that high of a resolution, just ... not this specific one? /EDIT

Out of interest, which of the three modes are you working from when attempting to build the 384*240 mode? Are you replacing the 1.25x scale, or the 1.5x? It seems like the 1.5x scale is "closer" to what you're trying to achieve--maybe the 3DS would handle it better using whatever values it hardcodes for that mode, compared to the 320*240 mode?

 

[Sono]

This is interesting to me, since the widescreen resolution you're shooting for (384*240) is smaller than that used by the 1.5x scaling mode. (384*288). EDIT: So it's not that the 3DS can't handle that high of a resolution, just ... not this specific one? /EDIT

Out of interest, which of the three modes are you working from when attempting to build the 384*240 mode? Are you replacing the 1.25x scale, or the 1.5x? It seems like the 1.5x scale is "closer" to what you're trying to achieve--maybe the 3DS would handle it better using whatever values it hardcodes for that mode, compared to the 320*240 mode?

It's not smaller. I reverse engineered the matrix hardware enough, and figured out how to scale the X axis independently of Y.

Also yeah, the patches I used (until now) skipped two VBlanks.
The patch I'm working on might be able to actually stretch the top screen at the expense of slightly distorting the bottom screen, with no VSync skip penalty.

I'm using the 320x240 one because the 1.5x mode requires extra patching, and it also affects the bottom screen, which is a no-no.

 

[Sono]

Well, this was fast... I did it for GBA mode. Now that I know what values to patch, DS mode shouldn't be too far now, assuming I don't fall asleep before I succeed.

Spoiler: 5/3 wide GBA

 

[Vague Rant]

Amazing (and fast!) work there, @Sono. Do feel free to at least try to catch up on some sleep.

 

[AkikoKumagara]

Love that you found that screen swap thing. Hope that gets added as an additional feature. I can't imagine it being useful in a ton of games, but it's still cool as hell. Good job on the GBA patch as well, looking forward to it.

 

[DSoryu]

Great to hear that your progress is giving results beyond your expectations, and by the compromises that need to be taken, only testing can give you the answers you seek, so take your time and sleep enough, believe me, mental fatigue is the worst in the world, so I highly recommend you to rest enough. Thank you for sharing your findings!

EDIT: I just saw that is possible to swap screens!! Now I love you more haha, that is really a GREAT thing for me, because in the Castlevania games I always found weird to have the map at the top screen instead the opposite, and on emulators I always tend to swap them.

Now a few questions regarding this:
Will it be "swapable" in-game and per game?
Will it need to be patched/unpatched before opening DS-mode, affecting every game?
I know it would be hard to implement these patches per game, but, is there a possibility to do that?

 

[Vague Rant]

Love that you found that screen swap thing. Hope that gets added as an additional feature. I can't imagine it being useful in a ton of games, but it's still cool as hell.

This is definitely very nice. Over in the widescreen thread there's a collection of games which are in a separate list because they display primarily on the touch screen, so there's no benefit to widescreen. A feature like that could turn a lot of those around, as long as they don't rely heavily on touch input. e.g. The Zelda games would not work very well if you swapped the screens because they're based entirely around touch input (unless you use button hacks), but other games that don't use touch too heavily should be playable switched and with widescreen support.

EDIT: @Dartz150 It would be hard to implement on a per-game basis if you're just launching them via normal methods, but with something like TWiLight Menu++ it should be doable. TWLMenu is already set up to handle widescreen on a per-game basis by loading into a separate TwlBg, so it should be equally as possible to launch into a separate "screen-flipped" TwlBg for selected games.

 

[Stack3r]

Awesome work on the GBA screen size! Does it appear to slow down FPS at all? And also would you be able to add that to your current program so we can have wide GBA?

 

[daemonspudguy]

Any way to download the patcher?

Sent from my moto z3 using Tapatalk

 

[RocketRobz]

Any way to download the patcher?

Sent from my moto z3 using Tapatalk

Should be a few pages back.

 

[Searinox]

There's a bug in the original code whereby DS mode scalled to full 3DS screen occasionally ends up duplicating a strip of the image on the lower part of the screen(s). It's fixable by closing and reopening the console lid but I'm curious if with your insight you can actually tell what's going on and why this bug occurs.

 

[daemonspudguy]

Wich patch stretches it?

Sent from my moto z3 using Tapatalk

 

[RocketRobz]

Wich patch stretches it?

Sent from my moto z3 using Tapatalk

None yet. There should hopefully be a future version that does it though.