Overclocking the EE (discussion) (testers wanted)

[Nobbs66]

on master, just change EE cycle rate to s8 to use negative values and customize directly through ini files and change the range at the conditional operator place to accept negative values at the one which rama implement and, it should work.

You realize not many people want to go into the source just to have an EE overclock right?

[Lagahan]

Just wanna say thanks for this, posted asking for it a while back in the suggestions thread and it was thought to be more likely to crash everything than do any good, glad to see it ends up actually improving some games!
So; I tested a few games:

GTA Series: All internally capped at 25fps like the PC versions to keep the physics in check.

Killzone: Massive increase in requirements (was already EE heavy) and a very slight improvement in smoothness. Too hefty to really try and improve, game chugs in botmatches with 20% EE OC, though I got it to 60fps with only 2 bots at 30% EE OC.

Quake 3 Revolution: Was an easy to run game to start with, though internal FPS was bad. Can run up to 50% OC EE and internal FPS improves dramatically too, I'd say, higher than 60fps internal with no bugs. Great stuff for the 4 player splitscreen, I'll have to get a few lads round to test it out!

Need For Speed Hot Pursuit 2: Internally capped at 30fps, had the EE OC at 50% (PCSX2 still 100% speed) with VU Cycle stealing at max and it wouldn't go past 30.

Need For Speed Underground: Internally capped at 30fps too, pretty much the same as HP2 but more intensive to run.

Ratchet & Clank: Sits at a steady 60fps with a 20% EE OC in locations where it would otherwise chug a bit down to 30-45fps! Pitty HW GSDX is broken still

Run Like Hell: Internally capped at 30fps. Tested with 50% EE OC, VU cycle stealing max. Game still ran 100% but framerate didn't improve.

Conflict Desert Storm: Huge improvement at only 20% EE OC. This game chugged at default EE clock, the PS2 version was horrible for framerate drops. Hard to judge any further improvements since it only works with GSDX Software rendering and thats already saturating my CPU a fair bit.

WipEout Fusion: Big improvement in scenes where the original game chugged; ie Florian Heights 3 reverse when you jump over the city, its a balancing act but 30% improves the chugging a fair bit. Doesn't eliminate it entirely.

[Eiodalin]

I would like to test out the Armored Core (Specifically Last Raven the Most) series I have, as well as Ace Combat games.

[Blyss Sarania]

The download is some pages back.

Meanwhile because of some renewed interest and good test results I'm gonna clean up my work and make a PR to try to get it in the main version.

[Lagahan]

Awesome!
Would it be possible to add the same amount of granularity to the EE downclocking as with the overclocking or is it hard coded to -33% and -50%?
There's always that odd game that is maybe 5 fps too slow for full speed but a 33% downclock is overkill for and results in very noticeably lower fps than original hardware.

Even if it could be changed it would be tricky getting the GUI right, maybe have default cyclerate listed as 0% OC in the slider and then positive (overclock) and negative(underclock) either side like this: (?)

[willkuer]

Since the clocks somehow allow floating point precision (how does this actually work @blyss?) One can possibly put a very fine slider moving percentwise (on codebase removing the switch and replacing it by a smooth function. If you have some basic coding skills you can do this by yourself.

[Blyss Sarania]

Awesome!
Would it be possible to add the same amount of granularity to the EE downclocking as with the overclocking or is it hard coded to -33% and -50%?
There's always that odd game that is maybe 5 fps too slow for full speed but a 33% downclock is overkill for and results in very noticeably lower fps than original hardware.

Even if it could be changed it would be tricky getting the GUI right, maybe have default cyclerate listed as 0% OC in the slider and then positive (overclock) and negative(underclock) either side like this: (?)

First: Adding more granularity to the downclock is indeed possible, and actually a pretty good idea. I will look into that. Problem is:
Second: Yeah I know it's nasty for left(negative) to be OC and right(positive) to be UC. But it was done that way to keep compatibility with current ini and preset settings, and I don't know of a way to do it with OC on the right(positive) which does. Unless some crazy conversion code is thrown in, but devs won't like that

@willkuer The scalars being floats only works(I think) because some maths ultimately truncate/round them to integer. The scalar defaults are ~3,5,3 or so, and it's towards 0 that becomes an overclock(they are cycle delays, so 0 is as low as they can go). So I only have "space" between 0 and 3 on scalar low and high and 0 and 5 on scalar mid. That's not much leeway to do stuff, which is why I eventually went with floats.

[willkuer]

But there is a really a difference between 2.5 and 2 for the scalers? So they got somehow multiplied with something and later truncated?

[Blyss Sarania]

But there is a really a difference between 2.5 and 2 for the scalers? So they got somehow multiplied with something and later truncated?

There is definitely a difference. I actually figured there wouldn't be, but in my testing with PS2 SNES emulator they definitely work and 2 is definitely different from 2.5 which is different from 3. I'm not exactly sure how, I'm not familiar enough with the timing codepath to follow it and see. But it does work

[ssakash]

First: Adding more granularity to the downclock is indeed possible, and actually a pretty good idea. I will look into that. Problem is:

while knowledgeable users could customize through the INI file to allow higher scalar values, the newbies would probably say " EE CYCLERATE gave me 20+fps before, why you only give me 5 FPS NOW !! ? "

[/quote]
Second: Yeah I know it's nasty for left(negative) to be OC and right(positive) to be UC. But it was done that way to keep compatibility with current ini and preset settings, and I don't know of a way to do it with OC on the right(positive) which does. Unless some crazy conversion code is thrown in, but devs won't like that
[/quote]

I'd also personally prefer it being the right side, it's easy to code. just modification needed for the switch-case statement. It wouldn't cause any conflicts on the INI file, the user could change it anytime in the GUI if he wants, so there would be no problem.

The presets could also be changed accordingly, so there should be no problem.