Fast Forward about mupen64plus HOT 17 CLOSED

I will get around to this, it's really simple.

[deleted comment]

okaygo's implementation of fast-forward so far is to reduce the time between 
vi's
depending on a percentage, e.g. 100 is normal running speed (100%), 150 would
increase the speed (reduce the amount of time between vi's) by 50%, etc. 
Although
this works, on systems such as mine, my CPU can't handle rendering much faster 
than
100%. I think it would be nice for people with slower machines, if fast forward
looked more like when you fast-forward a DVD, i.e. instead of showing smooth 
motion
very quickly, it skips through the frames at a certain rate.

I know this is more involved and I'm not sure if it's even possible (but I 
think it's
worth looking into). Basically, in fast-forward mode, the core would process 
all ROM
instructions, but it would not issue a request to the graphics/RSP plugins to 
render
every frame. It would only call out to the plugins every nth frame. This would 
result
in slower systems being able to support fast-forward since the system would not 
have
to be processing all the graphics at a faster rate.

I'll post this to the mailing list too.

This is actually not really simple.  It's hard to do correctly.  I moved your 
rev 178
fast forward code onto a branch because it doesn't work.  On my system it could 
not
cause any increase in speed, but it could slow it down.  However it slowed it 
down by
putting gaps in between sound chunks.

Flow control in an audio/video multimedia system like this is actually 
difficult to
do right.  Our eyes aren't very sensitive to small amounts of jitter in the 
video
playback, but our ears *are* very sensitive to jitter in the sound.  So the most
common way of handling this problem is to allow the audio to drive the entire 
chain.
  That's how the speed is normally controlled in Mupen64Plus - if it weren't you'd
hear pops in the sound.  Since we want to have very high quality playback in
Mupen64Plus, we have to put the speed control in the audio plugin.  It could be 
done
fairly easily by just resampling the sound to match the playback speed, but this
would have the side effect of causing the pitch to go up or down.  It would be
better, though more complicated, to also do a pitch conversion to maintain the 
same
pitch.

This is all complicated but necessary to get a really high quality feature.  It 
would
be possible however to get it running pretty quickly if the human interface were
changed so that rather than adjusting the speed in 5% increments, it only 
allowed a
2x or 4x or whatever fixed value you like increase in speed.  It would be like 
a VCR
fast forward button - just run forward at a fixed rate.

The adjustable interface is neat but it may not be very practical for users when
they're actually playing the game.  It might be more user friendly to have an 
on/off
button for fast forward.  Comments?

The way I implemented it is the way all other emulators do it, I don't have many
intentions of making a 'system' out of this. Like I said, you need to DISABLE 
audio
sync if you want this to work. This is done by, a) not using an audio plugin 
(dummy
audio), or b) disabling the syncing feature in jttl's audio (possible by 
modifying
the config).

I tested with the "Disable Sync" feature in both enabled and disabled states.  I
wouldn't be surprised if it worked fine with the dummyaudio, because the audio 
sets
the pace of the emulator.  That "Disable Sync" option seems to be mislabeled - 
the
actual mupen64.conf key is "NoAudioDelay".  It's not about audio/video
synchronization, it's about the amount of buffer latency between the frames and 
the
audio output.

Does your current code correctly adjust the game speed on your system with sound
enabled and no stuttering?  I believe that it will be necessary to resample the 
sound
in order to achieve this.  If you don't want to write the necessary code, we'll 
just
leave the branch in SVN and I'll do it for a later version.

Did you test it by changing the config for the audio plugin. NMN coded a 
feature in
the plugin, its in the settings. Read about the changes for it... It works fine 
on my
box.

I see what's happening now.  Tonight I tested the speedchange branch with this
jttl_audio config setting.  The method that you have devised sort of works but 
it has
a couple of problems.  The TIME_COMPENSATION audio config setting allows you to
disable the speed gate inside the audio plugin, so that you can gate the speed
instead in the vi interrupt routine.  This does work acceptably in fast mode, 
but it
has problems in either normal speed or slow mode.  In slow mode there are gaps
between sound chunks, or no sound at all.  And in normal speed mode you can hear
small pops or gaps in the sound as you play the game.  The reason for this is 
that
the speed limiter in the vi interrupt is clocked off of the SDL timer (some 
system
timer), but the sound output is clocked off of an internal sound card timer.  
Since
these clocks are not synchronized, and the vi interrupt code is not adjusting 
the
speed by the audio buffer high/low marks, the audio buffer will run empty or 
full and
cause small audio artifacts.

This is why there should be only one speed limiter, and it must be controlled 
by the
audio output buffer levels.  It actually could be implemented fairly easily in 
the
following way:

1. Use the original speed limiter code in jttl_audio.  I already removed NMNs 
changes
in the trunk because the default TIME_COMPENSATION value was causing severe 
stuttering.

2. Remove the speed limiter code in the vi interrupt.

3. Add a new API call to the audio plugin to adjust the speed

4. In this new API call, set a value which will be used to modulate the 
'frequency'
variable inside of my_audio_callback.

By using this method the playback will be smooth with no blips no matter what 
speed
it is set to.  I'd like to add this myself because there is a lot of code which
should be cleaned up.  I should be able to do it this week.

I like your implementation, however it only works if SOME settings are correct, 
its
hard to know which settings are correct, is there a way to change this? This 
also
brings up the issue of making a configuration GUI for jttl's audio.

I tested slow, normal, fast, and fast forward modes with both linear and sinc
resamplers and it worked properly in all cases.  If you can give me a 
combination of
settings which does not work, and a description of the specific problem, I'll 
take a
look at it.

This feature is present in the trunk as of rev 219.