Unofficial libretro port screen tearing \ VOGONS

Unofficial libretro port screen tearing

Topic actions

Post a reply

First post, by fr500

Posted on 2019-10-19, 03:28

fr500 Offline

Rank Newbie

Rank: Newbie
Posts: 29
Joined: 2018-07-10, 22:49

I'm looking for some help to solve horrible screen tearing (I have an horizontal line running across the screen at vertical scrolling in games like jazz jackrabbit).
I didn't write this core, I just cleaned it up and rebased it on top of DOSBox-SVN so it's easier to maintain.

Anyway, our whole rendering code is quite simplistic, it's basically this:

1#include <string.h>
2#include "libretro.h"
3#include "dosbox.h"
4#include "video.h"
5
6Bit8u RDOSGFXbuffer[1024*768*4];
7Bitu RDOSGFXwidth, RDOSGFXheight, RDOSGFXpitch;
8unsigned RDOSGFXcolorMode = RETRO_PIXEL_FORMAT_0RGB1555;
9void* RDOSGFXhaveFrame;
10
11Bitu GFX_GetBestMode(Bitu flags)
12{
13    return GFX_CAN_32 | GFX_RGBONLY;
14}
15
16Bitu GFX_GetRGB(Bit8u red,Bit8u green,Bit8u blue)
17{
18    return (red << 16) | (green << 8) | (blue << 0);
19}
20
21Bitu GFX_SetSize(Bitu width,Bitu height,Bitu flags,double scalex,double scaley,GFX_CallBack_t cb)
22{
23    memset(RDOSGFXbuffer, 0, sizeof(RDOSGFXbuffer));
24
25    RDOSGFXwidth = width;
26    RDOSGFXheight = height;
27    RDOSGFXpitch = width * 4;
28
29    if(RDOSGFXwidth > 1024 || RDOSGFXheight > 768)
30        return 0;
31
32    return GFX_GetBestMode(0);
33}
34
35bool GFX_StartUpdate(Bit8u * & pixels,Bitu & pitch)
36{
37    pixels = RDOSGFXbuffer;
38    pitch = RDOSGFXpitch;
39
40    return true;
41}
42
43void GFX_EndUpdate( const Bit16u *changedLines )
44{
45    RDOSGFXhaveFrame = RDOSGFXbuffer;
46}
47
48// Stubs
49void GFX_SetTitle(Bit32s cycles,Bits frameskip,bool paused){}
50void GFX_ShowMsg(char const* format,...){}
51void GFX_Events(){}
52void GFX_SetPalette(Bitu start,Bitu count,GFX_PalEntry * entries){}

We're basically getting a pointer to the framebuffer and blitting that. AS IS. I see that whoever wrote this is not doing anything with changedlines, so I thought that may be the problem so that's one possibility.
The libretro core is leveraging a co-threading library (libco), so basically dosbox is running in a co-thread and we're escaping to the libretro thread on every T interval to get a finished frame. Maybe we're not doing it when the actual frame is complete so that's another possibility.

I'm not very savvy on the codebase, I tried to leave most things untouched, so I thought I'd ask for some feedback.

Reply 1 of 3, by fr500

Posted on 2019-10-19, 04:52

fr500 Offline

Rank Newbie

Rank: Newbie
Posts: 29
Joined: 2018-07-10, 22:49

Ok after messing around problem seems to be.. the scheduler. We switch contexts at 1/fps
With this change we get no tearing but bad frame pacing

1$ git diff
2diff --git a/libretro/libretro.cpp b/libretro/libretro.cpp
3index 4b2a4fa2..91d39ac2 100644
4--- a/libretro/libretro.cpp
5+++ b/libretro/libretro.cpp
6@@ -1391,10 +1391,6 @@ void retro_run (void)
7         /* Run emulator */
8         co_switch(emuThread);
9
10-        /* Upload video */
11-        video_cb(RDOSGFXhaveFrame, RDOSGFXwidth, RDOSGFXheight, RDOSGFXpitch);
12-        RDOSGFXhaveFrame = 0;
13-
14         /* Upload audio */
15         audio_batch_cb((int16_t*)audioData, samplesPerFrame);
16     }
17diff --git a/libretro/libretro_gfx.cpp b/libretro/libretro_gfx.cpp
18index 1baf21d9..204c86e9 100644
19--- a/libretro/libretro_gfx.cpp
20+++ b/libretro/libretro_gfx.cpp
21@@ -7,6 +7,10 @@ Bit8u RDOSGFXbuffer[1024*768*4];
22 Bitu RDOSGFXwidth, RDOSGFXheight, RDOSGFXpitch;
23 unsigned RDOSGFXcolorMode = RETRO_PIXEL_FORMAT_0RGB1555;
24 void* RDOSGFXhaveFrame;
25+float RDOSfps;
26+
27+
28+extern retro_video_refresh_t video_cb;
29
30 Bitu GFX_GetBestMode(Bitu flags)
31 {
32@@ -25,6 +29,7 @@ Bitu GFX_SetSize(Bitu width,Bitu height,Bitu flags,double scalex,double scaley,G
33     RDOSGFXwidth = width;
34     RDOSGFXheight = height;
35     RDOSGFXpitch = width * 4;
36+    RDOSfps = 60.0f;
37
38     if(RDOSGFXwidth > 1024 || RDOSGFXheight > 768)
39         return 0;
40@@ -43,6 +48,8 @@ bool GFX_StartUpdate(Bit8u * & pixels,Bitu & pitch)
41 void GFX_EndUpdate( const Bit16u *changedLines )
42 {
43     RDOSGFXhaveFrame = RDOSGFXbuffer;
44+    video_cb(RDOSGFXhaveFrame, RDOSGFXwidth, RDOSGFXheight, RDOSGFXpitch);
45+    RDOSGFXhaveFrame = 0;
46 }
47
48 // Stubs

I figure the rest of the logic may need changes to work under this new behavior of sorts.

Reply 2 of 3, by realnc

Posted on 2019-10-19, 15:40

realnc Offline

Rank Oldbie

Rank: Oldbie
Posts: 573
Joined: 2010-10-13, 11:02

As mentioned in the libretro bug, with this patch applied the core seems to only present new frames when there's changes on the screen. When the image is static and nothing new is being drawn, there's no new frames being presented. This stalls the refresh rate in g-sync mode (you get 0Hz) and recovering from that produces extremely severe stutter.

I think this is a general dosbox behavior? Running dosbox on Windows and monitoring its frame presentation interval with something like RTSS shows that dosbox will stop doing frame buffer flips when no new frames are drawn and this stalls the g-sync display.

Ideally, frames should be presented at a constant pace even when nothing new was drawn on the screen. The frame presentation interval must match the emulated refresh rate to get the wanted real refresh rate (in VRR mode the application is responsible for driving the refresh rate of the monitor.)

Reply 3 of 3, by fr500

Posted on 2019-10-19, 20:30

fr500 Offline

Rank Newbie

Rank: Newbie
Posts: 29
Joined: 2018-07-10, 22:49

So realnc found a simple fix
https://github.com/libretro/dosbox-svn/issues … mment-544173355

The problem is still related to the scheduler. Must remove libco at some point. The frontend was drawing the frame while dosbox was writing to it causing the tearing.

Go to top of page Go to top of page

Back to DOSBox Development

Main menu

Common searches