Fast-forward function

[ebenblues]

I posted about this on the google group, but didn't get a response, so I'm posting here for a larger audience.

So far, the design for fast-forward is to simply remove any delays between screen refreshes in the emulator. Although this works, on systems such as mine, my CPU can't handle rendering much faster than at 100% speed so fast-forward
doesn't have much of an effect. I think it would be nice for people with slower machines, if fast forward looked more like when you fast-forward when watching a DVD, i.e. instead of showing smooth motion very quickly, it skips through the frames at a certain rate.

Basically, in fast-forward mode, the core would still process all ROM instructions, but it would not issue requests to the rendering/audio plugins for every single frame. It would only call out to the plugins every nth frame (depending on the fast-forward speed). This would result in slower systems being able to support fast-forward since the system would not be processing the same amount of graphics/audio as it does during normal gameplay.

Before looking into if this is even possible, I want to get feedback on whether people would like this behavior or not. I think fast-forward is mainly used to skip through cut scenes in games, but are there other uses of fast-forward that wouldn't work well with the new fast-forward behavior?

 

[nmn]

Sounds pretty neat, You couldn't just turn off the frame limiter since just about every plugin is additionally serving as a frame limiter so this idea does sound pretty good for implementing it. I wouldn't make it a high priority, But hey, I love that Mupen64 is getting all of this innovation lately.

I think audio may be an issue, though. I was having trouble today involving frequencies...

 

[Richard42]

I doubt many people would actually want to play the game in fast forward mode. You may not get a huge speed benefit from this method since the R4300 emulation takes the majority of CPU time unless you have a slow graphics adapter. But if you can find a way to do it, it's probably worthwhile. You may also want to have a top speed cap just so in a few years if we have much faster CPUs it won't be unreasonable. I still remember trying to play the original Wing Commander on a 486-DX2-66. Instant death.

 

[Surkow]

This is something I've been waiting for. For example when I want to start a new savegame in LOZ - MM I want to scroll through the beginning. Or when I'm playing SSB and I want the matches to start without waiting. Last time Richard42 said the speed of a game was limited by the sound plugin. Would the sound still work when using fast forward?

 

[nmn]

I can imagine this true (Though audio sync can be disabled I think that has no effect. In SVN I did add TIME_COMPENSATION to the JTTL audio plugin, setting it to zero will stop any and all syncing) but If the RSP doesn't feed all of the frames to the plugins, they can not limit the speed. Imagine it like this: instead of doing 1 loop, calling the audio and video and input plugins, You do multiple loops, then call the plugins. If the plugins don't get called, they can not limit the speed of the emulator, especially since the frames skipped never see the plugins. If you skip one frame like this, the graphics plugin and audio plugin's FPS will still be the same, but they'll be getting every other frame's data.

 

[ebenblues]

Thanks for the feedback. From the replies it seems like this is an idea worth looking into. My opinion is that sound isn't necessary while fast-forwarding.

 

[Chromar]

is there a fast forward in PJ64? for something like NPC's talking that you've seen a millions times and wanna skip it.. like in Zelda OoT, when the deku tree tells the story. I hate sitting through it.. lol Has anything been added at all??

Updated: Found it, nevermind

 

[Beth641]

Thanks for the feedback. From the replies it seems like this is an idea worth looking into. My opinion is that sound isn't necessary while fast-forwarding.

very good opinion.. but in some cases you need it..