Oh, only the GUI elements are stretched, the 3D field is fine, thanks for the fast reply!
Yeah, I'm using it, and as I said it works for me. Though I didn't test it thoroughly, only to remove the widescreen hack. Had it enabled with cia version prior. Asked for 3dsx to be populated with before mentioned as it appears bare in HBL, no icon, no name, etc.
Last edited by eqagunn,
I have a question regarding the filter matrix.
Does it work like a normal filter matrix (for example, opening the convolution matrix filter in gimp),and if so, is it possible to edit it ourselves?
Does it work like a normal filter matrix (for example, opening the convolution matrix filter in gimp),and if so, is it possible to edit it ourselves?
I actually never touched that in GIMP, so I don't know what it does.
There are two 1D matrixes (X and Y) which just do weighted average around them with a configurable weight.
TWPatcher's matrixes are not editable, but they are a planned feature for LgyBg.
Sounds like it's similar then. The one in gimp is a regular 5x5 matrix.
I'm only asking because I really liked the GPU scaling, but it's a little too blurry for my taste, I was hoping to make a hermite filter with sharpening, if possible, but I don't know how feasible that is with 2 1D matrices instead.
Could this be used to get the circle pad state into a DS game? If so, do you have any documentation to help me go about doing that?
Yes, it's been actually done, I just privated all videos, so people don't get mislead, because someone knowledgable must patch the support into games for it to work, and there are no such patches yet.
The patch I did only works on a very specific version of TwlBg, so I'll have to do a proper microcode for ARM11 to be able to read CPad on all versions of TwlBg.
How are you patching the bytes of the game? Or is this a homebrew? So I can select the easiest method.
You must know that in any case you'll need to be able to access the RTC from the ARM7 for this to work at all, since that's what rtcom uses.
Last edited by Sono,
Oh cool. I was under the impression that there wasn't any way of doing it, but it seems like with some effort, it should be possible.
I've been experimenting with getting analog stick / circle pad input into SM64DS. I wrote a modified version of DeSmuME and a game patch (in the form of an Action Replay code) that sends the analog input to the game through the GBA-slot interface. My forum account is too new for me to directly link it, but if you look up LRFLEW on Github, it's in the DeSmuME fork. I'm also starting to work on a patch for the Wii U Virtual Console solution, but I'm too early in to know if or how it will end up working exactly (the method I used for DeSmuME changed a few times while working on it).
I would expect the best way to patch the game bytes is to use an Action Replay code to patch the instructions in RAM. I remember seeing that TWiLight Menu++ supported using them, which would make it simple to use. Otherwise, patching the ROM file should work, but would be trickier due to SDK Compression (I'm looking into it for the Wii U project).
That sounds trickier. The Solution with DeSmuME only patched ARM9 instructions, but ARM7 instructions should be patch-able the same way. I'll need to get the data from the ARM7 to the ARM9. Since the patch already breaks multiplayer, I should be able to use memory related to that for the transfer, though.
Looking at GBATEK, it appears that RTC communication works via a CPU-driven serial communication. This might pose another challenge to it, as the patch will need to be able to account for the required timings without causing interruptions to other ARM7 tasks, such as sound.
Last edited by LRFLEW,
That suuuuuuuuuuuuuucks, since you do need to patch a hefty amount of ARM7 code, and you also need to store the ARM11 microcode somewhere in the ARM7 binary where you can upload it to the ARM11.
Sadly you're the first one actually interested in patching this into any game, so there isn't yet a refined method for adding rtcom into the game besides putting random code into the ARM7 and somehow branching to it to read the joystick data, while also installing a VBlank handler which calls a different function inside the random code which pulls the joystick data from the ARM11.
LgyBg is the project name for my TwlBg and AgbBg replacement. There are a few screenshots to prove that it exists [1] [2] [3], but I don't have time to work on it, and as you can see, they are way too unfinished to be released. Even though GBA mode is fully functional, and I could release it without worrying, but there is no scaling yet, because I need to write a GPU driver for 3D acceleration.
Yeah, this won't be an easy challenge, but I figured that would be the case, as otherwise someone else would have done it already. Doing it as a ROM patch might be easier if a significant amount of code needs to be appended, but that's something that can be figured out while working on it.
I would apreciate any help with getting this to work, but I understand if you're busy. If can't or don't want to work on this, I'd apreciate any reference material you have (eg. partially working code). If I'm doing this alone, I'll probably prioritize the Wii U project over this, and will get back to this later. (Though I'm running into the issue that I can't analyze the emulator with a debugger because it doesn't run in Cemu, so that might limit how much I can do with that project for now).
I'm a little confused by your explanation here. It sounds to me like you have the ARM7 reading the joystick data twice.
What I got from your previous explanation is that getting the analog stick values requires getting code on both the ARM11 and ARM7, with the ARM11 reading the analog stick values, transmitting it to the ARM7 via the RTC interface, and the ARM7 saving it to the memory shared with the ARM9 to get it into the game.
How easy is writing the ARM11 code, and how much CPU time is free on it? One thing is that SM64DS needs the analog stick values in a specific form (fixed point with 0x1000 being max and -0x1000 being min), along with the magnitude/angle of the input. I can do all the conversion in ARM9, as the game already does it for the touch screen controls, but it may be easier to do it in the ARM11.
I have another question.
Does the screen always get cropped starting from the corner, or is it possible to center it?
Because for some games I think the extra blurriness that comes from scaling the game to 410x240 and cutting off the extra 10 pixels would be worth it, for example games that are mostly 3D.
Does the screen always get cropped starting from the corner, or is it possible to center it?
Because for some games I think the extra blurriness that comes from scaling the game to 410x240 and cutting off the extra 10 pixels would be worth it, for example games that are mostly 3D.
Last edited by Edgarska,
Even though there is already reference source (https://github.com/Gericom/Rtc3DS), it'll probably also take an effort from my side to make it viable for you to embed this into the ROM somehow.
It doesn't read the joystick data twice, I just really misworded it. The VBlank handler should automatically read the joystick data, and you could query that data by calling into the ARM7 patch.
Yes, that's exactly how it works.
It's sort of easy writing ARM11 microcode (see in the Rtc3DS example), but I'll need to write some code which detects where the joystick data is being read, and read from there. Since the ARM11 is microcoded, you can transform the data on the ARM11 itself, so I guess that'll come handy for you.
--------------------- MERGED ---------------------------
The screen is not cropped, but centered as 384x240 in DS widescreen, or 400x240 in GBA widescreen.
Or am I misunderstanding what you want?
I meant if a different scaling resolution value was used instead of the one used now.
I saw in the spreadsheet that one of the possible values was 410 for the horizontal resolution, so my question was if that means the image would be cropped starting from the left, or if it would be possible to center it.
D
Deleted User
Guest
Hey folks, now I may be missing something obvious, BUT:
I can select and apply patches just fine (e.g. redshift and widescreen), however, I can't seem to get the main filters to work.
I select the filter I want (zero interpolation) by placing the ">" next to it, I enter the patch menu, I select the patches to apply (GPU scaling and widescreen) by pressing A on them, I leave the patch menu, and I press START to create TwlBg.cxi.
But, when I load TWLoader++, any game launched from TWLoader++, or any DSi game launched from the 3DS menu, it doesn't appear that the zero interpolation filter has been applied; it's still all blurry (on both the top and bottom screen).
What am I doing wrong?
Also, this has probably been asked a thousand times, but is it necessary to recreate TwlBg.cxi after every system update? Or only after updates that touch TWL (for lack of a better term)? Or not at all...?
I can select and apply patches just fine (e.g. redshift and widescreen), however, I can't seem to get the main filters to work.
I select the filter I want (zero interpolation) by placing the ">" next to it, I enter the patch menu, I select the patches to apply (GPU scaling and widescreen) by pressing A on them, I leave the patch menu, and I press START to create TwlBg.cxi.
But, when I load TWLoader++, any game launched from TWLoader++, or any DSi game launched from the 3DS menu, it doesn't appear that the zero interpolation filter has been applied; it's still all blurry (on both the top and bottom screen).
What am I doing wrong?
Also, this has probably been asked a thousand times, but is it necessary to recreate TwlBg.cxi after every system update? Or only after updates that touch TWL (for lack of a better term)? Or not at all...?
Similar threads
-
- Locked
