#12560 closed defect (fixed)
[FM Towns] scrolling much too slow (commit fb8f10840292ca2f678d4414815ff9578205656c)
Reported by: | michas0602 | Owned by: | athrxx |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | scrolling | |
Cc: | Game: |
Description
Regarding commit fb8f10840292ca2f678d4414815ff9578205656c :
On Rpi with AdvMame3-scaler, scrolling is much too slow now here...checked with Indy 3 and Zaks intro.
Smooth but way too slow - Indy is in the right and breaking into the waggon while the scrolling view is still way more left. Same for intro of Zak, view moves too slow
Change History (6)
comment:2 by , 4 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
I have now made a minor change that should at least bring the scrolling back to the state it was before.
Unfortunately, the really smooth scrolling (without skipping any frames for necessary catch-ups) is now gone even for fast platforms. I found the necessary changes too elaborate to include them in this fix. But I'll try to implement that soon. Of course, I can't make any promises for all target platforms...
comment:3 by , 3 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
This is still a regression to me, on an up-to-date HEAD.
I have some slower machines (such as an older PowerBook where I do some big-endian tests and patches) and the smooth scrolling is still really slow on older devices (I haven't tested it on some ports such as PS3 or Dreamcast, but I fear that it would be a problem there too).
On my modern machines, it's quite OK, unless I need to use Ctrl-F in-game to quickly test something: then the new scrolling mode makes the Fast mode slow and thus mostly useless.
I'm not a big fan of having a knob for everything, but could it be possible to have an option to disable this, at least for these use-cases? As has been done for trim_fmtowns_to_200_pixels, for example. I think several users will see this problem, otherwise.
Thanks.
comment:4 by , 3 years ago
I have disabled the scrolling for the fast mode (Ctrl-F). It really makes no sense there.
Just to make sure that you have read what the ticket is actually about: do you get smooth, but very slow scrolling (like in the ticket description) on your older hardware? Or do you just get jerky scrolling (which would be the behavior I'd expect)?
Yes, I could add a option like you suggested. Or I'll probably just disable the smooth scrolling for slow machines. Currently I have only one fallback in place: If your machine (or filter setting) is too slow for the totally smooth scrolling you'll get the jerky scrolling instead which still looks fine if your machine is just a bit too slow. BUt I might just another fallback which sets the scrolling back to the 8-pixels-strip based SCUMM scrolling.
comment:5 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I have added the requested check box to the engine tab, since even on a fast machine people might want to turn that off. And it allows easier experimenting with filter settings, since these seem to be mainly responsible for slow graphics updates...
comment:6 by , 3 years ago
@athrxx: Thank you very much for these two changes. I confirm that this is exactly what I was looking for!
As for the effect, well I don't really know how to describe it. The characters just start walking in heavy slow-motion while the smooth scrolling happens (e.g. Zak moving through his apartment), and once it's done scrolling they walk at their normal pace again. I find this very disturbing and I can't unsee it, but it's maybe a matter of personal taste since I tend to dislike most smooth scrolling or high FPS in general. Thanks for the new checkbox, then :)
(Of course yeah, the smooth scrolling makes the intro to Zak more exact and that's very nice, but I prefer choosing the old 8-pixel-scrolling).
OK for me then, thanks!
Thanks for the report.
I basically removed the catch up mechanism for cases where the machine is too slow to keep up with the 60 Hz full screen updates that are required for the scrolling. Apparently, that was a bad idea (which isn't much of a surprise really, no idea what I was thinking).
I'll revert that part of the commit and come up with a solution that still tries to keep the scrolling smooth for platforms that can manage it.