Menu
▾
▴
[fuse-emulator-devel] [ fuse-emulator-Bugs-2688741 ] speed estimation does not work
|
From: SourceForge.net <no...@so...> - 2009-03-27 12:41:42
|
Bugs item #2688741, was opened at 2009-03-16 15:26 Message generated for change (Comment added) made by szaszg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=596648&aid=2688741&group_id=91293 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gergely Szasz (szaszg) Assigned to: Nobody/Anonymous (nobody) Summary: speed estimation does not work Initial Comment: Start fuse with a 'screen stress' (e.g. opium4k demo), select HQ3x scaler. (do some nice and/or stress your system with some heavy thing..) Now the sound become fragmented and the screen update slow down... so emulation speed must fall under 100%. But the speed-o-meter show 100% and just after 20 or more secs. jump up e.g. 200% - 400% or even higher... ---------------------------------------------------------------------- >Comment By: Gergely Szasz (szaszg) Date: 2009-03-27 12:41 Message: Hmm.. there is some `theoretical' question: 1. what is `current_speed'? Now, this is a 10 second simple moving average, far for a real 'current_speed' 2. what is SPEED_TOLERANCE? Now, this is mean the deviation of the above moving average IMHO we can use a different 'current_speed' definition for rzx and display. For display, we can use the rate of the `frame time' and `expected frame time' (because the timing is work at frame base). And for rzx recording, we may use some well defined average speed... BTW: this RZX SPEED_TOLERANCE is Fuse specific, or there are some `international' standard for it? ---------------------------------------------------------------------- Comment By: Fredrick Meunier (fredm) Date: 2009-03-27 09:02 Message: Changes look good, though I think we need to retain the assumption we are running at the desired speed with less than 10 samples as we otherwise expose the accumulation of sound latency to the competition mode code breaking that e.g. on startup on my machine I see the estimated speed shown as 110% which decays down to the desired 100%, if I were using compo mode this would break the recording which limits deviation from 100% to 5% (see SPEED_TOLERANCE in rzx.c). ---------------------------------------------------------------------- Comment By: Gergely Szasz (szaszg) Date: 2009-03-23 00:31 Message: Here is a patch to solve this problems: changes: - fix the wrong calculation method - change the speed estimation base to 10x0.5 sec instead of 10x1 sec - estimate the speed during the `start-up' period (first 10 sample) - we get times in seconds, so we do not need to divide `difference' by 1000.0 - fix - we do not need to calculate `speed' every time - move to that block, where we need it File Added: fuse.timer_01.diff ---------------------------------------------------------------------- Comment By: Gergely Szasz (szaszg) Date: 2009-03-17 19:46 Message: Hmm.. the speed calculating arithmetic is the opposit of the needed :) We have to use `current_speed = 10 * 100 / ( current_time - stored_times[ next_stored_time ] );' instead of `current_speed = 10 * ( current_time - stored_times[ next_stored_time ] );' But the timing code has some misfunction too: at 100% speed, the `machine 10 sec' is 9.95-9.97 real sec instead of 10.0 at 50% speed the `machine 10 sec' is 22.18-22.63 real sec instead of 20.0 at 200% speed the `machine 10 sec' is 6.62-6.68 real sec instead of 5.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=596648&aid=2688741&group_id=91293 |