(01-31-2015, 04:10 PM)rama Wrote: Well, I want the feature in a basic form (but easy to implement).
Our cycle counting isn't exact enough and we haven't found an idea yet on how to make it better.
(The problems are superscalar EE and unknown at recompile time memory latencies.)
By adding the overclock feature, I can better test and debug cycle counting.
I'm just not sure it should be exposed to regular users now. The feature can very easily lead
to misconfiguration when people try to "optimize" everything (and that's what we regularly see).
i agree to leaving that overclock out of the UI. i dunno how this scalar stuff is used anyway. i guess i have to stick my nose in the machine again and follow it. but the point is if it's generally overclocking like some 700Mhz EE it's seriously raising the need to emulate the speed. it might speed up the games run slow on the hardware. but on "faster" games it might spend useless time - however - even if it might spend "empty" cycles on sync points. but i have no clue how "empty" would be done. cause i haven't the sync points in my head. the obvious last instance is running at 60fps. ofc.
[babble]
timing and sync is seriously confusing sometimes. i mean target is to run all as fast as possible til you flip the frame and hopefully have everything rendered in that 16ms to get the stable 60fps on monitor absolute. i know SOC doesn't do that. but i can't picture the timing relation between real ps2 fps on that offset V/S with that "wrong emulated speed" fps on V/S on pc monitor. so... yeah... i gotta seriously look in the machine. and pcsx2 has gotten like a lil closed box with just a couple holes to me. this' me so bad not actively coding tho. i'll look it up.
[/babble]