Oh, only the GUI elements are stretched, the 3D field is fine, thanks for the fast reply!If it's a ROM hack, and the 3D field is stretched, then yes.
Oh, only the GUI elements are stretched, the 3D field is fine, thanks for the fast reply!If it's a ROM hack, and the 3D field is stretched, then yes.
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!
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.Also, there is a 3dsx link in the main post. It doesn't work for me, but I guess you could have better luck with it?
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.
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?
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.
ARM11 <--> ARM7 communication with rtcom (discovered by @Gericom) ... any developer and romhacker can use this for anything which needs 3DS hardware access
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.
How are you patching the bytes of the game? Or is this a homebrew?
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.
-snip-
Hi there, I didn't read this thread for a while
Could anyone tell me what's the LgyBg AGB, please?
Sent from my SM-N960F using Tapatalk
... 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.
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.
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.