by pixel perfect you mean that it's completely unfiltered and unstretched? wouldn't it look TINY?
It WILL be tiny. There is simply no other way, the display lacks enough pixels, and there isn't enough raw hardware power for subpixel magic filters to work in real time at 60FPS.
Keep Y pressed right after you press A to open the app, and it'll boot to a different mode for GBA patches.
Yeah, but I keep forgetting to re-add the filters which got lost from the source code at some time.
As I got ninja'd above at the time of typing this reply, you do need to indeed hold Y during the Nintendo 3DS boot logo after launching TWPatch until the menu shows up to boot into the hidden GBA patcher mode.
They are not new, they just somehow went missing from the source code.
Although there are definitely a few filters which were requested for GBA in this thread.
I've tried to install this based on the installation instructions found on GameBrew, which are written for enabling widescreen.
Specifically:
-Placed TWPatch.3dsx in 3ds folder.
-Launched TWPatch using the homebrew launcher.
-Pressed Y+B to open the patch menu.
-Toggled "Invert START+SELECT function".
-Pressed B.
-Held START to begin patching.
I saw that the D-pad patch was also applied, despite not selecting it.
At this point, the instructions are unclear, so I first tried launching a GBA game. The screen was still stretched.
Rebooted my 3DS into Luma3DS's configuration screen. Enabled external FIRMs and modules, and saved. Tried a GBA game again. No change.
What do I have to do at this point?
Also, since you were able to patch the D-pad, does that mean it is possible to remap the GBA's buttons?
Specifically:
-Placed TWPatch.3dsx in 3ds folder.
-Launched TWPatch using the homebrew launcher.
-Pressed Y+B to open the patch menu.
-Toggled "Invert START+SELECT function".
-Pressed B.
-Held START to begin patching.
I saw that the D-pad patch was also applied, despite not selecting it.
At this point, the instructions are unclear, so I first tried launching a GBA game. The screen was still stretched.
Rebooted my 3DS into Luma3DS's configuration screen. Enabled external FIRMs and modules, and saved. Tried a GBA game again. No change.
What do I have to do at this point?
Also, since you were able to patch the D-pad, does that mean it is possible to remap the GBA's buttons?
Make sure that you're running Luma from SD, not NAND. If you have a
boot.firm file on your SD card you're good. If not download it either from Universal-Updater or just manually.
What are you exactly trying to do? Trying to use native GBA mode, or running GBARunner2 in DS mode?
For GBA mode, you need to hold Y while booting TWPatch to enable GBA patching mode (you know when you have enabled GBA patching mode if the number of scale filters drops dramatically, and the background is glitched out).
The DPAD patch doesn't affect normal gameplay on unmodified hardware. It lets you use both CPad+DPAD to let you press "illegal" combinations UP+DOWN and LEFT+RIGHT.
While the DPAD patch doesn't do anything fancy which would infer that button remapping is possible, it is possible to "remap" the buttons (or more accurately, simulate button input in software). Normally the button presses are routed directly to the GBA, so there is zero delay there. But with button remapping, since it has to be simulated in software, so there is some added delay which might be noticable by some players.
I can not do a patch to do this in Nintendo's own garbage code due to many reasons, but if writing new code then it is doable.
I'm trying to use native GBA mode. Just followed your instructions, and now it works! Thanks!
I know the D-pad patch doesn't affect normal gameplay, but I prefer to not have a patch applied that I didn't choose.
Is the routing really that direct? Surely there must be code somewhere that tells AGB_FIRM which 3DS buttons correspond to which GBA buttons? Because all four face buttons are mapped to either A or B.
I'm sorry that you feel about the DPAD patch that way. Although it requires conscious effort to press both the DPAD + CPad together which you probably never need to do under normal circumstances, and most games already have a mechanism to still counteract LEFT+RIGHT or UP+DOWN press (which is usually MUCH better anyway than what garbage Nintendo did), so I thought that this default could only be beneficial to basically almost everyone. Besides, the default DPAD filtering just adds delay to the inputs, and that's also a reason I have disabled the filtering by default.
Although to be fair, I didn't expect people to go into the patcher that often, so using original design considerations, I thought it's okay to have some defaults, and let people uncheck them if they *really* hate it. The only exception to this is rtcom in DS mode, which is required by some patches to work properly, so it's easier (for me) to just leave it enabled than to have people complaining that after patching they just go to a black screen because they forgot to enable it.
I would love to hear feedback though, especially since many people use TWPatch more often than I have intended it to be used. Because I don't get much feedback, it's hard to know if I'm doing things good or bad.
Yes, if you disable software control for every button then each physical button (DPAD, A, B, START, SELECT, L, R) gets connected directly to the GBA (also X and Y in DS mode), so if the game scans the buttons more than 60FPS, or has an interrupt set up for button presses, you can trigger them anywhere mid-frame.
However, if you enable software control, the software itself controls when the buttons get scanned from the 3DS side, processed, then forwarded into the DS/GBA side. Nintendo's code does this AFTER VSync, so every software button will be at least one frame too late.
As for the X button functioning as B in GBA mode, that's done in software, so it will be subject to the 1 frame delay.
That's a reason I can get behind.
I understand, but that patch wasn't checked in the list, yet it was still installed. That's what bugged me.
I see, so the buttons are connected by hardware after all. Too bad.
That's a reason I can get behind.
I understand, but that patch wasn't checked in the list, yet it was still installed. That's what bugged me.
I see, so the buttons are connected by hardware after all. Too bad.
Which patch was not checked yet still applied? That could be a bug.
"Too bad"? What's wrong with direct connection? There is some latency in the video output due to the capture card, but that's it, the rest works like an actual GBA.
Also all buttons can be overridden in software, which would allow for things like button remapping, TAS input, macros (turbo fire button?), and other things.
How did you apply this, and what do you mean? I need more information so I could investigate this.
megaman zero collection: re-released gba games for nintendo ds. the filter used is sono crisp. The screen is a little smaller but is much sharper.
Attachments
The D-pad filter one.
In this case, it means that the buttons can't be remapped without introducing latency.
How much latency are we talking about?
- No one is chatting at the moment.
-
-
-
-
-
-
-
@
xtremegamer:
loving the new zelda, i started a game, it was so fucking good, so i
am waiting on my friend to get home so we can start a new one together -
@
Skelletonike:
I just dislike that they don't let me choose the voices before the game starts. Happened with botw as well, had to change to japanese and restart. -
-
-
-
-
-
-
-
@
Skelletonike:
Just scanned all my zelda amiibos, took a while but didn't get anything that cool, did get the lon lon ranch hylian fabrics though.
-
-
@
K3N1:
@Skelletonike, btw I ran that custom for mgs4 on the deck I'm amazed it got that far in game -
-
-
-
-
-
-
