Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update NewEmuChecklist.txt #34

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update NewEmuChecklist.txt #34

wants to merge 1 commit into from

Conversation

rzumer
Copy link
Contributor

@rzumer rzumer commented Jan 23, 2019

Proposed changes.

  • Add memory mapping method requirement
    Memory maps on some systems are complex, so it should be clear that the memory mapping method is well-researched.
  • Fix inconsistent entries
    "Fast-forward" was there twice, so cut the redundant entry and reword the slowdown item for consistency

On a side note I think GB systems need their memory mapping method reviewed, based on what I have heard about paging issues. It would be nice if there were a way to solve that without breaking compatibility.

* Add memory mapping method requirement
* Remove redundant entries
@Jamiras
Copy link
Member

Jamiras commented Jan 26, 2019

While Fast Forward and Speed Up provide similar functionality, they're typically two different features in the emulator.

Speed Up allows you to adjust the speed to 2x, 3x, 4x incrementally. Fast Forward removes any delay provided by the emulator and runs as fast as possible.

Fast Forward is usually only active while holding a button down, whereas Speed Up remains in effect until the player resets speed back to normal.

With this distinction, Slow Down is not a separate option and decreasing speed is handled by the Speed Down clause.

@rzumer
Copy link
Contributor Author

rzumer commented Jan 26, 2019

I remember you brought that up before, but to me this definition of "fast forward" is not clear. That said, regardless of the wording, the distinction seems meaningless for the checklist since a clear indication that "faster than real time" speed is allowed in hardcore (as opposed to "slower than real time") covers all situations. It seems redundant to have two separate entries for what is essentially the same functionality where in one case the speed-up factor is capped and in the other it is not. If the distinction must be so fine-grained, then I suppose we should add additional lines to cover over- and under-clocking.

@meleu
Copy link
Contributor

meleu commented Mar 19, 2019

This discussion here and that recent one in the forums made me think that we shouldn't allow speed-up fine adjustments, but only the "as fast as possible" function (in hardcore mode).

But as I don't have enough knowledge about the implementations, I'm not sure if it would be possible to allow "as fast as possible" and block "speed up adjustments".

While unsure, I agree with @rzumer's argument here:
in the hardcore case, if slowdown / "speed below 100%" is not allowed and fast-forward / "speed above 100%" is allowed, then listing all of them sounds redundant to me.

@Jamiras
Copy link
Member

Jamiras commented Mar 19, 2019

In most emulators, fast forward removes the frame limiter entirely and the system runs as fast as possible - on some systems, this could by 0% faster, whereas on others it could be hundreds of times faster.

My phone runs RetroArch/SNES at 95%, so FF does nothing for me there, but it does give me about a 75% boost in speed in RetroArch/NES. One could even argue that that 5% speed penalty I'm getting for running on old hardware is cheating, but playing with a touchscreen is already difficult enough, so I do almost all of my achievements on my PC.

Adjusting speed changes the framerate from the default to something else. i.e. 60 fps => 90 fps = 150% speed. 60fps => 30fps = 50% speed.

Even if these aren't separate functions internally, the mechanisms to activate them are, and that's usually where we put the hardcore checks (i.e. on pressing the key or choosing the menu item). In fact, that's exactly why I've chosen to list them separately. I expect speed up to have to be handled separately from fast forward, so there's separate checkboxes.

Speed-up has been allowed because it behaves like fast forward. However, I would agree that having a fixed sped slightly faster than normal does feel like more of an advantage than an uncontrollable burst of get-through-this-boring-thing-as-fast-as-possible.

Treating speed-up differently than fast-forward warrants having them as separate items. However, if we do decide against speed-up in hardcore, speed-up and speed-down could be merged.

I plan to finish rolling out the existing emulators using the current checklist. If we have a consensus, we can make appropriate changes with the next set of releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants