VIDEO Patch for pixel-perfect scaling (SDL1)

Here you can discuss the development of patches.

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Ant_222 » 2019-1-20 @ 10:56

Pat86 wrote:unfortunately i dont know how to apply the patch - i just use Yesterplays ECE. :-\
Try my development build form the attachment (Windows, MinGW, 32-bit).
You do not have the required permissions to view the files attached to this post.
Ant_222
Member
 
Posts: 466
Joined: 2010-7-24 @ 21:29

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Pat86 » 2019-1-20 @ 11:48

Thank you. Tearing is gone, but now performance in Jazz Jackrabbit's menues and loading screen is really laggy for openglnb / pp in both windowed and fullscreen. Gameplay is fine.
Acts exactly like surfacepp fullscreen with double buffering on now.

btw i have to correct my previous comment, that surfacepp fullscreen with double buffering off results in no tearing for me. it does. it's just not so recognizable than it is with opengl.
Pat86
Newbie
 
Posts: 24
Joined: 2019-1-19 @ 13:47

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Ant_222 » 2019-1-21 @ 19:55

Pat86 wrote:Thank you. Tearing is gone, but now performance in Jazz Jackrabbit's menues and loading screen is really laggy for openglnb / pp in both windowed and fullscreen.
There should at least be this difference: that with openglpp CPU load must be much lower. Could you test it with different cycles settings?
Gameplay is fine. Acts exactly like surfacepp fullscreen with double buffering on now.
But is the CPU load the same too?

I can't do much more at this point, so I think I will make OpenGL V-sync optional and then consider bladeSk's idea of using a borderless window to imitate fullscreen mode. Edit: Another possibility would be to try OpenGL output without double buffering.
Ant_222
Member
 
Posts: 466
Joined: 2010-7-24 @ 21:29

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Pat86 » 2019-1-22 @ 10:08

Yes, cpu load is lower. Maybe it's an specific dosbox problem with the game menue + loading screen & vsync / double buffering? Due to this gfx effect in the background? All my other games just work fine.
Pat86
Newbie
 
Posts: 24
Joined: 2019-1-19 @ 13:47

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Ant_222 » 2019-1-22 @ 10:19

Pat86 wrote:Yes, cpu load is lower. Maybe it's an specific dosbox problem with the game menue + loading screen & vsync / double buffering? All my other games just work fine.
May be, but I am not sure. SDL people simply ignored my question about SDL 1.2, so we are left to our own. By the way, V-Sync in SDL 1.2 requires double buffering. Anyway, I am glad that the new pixel-perfect output for OpenGL is useful.

bladeSk says that he has implemented pixel-perfect aspect-ratio correction in his fork, but the new version is not published yet. I am looking forward to testing his implementation with a borderless window.
Ant_222
Member
 
Posts: 466
Joined: 2010-7-24 @ 21:29

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Ant_222 » 2019-1-22 @ 20:56

Pat86 wrote: Maybe it's an specific dosbox problem with the game menue + loading screen & vsync / double buffering?
According to this thread, the effect might be due different refresh rates of the menu and in-game modes. The menu uses 70Hz and the in-game 60Hz. V-Sync might have trouble syncing with the higher rate of the emulated game.
Ant_222
Member
 
Posts: 466
Joined: 2010-7-24 @ 21:29

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Yesterplay80 » 2019-1-23 @ 13:05

Alpha 19 is included in DOSBox ECE r4180.4. :happy:

Btw: Is there a certain reason why you mix up the settings for the output and the mouse?

Code: Select all
output = overlay
sensitivity = 100
surfacenp-sharpness = 50
glfullvsync = true
autolock = true


I always alter your patch so that the output settings remain in one "block" and the mouse settings make another "block", I hope that doesn't break anything. I wouldn't know how, but I'm no developer/coder, so who knows?

Code: Select all
output = overlay
surfacenp-sharpness = 50
glfullvsync = true
xsensitivity = 100
ysensitivity = 100
autolock = true
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 414
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Ant_222 » 2019-1-23 @ 13:24

Yesterplay80 wrote:Alpha 19 is included in DOSBox ECE r4180.4.
Thank you!
Yesterplay80 wrote:Btw: Is there a certain reason why you mix up the settings for the output and the mouse?
...
I always alter your patch so that the output settings remain in one "block" and the mouse settings make another "block", I hope that doesn't break anything.
No, that was unintentional. I will regroup the settings the way you do, if possible.
Ant_222
Member
 
Posts: 466
Joined: 2010-7-24 @ 21:29

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Pat86 » 2019-1-23 @ 13:55

Ant_222 wrote:
Pat86 wrote: Maybe it's an specific dosbox problem with the game menue + loading screen & vsync / double buffering?
According to this thread, the effect might be due different refresh rates of the menu and in-game modes. The menu uses 70Hz and the in-game 60Hz. V-Sync might have trouble syncing with the higher rate of the emulated game.


sounds plausible. turning on/off vsync on the fly might help here. might this be possible via a hotkey?
Pat86
Newbie
 
Posts: 24
Joined: 2019-1-19 @ 13:47

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby KainXVIII » 2019-1-23 @ 13:57

Holy cow, working vsync in Dosbox?! Screen tearing was my biggest pet peeve to date and now its fixed? Dosbox Daum come close to this but never works properly (for me)
Why this is not thread worthly?
User avatar
KainXVIII
Member
 
Posts: 316
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Ant_222 » 2019-1-23 @ 14:06

Pat86 wrote:turning on/off vsync on the fly might help here. might this be possible via a hotkey
Possible, but may not be easy for me to implement. I will consider it after we have decided on whether V-Sync itself as implemented in my patch works well enough.
KainXVIII wrote:Holy cow, working vsync in Dosbox?! Screen tearing was my biggest pet peeve to date and now its fixed? Dosbox Daum come close to this but never works properly (for me)
Why this is not thread worthly?
Have you tested my patch with the glfullvsync option? If not, please do and tell your opinion.
Ant_222
Member
 
Posts: 466
Joined: 2010-7-24 @ 21:29

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Ant_222 » 2019-1-23 @ 14:16

For whatever developers might be reading this, I did not do much to enable V-Sync. Setting the attribute SDL_GL_SWAPCONTROL did the trick. I wrote it in a version-agnostic manner, though.
Ant_222
Member
 
Posts: 466
Joined: 2010-7-24 @ 21:29

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Pat86 » 2019-1-23 @ 14:19

btw is it possible to configure glfullvsync via DBGL or do i have to edit the config file manually?
Pat86
Newbie
 
Posts: 24
Joined: 2019-1-19 @ 13:47

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Ant_222 » 2019-1-23 @ 14:23

Pat86 wrote:btw is it possible to configure glfullvsync via DBGL or do i have to edit the config file manually?
Can't tell because I don't use DOSBox UI's and always edit my config manually. UI-access to a custom configuration option should not be possible unless your UI provides some generic ini-file editing functionality or is aware of my patch (which is unlikely).
Ant_222
Member
 
Posts: 466
Joined: 2010-7-24 @ 21:29

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby KainXVIII » 2019-1-23 @ 14:31

I just tested it in Hocus Pocus (GoG) and got interesting results:
1. Vsync works and screen tearing is finally gone!
2. Game (and even music) were slowed in main menus, but gameplay was fine.

So i turned on MSI Afterburner (don't know how its reliable in dosbox apps though) to measure FPS:
1. With glfullvsync=false main menus/music works fine without slowdowns and FPS was capped to ~70
2. With glfullvsync=true main menus/music were slowed down and FPS was capped to ~60 (my monitor max refresh rate), so there is a culprit i guess.
3. Main gameplay was capped to ~20 something fps so glfullvsync=true does not break or slowdown anything :cool:

Conclusion, i don't know - tearing is gone but results may vary and heavily depends on the game (and your monitor) :confused:

Desktop Screenshot 2019.01.23 - 17.18.09.49.png

Wolfenstein 3D Screenshot 2019.01.23 - 17.21.36.80.png

Wolfenstein 3D Screenshot 2019.01.23 - 17.21.43.13.png
You do not have the required permissions to view the files attached to this post.
User avatar
KainXVIII
Member
 
Posts: 316
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Pat86 » 2019-1-23 @ 14:34

Hocus Pocus seems to be the same case as Jazz Jackrabbit, where menu etc is running with 70hz. Vsync forcing it to run in 60hz = lag.
Pat86
Newbie
 
Posts: 24
Joined: 2019-1-19 @ 13:47

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby KainXVIII » 2019-1-23 @ 14:35

Pat86 wrote:Hocus Pocus seems to be the same case as Jazz Jackrabbit, where menu etc is running with 70hz. Vsync forcing it to run in 60hz = lag.

Wellthereitis.gif
PS - can somebody try these games on 144hz monitors? :-D
User avatar
KainXVIII
Member
 
Posts: 316
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Pat86 » 2019-1-23 @ 14:52

seems like there were actually more games that used different frequencies.

Tried Hocus Pocus myself (3D Realms Anthology version) and i can confirm, that with glfullvsync=true on and surfacepp + double buffering main menu is slower. turning vsync / double buffering off and it runs flawlessly.
Yet Jazz and Hocus Pocus running fine in surface windowed mode aka using windows double buffering(?!). how come this one doesnt break them? adaptive v-sync?
Pat86
Newbie
 
Posts: 24
Joined: 2019-1-19 @ 13:47

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Diduz » 2019-1-23 @ 15:16

First of all, thanks again to Ant_222 and YesterPlay80 for their work. :happy:
I know there are various games that use different refresh frequencies between menus and ingame screens. In my opinion a good game to test the effectiveness of Ant's patch should be Apogee's Crystal Caves. Yeah, this sounds a strange choice :-D , the game is pretty choppy, but the title screen features an incredible silk-smooth EGA 60hz vertical scrolling (just wait for the screen to scroll without pressing any key). "machine=EGA" in dosbox.conf should keep the internal game screen frequency to 60hz.
60Hz is the easiest refresh to match for the vast majority of nowadays monitors, so I think this should be a good test I'm gonna try tonight. Games such as Jazz Jackrabbit are particularly complex, so I'm just afraid the results we get from their behaviour could be misleading.
Another 60hz smooth Apogee EGA game is Monster Bash.

Oh, perhaps one could match a 70hz game refresh by setting the desktop to a 70Hz resolution/refresh and then running DosBox? Just an idea. ._.
Diduz
Newbie
 
Posts: 34
Joined: 2003-4-23 @ 15:39

Re: VIDEO Patch for pixel-perfect scaling (SDL1)

Postby Pat86 » 2019-1-23 @ 15:24

Just gave Crystal Caves a try and yes, that's some smooooth scrolling. glfullvsync=false breaks it, with an ugly tearing line. ;)

Regarding Monster Bash, it has a frequent micro stutter every XY frame. But i guess that's just the game itself. Its identical for glfullvsync=true and surface+double buffering.
Last edited by Pat86 on 2019-1-23 @ 15:32, edited 3 times in total.
Pat86
Newbie
 
Posts: 24
Joined: 2019-1-19 @ 13:47

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest