What the...I can make hacks sliders go beyond the limits with cheats

[vsub]

I was doing some experiments and I notest something strange

1.The game is Van Helsing(that game gain huge speed boost from VU Stealing)...no need to run the game first...
2.Open the settings,set the VU Stealing to 3(hit apply) and search with your memory searching program(Cheat Engine\ArtMoney)for 3,change it to 2 and search for 2,change it to 1 and search for one.At the end you will endup with two addresses,one that is changed when you hit apply(you need that one)and one that is changed while moving the slider.
Each time I increase the value by 1 and press F6,I get even more speed(I don't know if it's false...pcsx2 and bandicam says otherwise)

This will probably have the same effect on the EE slider

Is this something expected(probably yes)

[willkuer]

You can as well increase the values in the ini file.
I think what you observe is expected.

The extreme stealing and underclocking were features Rama once enabled to satisfy some users.

[Blyss Sarania]

I didn't know you could do VU stealing that way in the ini. I thought it was only EE cyclerate.

[willkuer]

Well it is some time past since Rama implemented it but I think it concerns both sliders. Let me have a look into the source maybe I can validate that.

Edit: I haven't found a limit. The value is read from the ini and then later used without a max-limit. I am currently on mobile so maybe I oversaw something but I guess neither in microvu nor in supervu it is limited.

[Blyss Sarania]

Ini wise again I only know of the EE one, which can take values 1-99. At least ini wise it's capped at 99 by this code in iR5900-32.cpp :

Code:

-            if (EmuConfig.Speedhacks.EECycleRate > 2 && EmuConfig.Speedhacks.EECycleRate < 100) {
-                scalarLow *= EmuConfig.Speedhacks.EECycleRate;
-                scalarMid *= EmuConfig.Speedhacks.EECycleRate;
-                scalarHigh *= EmuConfig.Speedhacks.EECycleRate;
-            }

[willkuer]

Yes for ee the limit is obvious. For vucyclesteal you can have a look here.

One can see saving and loading of the value but everywhere the cycle steal is just multiplied by the requested cycles. If github found all instances there shouldn't be a limit. Maybe there should be. Possibly this can lead to out of range values.

OK I am stupid. Exactly the first instance I linked showed that loading of vu cycle steal from the ini is limited to be between and excluding -1 and 4 and is reverted in case of out of bounds values. Github search just didn't show the reassignment and that's why I haven't seen it first.

But afterwards it is not checked anymore and that is the reason why vsub can apply larger values.

At least that are all instances that github search found. Obviously it does not find all instances..


Does anything funny happen if you increase it further? Maybe using 10 or 100?

[ssakash]

there is no limit present for VU stealing , it gets saturated to the slider values only after using the slider. unless otherwise you could pump it up to your interest to increase the cpuRegs.cycle (INI files)

[Blyss Sarania]

there is no limit present for VU stealing , it gets saturated to the slider values only after using the slider. unless otherwise you could pump it up to your interest to increase the cpuRegs.cycle (INI files)

Not from the ini file. As willkuer pointed out, this code:

Code:

    if (Conf.Hacks.VUCycleSteal < 0 || Conf.Hacks.VUCycleSteal > 4)

in ini.cpp prevents it.

[willkuer]

I am not exactly sure though...
The amount of macros is crazy. And somehow macro names seems not always to be very helpful. And typically for c++ functions coming out of nowhere. One should still say that I am on mobile and github is not exactly made for code analysis on mobile...

Still the api/loadconfig seems to request the vu cycle stealing in the mentioned function (doConfig). VU cycle stealing is only checked against validity onLoad. Thats different to ee cycle rate which is checked on application. So vu cycle stealing can be manipulated as you like (after config load) but ee cycle rate will revert your manipulation. If you would like to overcome the 100 barrier you need to manipulate the low/mid/high-scalars instead.