Screen tearing after playing Zelda LTTP for multiple hours. [Fixed]

User avatar
ItalianGrandma
Posts: 132
Joined: Sun May 24, 2020 7:09 pm
Has thanked: 17 times
Been thanked: 22 times
Contact:

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by ItalianGrandma »

I have seen some tearing as well in various games, but it was on my AOC monitor and it’s happened with NES, SNES and I believe other cores as well. It’s very intermittent though, and I’m not sure what steps I could take to reproduce it. I know when it did happen, I wasn’t playing for four hours and a reboot always fixed it. I’m also fairly certain I’ve seen it with both vsync=0 and vsync=2.
AtomicShroom
Posts: 170
Joined: Sun Mar 07, 2021 12:28 pm
Has thanked: 31 times
Been thanked: 48 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by AtomicShroom »

rhester72 wrote: Thu Jul 01, 2021 12:39 am @AtomicShroom: Can you specify one game that exhibits this even when not being actively played so we can duration-test ourselves (without playing for 4 hours)?
I tried with Super Mario World this morning and I was able to reproduce it by just leaving it idle for around 4 hours. Since the demo scrolls to the right it’s very easy to notice.
paulbnl wrote: Thu Jul 01, 2021 8:45 am
Disconnecting and reconnecting the HDMI cable should have fixed it if the problem is in the TV. The problem is in the MiSTer scaler. I have reproduced it after leaving the Zelda intro running over night with your settings (vsync_adjust=0, 720p).

The normally dropped frame is replaced by a moving tear from bottom to the top every 10 seconds. This indicates the scaler is selecting the wrong frame buffer. I have verified this by checking the latency. Normally the latency is 2 frames with vsync_adjust=0 but in this tearing mode there is only 1 frame of latency.

This is easiest to see with the grid scroll test in the 240p test suite. I am now leaving that running in 1080p to see if it happens in that resolution.
Thanks for confirming @paulbnl! What you’re describing is *exactly* what I’m witnessing.

Can this be fixed by the MiSTer team? Surely there is a way to output a signal that will not tear. I’ve played my SNES Classic for an ungodly amount of hours and never once have I seen it tear, and it’s also sending a 720p signal. So certainly the TV is not at fault here. There has to be a way for MiSTer to send a proper stable signal?
ash2fpga
Posts: 237
Joined: Tue May 26, 2020 6:20 pm
Has thanked: 62 times
Been thanked: 28 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by ash2fpga »

The scaler source is here:
https://github.com/MiSTer-devel/Templat ... /ascal.vhd

Not exactly a simple thing.

I started looking at the rescaling logic a bit a while back to try to understand it better, but I was only interested in reproducing a single frame, to compare against/verify PolyphasePreviewer results, and not anything temporal. (I still have yet to get back to that. :oops:)
paulbnl
Core Developer
Posts: 205
Joined: Sun May 24, 2020 8:48 pm
Has thanked: 18 times
Been thanked: 196 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by paulbnl »

AtomicShroom wrote: Fri Jul 02, 2021 5:55 pm Thanks for confirming @paulbnl! What you’re describing is *exactly* what I’m witnessing.

Can this be fixed by the MiSTer team? Surely there is a way to output a signal that will not tear. I’ve played my SNES Classic for an ungodly amount of hours and never once have I seen it tear, and it’s also sending a 720p signal. So certainly the TV is not at fault here. There has to be a way for MiSTer to send a proper stable signal?
Sure it can be fixed but so far it has been difficult to pin point the issue. Yesterday I left the 240p test suite running for 8 hours in 1080p mode without tearing. Today I have left it running for 10 hours at 720p without tearing.

Just now I left Super Mario World running for about 1.5 hours at 720p and it started tearing.

Either this is a coincidence or Super Mario World can trigger it and not the 240p test suite which would be very strange.
User avatar
jlancaster86
Posts: 147
Joined: Sat Jun 27, 2020 1:33 pm
Has thanked: 129 times
Been thanked: 35 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by jlancaster86 »

paulbnl wrote: Thu Jul 01, 2021 8:50 pm It is important to note that there are 2 different issues here:
  1. Tearing with vsync_adjust=0: Caused by MiSTer scaler. This is visible on all displays/capture cards.
  2. Tearing with Samsung and vsync_adjust=1/2. Caused by Samsung. Tip: Do not buy Samsung
Yeah, the two issues seem to be unrelated. I've created a separate thread for discussing the Samsung TV issue here.
User avatar
Grabulosaure
Core Developer
Posts: 78
Joined: Sun May 24, 2020 7:41 pm
Location: Mesozoic
Has thanked: 3 times
Been thanked: 92 times
Contact:

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by Grabulosaure »

@AtomicShroom
I really have no idea on what could cause tearing after hours. The scaler continuously selects the latest updated frame.

I've made a version of SNES with a "border" option which shows input video in the border of the scaled image. I'd be curious to know if the tearing is synchronised with the input video sliding :

http://temlib.org/pub/mister/SNES_border.rbf

With SNES NTSC mode, the skew compared to 60Hz output is around 1 frame per 10 second.
paulbnl
Core Developer
Posts: 205
Joined: Sun May 24, 2020 8:48 pm
Has thanked: 18 times
Been thanked: 196 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by paulbnl »

@Grabulosaure What I think is happening is that in some edge case 'o_ibuf0' and 'o_obuf0' become equal. The 'buf_next' function defaults to buffer 1 so when o_ibuf0 and o_obuf0 are equal then they both get stuck at buffer 1.

I had to wait a long time for it to start tearing again but I could finally confirm with SignalTap that they are both stuck at buffer 1.
User avatar
Grabulosaure
Core Developer
Posts: 78
Joined: Sun May 24, 2020 7:41 pm
Location: Mesozoic
Has thanked: 3 times
Been thanked: 92 times
Contact:

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by Grabulosaure »

paulbnl wrote: Sun Jul 04, 2021 9:00 am @Grabulosaure What I think is happening is that in some edge case 'o_ibuf0' and 'o_obuf0' become equal. The 'buf_next' function defaults to buffer 1 so when o_ibuf0 and o_obuf0 are equal then they both get stuck at buffer 1.

I had to wait a long time for it to start tearing again but I could finally confirm with SignalTap that they are both stuck at buffer 1.
i suspect the input and output synchro that triggers buffer swap occurring at exactly the same cycle. Something as stupid. Sorry :o

I'l post a tentative fix today.
User avatar
Grabulosaure
Core Developer
Posts: 78
Joined: Sun May 24, 2020 7:41 pm
Location: Mesozoic
Has thanked: 3 times
Been thanked: 92 times
Contact:

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by Grabulosaure »

@paulbnl
@AtomicShroom

I have posted an updated version of SNES which may fix the problem : End of input and begin of output during the same clock cycle.

http://temlib.org/pub/mister/SNES.rbf
http://temlib.org/pub/mister/SNES_border.rbf

Code: Select all

diff --git a/sys/ascal.vhd b/sys/ascal.vhd
index 2d21b35..f157e9f 100644
--- a/sys/ascal.vhd
+++ b/sys/ascal.vhd
@@ -383,8 +383,8 @@ ARCHITECTURE rtl OF ascal IS
   SIGNAL avl_fb_ena : std_logic;
   
   FUNCTION buf_next(a,b : natural RANGE 0 TO 2; freeze : std_logic := '0') RETURN natural IS
-  BEGIN
-    IF (freeze='1') THEN RETURN a; END IF;
+  BEGIN
+    IF (freeze='1') THEN RETURN a; END IF;
     IF (a=0 AND b=1) OR (a=1 AND b=0) THEN RETURN 2; END IF;
     IF (a=1 AND b=2) OR (a=2 AND b=1) THEN RETURN 0; END IF;
     RETURN 1;                              
@@ -401,7 +401,7 @@ ARCHITECTURE rtl OF ascal IS
   ----------------------------------------------------------
   -- Output
   SIGNAL o_run : std_logic;
-  SIGNAL o_freeze : std_logic;
+  SIGNAL o_freeze : std_logic;
   SIGNAL o_mode,o_hmode,o_vmode : unsigned(4 DOWNTO 0);
   SIGNAL o_format : unsigned(5 DOWNTO 0);
   SIGNAL o_fb_pal_dr : unsigned(23 DOWNTO 0);
@@ -1731,8 +1731,8 @@ BEGIN
       --------------------------------------------
       -- Triple buffering.
       -- For intelaced video, half frames are updated independently
-      -- Input : Toggle buffer at end of input frame
-               o_freeze <= freeze;
+      -- Input : Toggle buffer at end of input frame
+      o_freeze <= freeze;
       o_inter  <=i_inter; -- <ASYNC>
       o_iendframe0<=i_endframe0; -- <ASYNC>
       o_iendframe02<=o_iendframe0;
@@ -1746,7 +1746,12 @@ BEGIN
         o_ibuf1<=buf_next(o_ibuf1,o_obuf1,o_freeze);
         o_bufup1<='1';
       END IF;
+      
       -- Output : Change framebuffer, and image properties, at VS falling edge
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup0='1' THEN
+        o_obuf0<=buf_next(o_obuf0,o_ibuf0,o_freeze);
+        o_bufup0<='0';
+      END IF;
       IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup1='1' THEN
         o_obuf1<=buf_next(o_obuf1,o_ibuf1,o_freeze);
         o_bufup1<='0';
@@ -1755,6 +1760,33 @@ BEGIN
         o_hdown<=i_hdown; -- <ASYNC>
         o_vdown<=i_vdown; -- <ASYNC>
       END IF;
+      
+      -- Simultaneous change of input and output framebuffers
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND
+        o_iendframe0='1' AND o_iendframe02='0' THEN
+        o_bufup0<='0';
+        o_obuf0<=o_ibuf0;
+      END IF;
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND
+        o_iendframe1='1' AND o_iendframe12='0' THEN
+        o_bufup1<='0';
+        o_obuf1<=o_ibuf1;
+      END IF;
+      
+      -- Non-interlaced, use same buffer for even and odd lines
+      IF o_inter='0' THEN
+        o_ibuf1<=o_ibuf0;
+        o_obuf1<=o_obuf0;
+      END IF;
+      
+      -- Triple buffer disabled
+      IF o_mode(3)='0' THEN
+        o_obuf0<=0;
+        o_obuf1<=0;
+        o_ibuf0<=0;
+        o_ibuf1<=0;
+      END IF;
+      
       -- Framebuffer mode.
       IF o_fb_ena='1' THEN
         o_ihsize<=o_fb_hsize;
@@ -1774,25 +1806,6 @@ BEGIN
         o_stride<=to_unsigned(o_ihsize_temp2,14);
         o_stride(NB_BURST-1 DOWNTO 0)<=(OTHERS =>'0');
       END IF;
-      
-      IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup0='1' THEN
-        o_obuf0<=buf_next(o_obuf0,o_ibuf0,o_freeze);
-        o_bufup0<='0';
-      END IF;
-      
-      IF o_inter='0' THEN
-        o_ibuf1<=o_ibuf0;
-        o_obuf1<=o_obuf0;
-      END IF;
-      
-      -- Triple buffer disabled
-      IF o_mode(3)='0' THEN
-        o_obuf0<=0;
-        o_obuf1<=0;
-        o_ibuf0<=0;
-        o_ibuf1<=0;
-      END IF;
-      
       ------------------------------------------------------
       o_hmode<=o_mode; 
       IF o_hdown='1' AND DOWNSCALE THEN
PikWik
Posts: 256
Joined: Sat May 30, 2020 7:00 pm
Has thanked: 192 times
Been thanked: 71 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by PikWik »

BOOOM
MiSTer community to the rescue!

my next questions is, can this fix be applied to other cores?
seems like some folks would appreciate this, if this tearing with vsync_adjust=0 is a widespread issue
AtomicShroom
Posts: 170
Joined: Sun Mar 07, 2021 12:28 pm
Has thanked: 31 times
Been thanked: 48 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by AtomicShroom »

Grabulosaure wrote: Sun Jul 04, 2021 12:58 pm @paulbnl
@AtomicShroom

I have posted an updated version of SNES which may fix the problem : End of input and begin of output during the same clock cycle.

http://temlib.org/pub/mister/SNES.rbf
http://temlib.org/pub/mister/SNES_border.rbf

Code: Select all

diff --git a/sys/ascal.vhd b/sys/ascal.vhd
index 2d21b35..f157e9f 100644
--- a/sys/ascal.vhd
+++ b/sys/ascal.vhd
@@ -383,8 +383,8 @@ ARCHITECTURE rtl OF ascal IS
   SIGNAL avl_fb_ena : std_logic;
   
   FUNCTION buf_next(a,b : natural RANGE 0 TO 2; freeze : std_logic := '0') RETURN natural IS
-  BEGIN
-    IF (freeze='1') THEN RETURN a; END IF;
+  BEGIN
+    IF (freeze='1') THEN RETURN a; END IF;
     IF (a=0 AND b=1) OR (a=1 AND b=0) THEN RETURN 2; END IF;
     IF (a=1 AND b=2) OR (a=2 AND b=1) THEN RETURN 0; END IF;
     RETURN 1;                              
@@ -401,7 +401,7 @@ ARCHITECTURE rtl OF ascal IS
   ----------------------------------------------------------
   -- Output
   SIGNAL o_run : std_logic;
-  SIGNAL o_freeze : std_logic;
+  SIGNAL o_freeze : std_logic;
   SIGNAL o_mode,o_hmode,o_vmode : unsigned(4 DOWNTO 0);
   SIGNAL o_format : unsigned(5 DOWNTO 0);
   SIGNAL o_fb_pal_dr : unsigned(23 DOWNTO 0);
@@ -1731,8 +1731,8 @@ BEGIN
       --------------------------------------------
       -- Triple buffering.
       -- For intelaced video, half frames are updated independently
-      -- Input : Toggle buffer at end of input frame
-               o_freeze <= freeze;
+      -- Input : Toggle buffer at end of input frame
+      o_freeze <= freeze;
       o_inter  <=i_inter; -- <ASYNC>
       o_iendframe0<=i_endframe0; -- <ASYNC>
       o_iendframe02<=o_iendframe0;
@@ -1746,7 +1746,12 @@ BEGIN
         o_ibuf1<=buf_next(o_ibuf1,o_obuf1,o_freeze);
         o_bufup1<='1';
       END IF;
+      
       -- Output : Change framebuffer, and image properties, at VS falling edge
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup0='1' THEN
+        o_obuf0<=buf_next(o_obuf0,o_ibuf0,o_freeze);
+        o_bufup0<='0';
+      END IF;
       IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup1='1' THEN
         o_obuf1<=buf_next(o_obuf1,o_ibuf1,o_freeze);
         o_bufup1<='0';
@@ -1755,6 +1760,33 @@ BEGIN
         o_hdown<=i_hdown; -- <ASYNC>
         o_vdown<=i_vdown; -- <ASYNC>
       END IF;
+      
+      -- Simultaneous change of input and output framebuffers
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND
+        o_iendframe0='1' AND o_iendframe02='0' THEN
+        o_bufup0<='0';
+        o_obuf0<=o_ibuf0;
+      END IF;
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND
+        o_iendframe1='1' AND o_iendframe12='0' THEN
+        o_bufup1<='0';
+        o_obuf1<=o_ibuf1;
+      END IF;
+      
+      -- Non-interlaced, use same buffer for even and odd lines
+      IF o_inter='0' THEN
+        o_ibuf1<=o_ibuf0;
+        o_obuf1<=o_obuf0;
+      END IF;
+      
+      -- Triple buffer disabled
+      IF o_mode(3)='0' THEN
+        o_obuf0<=0;
+        o_obuf1<=0;
+        o_ibuf0<=0;
+        o_ibuf1<=0;
+      END IF;
+      
       -- Framebuffer mode.
       IF o_fb_ena='1' THEN
         o_ihsize<=o_fb_hsize;
@@ -1774,25 +1806,6 @@ BEGIN
         o_stride<=to_unsigned(o_ihsize_temp2,14);
         o_stride(NB_BURST-1 DOWNTO 0)<=(OTHERS =>'0');
       END IF;
-      
-      IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup0='1' THEN
-        o_obuf0<=buf_next(o_obuf0,o_ibuf0,o_freeze);
-        o_bufup0<='0';
-      END IF;
-      
-      IF o_inter='0' THEN
-        o_ibuf1<=o_ibuf0;
-        o_obuf1<=o_obuf0;
-      END IF;
-      
-      -- Triple buffer disabled
-      IF o_mode(3)='0' THEN
-        o_obuf0<=0;
-        o_obuf1<=0;
-        o_ibuf0<=0;
-        o_ibuf1<=0;
-      END IF;
-      
       ------------------------------------------------------
       o_hmode<=o_mode; 
       IF o_hdown='1' AND DOWNSCALE THEN
Holy hell that was fast! Thank you so much for looking into this and attempting a fix! 🙏🏻 It’s currenty running so I’ll report back with my results when I get back home tonight!
AtomicShroom
Posts: 170
Joined: Sun Mar 07, 2021 12:28 pm
Has thanked: 31 times
Been thanked: 48 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by AtomicShroom »

Grabulosaure wrote: Sun Jul 04, 2021 12:58 pm @paulbnl
@AtomicShroom

I have posted an updated version of SNES which may fix the problem : End of input and begin of output during the same clock cycle.

http://temlib.org/pub/mister/SNES.rbf
http://temlib.org/pub/mister/SNES_border.rbf

Code: Select all

diff --git a/sys/ascal.vhd b/sys/ascal.vhd
index 2d21b35..f157e9f 100644
--- a/sys/ascal.vhd
+++ b/sys/ascal.vhd
@@ -383,8 +383,8 @@ ARCHITECTURE rtl OF ascal IS
   SIGNAL avl_fb_ena : std_logic;
   
   FUNCTION buf_next(a,b : natural RANGE 0 TO 2; freeze : std_logic := '0') RETURN natural IS
-  BEGIN
-    IF (freeze='1') THEN RETURN a; END IF;
+  BEGIN
+    IF (freeze='1') THEN RETURN a; END IF;
     IF (a=0 AND b=1) OR (a=1 AND b=0) THEN RETURN 2; END IF;
     IF (a=1 AND b=2) OR (a=2 AND b=1) THEN RETURN 0; END IF;
     RETURN 1;                              
@@ -401,7 +401,7 @@ ARCHITECTURE rtl OF ascal IS
   ----------------------------------------------------------
   -- Output
   SIGNAL o_run : std_logic;
-  SIGNAL o_freeze : std_logic;
+  SIGNAL o_freeze : std_logic;
   SIGNAL o_mode,o_hmode,o_vmode : unsigned(4 DOWNTO 0);
   SIGNAL o_format : unsigned(5 DOWNTO 0);
   SIGNAL o_fb_pal_dr : unsigned(23 DOWNTO 0);
@@ -1731,8 +1731,8 @@ BEGIN
       --------------------------------------------
       -- Triple buffering.
       -- For intelaced video, half frames are updated independently
-      -- Input : Toggle buffer at end of input frame
-               o_freeze <= freeze;
+      -- Input : Toggle buffer at end of input frame
+      o_freeze <= freeze;
       o_inter  <=i_inter; -- <ASYNC>
       o_iendframe0<=i_endframe0; -- <ASYNC>
       o_iendframe02<=o_iendframe0;
@@ -1746,7 +1746,12 @@ BEGIN
         o_ibuf1<=buf_next(o_ibuf1,o_obuf1,o_freeze);
         o_bufup1<='1';
       END IF;
+      
       -- Output : Change framebuffer, and image properties, at VS falling edge
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup0='1' THEN
+        o_obuf0<=buf_next(o_obuf0,o_ibuf0,o_freeze);
+        o_bufup0<='0';
+      END IF;
       IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup1='1' THEN
         o_obuf1<=buf_next(o_obuf1,o_ibuf1,o_freeze);
         o_bufup1<='0';
@@ -1755,6 +1760,33 @@ BEGIN
         o_hdown<=i_hdown; -- <ASYNC>
         o_vdown<=i_vdown; -- <ASYNC>
       END IF;
+      
+      -- Simultaneous change of input and output framebuffers
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND
+        o_iendframe0='1' AND o_iendframe02='0' THEN
+        o_bufup0<='0';
+        o_obuf0<=o_ibuf0;
+      END IF;
+      IF o_vsv(1)='1' AND o_vsv(0)='0' AND
+        o_iendframe1='1' AND o_iendframe12='0' THEN
+        o_bufup1<='0';
+        o_obuf1<=o_ibuf1;
+      END IF;
+      
+      -- Non-interlaced, use same buffer for even and odd lines
+      IF o_inter='0' THEN
+        o_ibuf1<=o_ibuf0;
+        o_obuf1<=o_obuf0;
+      END IF;
+      
+      -- Triple buffer disabled
+      IF o_mode(3)='0' THEN
+        o_obuf0<=0;
+        o_obuf1<=0;
+        o_ibuf0<=0;
+        o_ibuf1<=0;
+      END IF;
+      
       -- Framebuffer mode.
       IF o_fb_ena='1' THEN
         o_ihsize<=o_fb_hsize;
@@ -1774,25 +1806,6 @@ BEGIN
         o_stride<=to_unsigned(o_ihsize_temp2,14);
         o_stride(NB_BURST-1 DOWNTO 0)<=(OTHERS =>'0');
       END IF;
-      
-      IF o_vsv(1)='1' AND o_vsv(0)='0' AND o_bufup0='1' THEN
-        o_obuf0<=buf_next(o_obuf0,o_ibuf0,o_freeze);
-        o_bufup0<='0';
-      END IF;
-      
-      IF o_inter='0' THEN
-        o_ibuf1<=o_ibuf0;
-        o_obuf1<=o_obuf0;
-      END IF;
-      
-      -- Triple buffer disabled
-      IF o_mode(3)='0' THEN
-        o_obuf0<=0;
-        o_obuf1<=0;
-        o_ibuf0<=0;
-        o_ibuf1<=0;
-      END IF;
-      
       ------------------------------------------------------
       o_hmode<=o_mode; 
       IF o_hdown='1' AND DOWNSCALE THEN
And yuuup that totally seems to fix it! 🥳 Super Mario World has been running for well over 5 hours now and no screen tearing to be seen! Absolutely impeccable! 👌🏻

Edit: If confirmed by others, could you make sure to propagate this fix to all other cores? Thanks! :D
paulbnl
Core Developer
Posts: 205
Joined: Sun May 24, 2020 8:48 pm
Has thanked: 18 times
Been thanked: 196 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by paulbnl »

I have left the core with the fix running for 19 hours without tearing so I think we can say that it is fixed.
PikWik
Posts: 256
Joined: Sat May 30, 2020 7:00 pm
Has thanked: 192 times
Been thanked: 71 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by PikWik »

i dont have too much time to tinker with this tonight, but im noticing something similar happening as of lately.
tested with the new shadow mask core and standard SNES core thats released, but its a judder or frame drop every second or so when im running with mario at full speed

240 testsuite scrolls the screen just fine up to the super fast speeds that the grid and sonic background can display,
but super mario world, with either "match core frequency" or "low lag" has a slight loading/catchup/frame drop every second or so.
its like a frame drop about every second, only when im running at full speed.

i can record a video to show what im talking about, and/or make a separate thread if its not related to this issue
PikWik
Posts: 256
Joined: Sat May 30, 2020 7:00 pm
Has thanked: 192 times
Been thanked: 71 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by PikWik »

weird, reproduced it with the SNES version posted above by Grabulosaure, and on the shadow mask version of the SNES core,
in vsync mode 0, 1, or 2 if i run full speed with mario, the screen is briefly loading/catching up every second or so

good example is the first levels of SMW, where you have a long section to run on the foreground and look at the background.
but, test suite does not do this in the scroll test, so maybe its just how SMW is??
maybe a video buffer maxout, due to so many sprites and objects entering the screen when running at full speed?

i will have to check on my actual SNES and CRT and report back


EDIT *****
yes, happens on SNES with a CRT. i guess this is just how mario has always played, but ive never noticed :lol:
EDIT *****
FoxbatStargazer
Top Contributor
Posts: 994
Joined: Thu Dec 10, 2020 5:44 pm
Has thanked: 309 times
Been thanked: 228 times

Re: Screen tearing after playing Zelda LTTP for multiple hours.

Unread post by FoxbatStargazer »

PikWik wrote: Wed Nov 03, 2021 4:53 am EDIT *****
yes, happens on SNES with a CRT. i guess this is just how mario has always played, but ive never noticed :lol:
EDIT *****
That's potentially interesting for all those complaints about SMW scrolling on LG CX!
Post Reply