..:: PCSX2 Forums ::..

Just wanted to sign in and say, I've done some testing with Grandia III, long term testing that is. Now, in Grandia III we all know that during some in-game cut-scenes Grandia III punishes graphics cards, for what appears to be no reason. Using the old scaling methods, I can run 3x scaling without my frames dropping below 55 when these demanding for no reason cut-scenes happen, but with the new scaling method, I drop down to 20 and have a hard time recovering....

I had a theory yesterday while I was playing Kinetica that this new scaler method, although increases graphical fidelity, might punish graphic cards more. Just a tip, because I think it actually does, but depends on the game. Grandia III, for those cut-scenes, gets hit hard, and for Kinetica, memory usage increases slightly, but I haven't done a 5-10 hour test for it yet.

The scaling build I uploaded last night, was intended really, only for doing some test comparisons tbh. I wouldn't really go using it fulltime or anything like that. I'll be looking into the scaling again tonight, to see if there's a proper alternative to the default hardcoded values.

Just wanted to mention it. May as well as use it fulltime for games that don't mind it.

(01-20-2014, 11:40 PM)Asmodean Wrote: [ -> ]I dunno about that >.<, but all the same. I'm obviously honoured and will help out how I can
----

KrossX: Yeah, I've been testing that myself. GSdx is reporting the same output res as before, but I've been monitoring GPU load to try and see if that's the only culprit, but it doesn't seem to be as simple as that. I've not had enough time today to look into it properly though. I was bleary eyed at like 5am last night when I uploaded the test build >.<

#edit: typos

Congratulations!


GPUDrawingEnvironment is properly initialized on creation, so I would guess it really is just 320x240. That could be tested replacing (m_base_width * 4), (m_base_height * 3) with 1280, 720. It would explain the extra burden on gpu.

The problem with GS is that for framebuffers you know the width but not the height. To get a similar display rect would be the DISPLAY1/2 regs but, you get height in pixels but width in clocks. I guess width would be easier from the framebuffer regs.

I dunno what numbers you could get, but might be worth the try.

Sidenote: Would separated scalers be worth it? For with and height separated.

Yeah, that's worth looking into. Also, bear with me, and I'll edit this and upload two test screens in a minute, just compiling two builds.

#Edit: Yar - tested it, and your right. I took the multipliers out of base width/height and tested it. Then retested with 320, 240. Same results (same frame rect size is displayed). I had bloody tested this already, but I stupidly used the first values in the GetDisplayRect() w/h arrays (256, 240). So when I tested it, I didn't end up getting the same results. So I didn't end up thinking it was the same lol *facepalm*

I'll keep looking into it anyway. I still think there's a better way of doing it.

#Edit2: Oh, and Thanks

----
#Edit3: (last edit for this post, I swear >.<) I don't seem to be getting the same results using 1280, and 720, though. See the screens below. You may need to view in fullscreen to see properly, I dunno.

Using Width & Height vars
[attachment=48363]
Using 1280 & 720
[attachment=48364]

The second one is still blurrier (?)

I had to zoom in to 225% to really notice the difference, yeah 2nd one is blurrier, but just. Shadows are sharper as is everything else in the Width & Height version. It's a lot harder to notice at default 100% zoom.

Edit:I cropper the pictures above so the difference can be noticed easily.

Width & Height



1280 x 720

m_base_width and m_base_height are always 320 and 240 so....I don't see the point of pulling that value from GPUDrawingEnvironment with all those extra included headers. You're basically just changing the base from 640x512 to 1280x720. Which is probably part of the reason that it looks better; you're basically doubling the "meaning" of scaling - ie. 2x upscaling is actually closer to 3 or 4x upscaling

The new "base" resolution however is 16:9 unlike the previous 5:4 ratio, which is a good change

edit: and it looks like you already noticed this lol >_>

Yeah, I had noticed as much. I failed at tested it last night (probably because it was like 5am lol), as I mentioned above, I had used the first two w/h vals in GetDisplayRect arrays to check if it was only using those, so it didn't produce the same results. So I said I'd do up a test build so I could go to sleep >.<

Edit: Side note though - you gave me an idea. Kind of separate to what I'm working on regarding the scaling atm, but: I think it could possible be a good idea to have a conditional outside of there for the width/height base values, to check if the selected aspect ratio is set to 4:3, or 16:9, and (if it sticks to using hardcoded vals) adjust the values based on the user selection. Chances are - if they're using the 16:9 aspect option, they've probably got the game widescreen patched. It's currently using 4:3 base values for a 16:9 output (if selected), which isn't really ideal.

How about just a printf to the console? You know, having the original method, asmodean's method and the (320x240) 1280x720 test. Then printf all the width/height results in one line.

*is too lazy to do it cuz he has to compile everything*

As for custom aspect ratio scaling, that's why I was thinking if it was worth it to have separate scaling.

mm....but I mean this stuff is not really that important because the user can just put in a "custom" resolution and see whatever works best for their particular game, all we're really doing is adjusting the definition of 2x upscaling, 3x upscaling, etc.