I tried poking at a version but I couldn't glean very much, too much going on, I'll look some more but is disgusting that they just embed the ROM in the RPX, need to fix that
I tried poking at a version but I couldn't glean very much, too much going on, I'll look some more but is disgusting that they just embed the ROM in the RPX, need to fix that
Yeah, they literally just injected a ROM inside the ELF itself and then converted it to RPX. The offset we're thinking the filtering is being handled at is at offset 00F32A80
As seen here, there are two instances where the bytes show up, and thus changed to
These are the findings @QuarkTheAwesome found while poking around. The weird part is that these offsets are shared with NES RPX/elf files, what we're trying to do is correct the gamma
and find out where it's applying the linear filter and why NES games seem to use a bilinear filter, the GX2 function is called GX2InitSamplerXYFilter and GX2InitSamplerZMFilter, but he can
definitely put his input in here and explain what he's found, it's messy yes, but I feel, no, we feel that we're on to something.
Edit: He explained the function here http://gbatemp.net/threads/understa...es-vc-rpx-settings.425474/page-8#post-6371351
Just to clarify, the modification in blue changes the VC's call to GX2InitSamplerXYFilter to have "1" as argument 2 and 3 (though it doesn't seem to make a difference atm). Not sure what happens if you change the bytes highlighted in red.
Tried to alter the bytes in both red and green/blue sections to the other bytes suggested previously, but I didn't notice anything different, I really hope I'm not stressing you guys out, but I started this thread and I don't want to just pack up and go home so to speak, you know?
Seriously, it's fine ;D
If I was having trouble with this that I couldn't deal with I wouldn't be helping. Since I'm helping, you can be sure that you're not stressing/holding me out/back. Simple as that :3
By the way I've started writing this in my free time so you can look at that if you want. Although I'm fairly sure the bit on syntaxes is just flat-out wrong. WIP.
No worries, and I'm sure that we can find out sooner or later what needs to be changed to alter the filter and gamma levels to help them look better. I mean, after all, NES ELF files share the same offsets, and those use a heavier filter than Snes games for some reason. And I thank you both and everyone else involved, gonna be heading to bed in a bit, so I'll let you guys do your magic, I know we're onto something.
No worries. I think I've actually found what we need to tweak, so there might be some good news in the morning ;D
Bookmarked, love to see more. PPC assembly is interesting.Seriously, it's fine ;D
If I was having trouble with this that I couldn't deal with I wouldn't be helping. Since I'm helping, you can be sure that you're not stressing/holding me out/back. Simple as that :3
By the way I've started writing this in my free time so you can look at that if you want. Although I'm fairly sure the bit on syntaxes is just flat-out wrong. WIP.
No worries. I think I've actually found what we need to tweak, so there might be some good news in the morning ;D
False alarm, no luck. We can basically rule out all references to GX2InitSamplerZMFilter and GX2InitSamplerXYFilter at this point, I've tried all of them to no avail.
Worth noting that one particular call to GX2InitZMFilter actually has filtering enabled. Tweaking this to the other filter type made no change, but I think I can tell you where this filter is visible - open up the Virtual Console Menu and you'll see the image in the background slightly blurred. My guess is that's where you can see the filtering.
Looks like the VC is not using those two functions for its upscaling. It's likely some sort of shader or something. I've got a bit of a headache rn (IDA does that to me, it also explains the rather low quality of what I'm writing atm), so I'm gonna work on something else for now but my guess is that the VC has a shader or some sort of logic upscaling the image before sending it off to GX2 at the correct resolution.
Someone can look at texture2D_206.gsh (under /content on Loadiine dumps) if they want, that's probably what needs rewriting
fyi there's a very easy to find mario rpg dump that was uploaded on wednesday in case you're interested in checking that game's rpx
lets be honest here smrpg is a turn base rpg, 50hz makes literaly no diference lol if you dont play a turn based rpg becuase you got only the 50hz version them your not a big fan of the game lol.Yeah, I saw that it's been dumped, the problem is twofold, it's PAL and injecting ROMs into PAL RPX files makes them PAL still, unless there's a way to change it to NTSC.
lets be honest here smrpg is a turn base rpg, 50hz makes literaly no diference lol if you dont play a turn based rpg becuase you got only the 50hz version them your not a big fan of the game lol.
like i said not a big fan then xD.I'm just saying, some 50 Hz games also have slower music, and growing up with the 60 Hz version, the slower tempo will kinda ruin for me, but that's just me lol, sorry For gameplay, no, you're right, no big difference, but the music will be 20% slower, and as I'd be able to tell a diff right away if it's a slower tempo. I just wish we can force 60 Hz in RPX games is all.
I'm not a big fan of crackling audio nor slow audio in ANY game.like i said not a big fan then xD.
just confirmed that the pal e shop super mario rpg is the usa version so there is no craking or 50 hz lol.I'm not a big fan of crackling audio nor slow audio in ANY game.
Btw, @the_randomizer have you had any luck looking into the texture2D_206.gsh file that Quark mentioned?
I'm not a big fan of crackling audio nor slow audio in ANY game.
Btw, @the_randomizer have you had any luck looking into the texture2D_206.gsh file that Quark mentioned?