All cores video stutters slightly with update from 4.0.2 to either 4.1 or 4.2
-
@BuZz On the newer versions, I used the configuration editor, and on 4.0.2, I manually edited the file, if my memory serves me. Do you think that could have any bearing on this?
I was doing some searching, and I did see another thread where someone saw stuttering in emulation station as well as cores, and he determined it was the Steam controller support drivers that were added in version 4.1 of Retropie, and by uninstalling them, it fixed his problem. I am going to give that a shot tonight to rule that out.
https://retropie.org.uk/forum/topic/7828/stuttering-issue-across-all-the-distrib/10 -
@dukesilver the steam controller drivers are not installed by default.
How you edit the file shouldn't make a difference, but some default options may have changed. Also make sure the video mode is the same between installs (
tvservice -s) -
@BuZz I will at least check my syslog per the steamcontroller thread, to see if there is any evidence of other errors being logged, that could be causing the stutter. He also used 'display framerate' to detect a frame dip ever X seconds, which is probably similar to what I am experiencing.
I just did a search for 'tvservice' in the entire 'configs' folder of both the working and jumping systems, and did not see it. Where is that setting stored?
-
@dukesilver that is a commandline tool to tell you the current screenmode.
-
@BuZz 10-4, I will report back.
-
I ran tvservice -s while inside of emulation station. I checked that video mode was left unset, shown by (), in each emulator at start. To verify I ran it again while in lr-nestopia, and it was the same.
On the stuttering install:
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressiveOn the working install:
state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressiveI also verified that no steamcontroller drive is installed.
So, I will continue to investigate, and check the logs next, but as of testing both of these just now, one instance is stuttering, and one instance is working fine.
-
My investigation into the syslog did not find any obvious problems, but I do think there may be a larger problem with speed as a whole. I am hoping someone can try to replicate. Below testing is on the same pi, with the same 2.5A power supply, and the same 32GB Evo SD card, on the same TV.
On my working 4.0.2 build:
lr-nestopia runs flawlessly with a video_frame_delay of 6, as per Brunnis's recommendations for reducing input lag. No video stuttering in 240p test suite grid scrolling, or in games with scrolling such as Contra intro screen and Battletoads turbo tunnel.lr-snes9x2010 runs flawlessly with default settings. 240p test suite has no stuttering during grid scrolling, and Super Mario Allstars plays The Lost Levels without any stuttering or lag.
On my stuttering 4.2 build:
lr-nestopia runs well with default setttings, but a video_frame_delay of 6 make its stutter quite bad.lr-snes9x2010 produces HORRIBLE stuttering in the grid scrolling via 240p test suite, and Super Mario Allstars is unplayable during The Lost Levels, due to 1-2 frame freezing and lag. I can not beat the first level.
lr-snes9x2005 seems to be fine, with no noticeable stuttering.
-
No problems for me with Super Mario All-Stars playing the Lost Levels in Snes9x 2010 1.52.4 b2a69de
-
I played a bit more and I see some jitter for sprites, but only because I was overanalyzing everything. The game was still looking great and was totally playable.
How does it work "out of the box" with no video tweaks at all? I've done literally nothing to my two Pi 3s that are connected to TVs in terms of video settings aside from setting overscan and forcing HDMI audio, and they work great. It's sounding like you've "fiddled with the knobs" so hard trying to make a test suite run perfectly that now games are suffering.
-
@obsidianspider Tonight I will do a clean install of 4.2 and do nothing other than uploading the rom to verify, but all I did for last nights testing was set video_threaded to false and video_driver to dispmanx. No other changes were made, besides testing the video_frame_delay in the nes-specific retroarch.cgf file. Just to rule out any outside influence though, I will leave the video driver to gl and threaded video to true and see what that gets me.
For me, on The Lost Levels, it was stuttering so badly, that it was just not playable. Mario would freeze midair for 1-2 frames, every few seconds. If you didn't experience that, than there is something definitely going on with me changing the video driver or video threaded.
-
@dukesilver If there's a variable/setting you want me to confirm, let me know, but yeah, as far as I know, my stuff is default.
-
@obsidianspider Just to humor me, would you be willing to try dispmanx for video driver and video threaded to false.
-
@dukesilver oh yeah, dispmanx and threaded video off makes that game run like total garbage.
Running with just dispmanx as the driver makes it better, but it is a bit jerky.
Going back to threaded video on and gl as the driver is much better. Is it 100% perfect? No, but it's more than acceptable to me.
-
@obsidianspider Great for diagnosing the problem, crappy for me trying to reduce input lag. Brunnis discovered that changing to dispmanx from gl saves 1 frame of input lag, which is great. So it looks like something changed with the driver from 4.0.2 to 4.2. I may open up an issue in git at some point, but for the sake of this thread, after I confirm your findings, I think we can close this.
Thank you for working with me to help figure this out.
-
@dukesilver I've tried to minimize lag in the past and it ended up being a giant pain in the rear. I turned game mode off and went back to default settings. For most games it's totally fine for me. When I obsess over things like that I tend to forget what the heck I'm trying to do, which is play and enjoy these games. But I get it, I've been there. I spent around 30 hours trying to figure out why a kernel update broke a script to drive the second screen on my Super Famicom Pi.
-
@Brunnis , care to look at these findings? I know you did a bunch of research on input lag and determined that dispmanx and video_threaded = false worked great at reducing input lag, but with version 4.1 and 4.2 of retropie, it stutters so bad it's not playable. Any thoughts?
-
@dukesilver Please wait before opening issues on our issue tracker. We cannot be responsible for bugs in every single 3rd party piece of software we ship with, and the issue tracker clearly says to use the forum (It doesn't mean open a thread on the forum, and in 2 days time open a ticket ).
The dispmanx driver in retroarch had some changes that removed the triple buffer which may be related.
https://github.com/libretro/RetroArch/commit/0b75671c21ec1e891779031b6435ad18debe3e60
You will need to open an issue there. They may want you to build RetroArch and test before/after the changeset.
-
@BuZz I see that now, I was only trying to help and follow the rules, that's why I waited and tried to do as much research and post here first. I didn't know enough of the software to realize it was due to a 3rd parties change.
-
did this get resolved? I have a slight stutter as well on the newest 4.4.4 clean retropie install:
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.