VOGONS

Common searches


Reply 560 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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).

Attachments

  • Filename
    DosBoxPp18a.zip
    File size
    1.09 MiB
    Downloads
    55 downloads
    File license
    Fair use/fair dealing exception

Reply 561 of 733, by Pat86

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 562 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 563 of 733, by Pat86

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 564 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 565 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 566 of 733, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

Alpha 19 is included in DOSBox ECE r4180.4. 😀

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

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?

output = overlay
surfacenp-sharpness = 50
glfullvsync = true
xsensitivity = 100
ysensitivity = 100
autolock = true

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 567 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 568 of 733, by Pat86

User metadata
Rank Newbie
Rank
Newbie
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?

Reply 569 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member

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?

Reply 570 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 571 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 573 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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).

Reply 574 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member

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 😎

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

Desktop Screenshot 2019.01.23 - 17.18.09.49.png
Filename
Desktop Screenshot 2019.01.23 - 17.18.09.49.png
File size
132.97 KiB
Views
1214 views
File license
Fair use/fair dealing exception
Wolfenstein 3D Screenshot 2019.01.23 - 17.21.36.80.png
Filename
Wolfenstein 3D Screenshot 2019.01.23 - 17.21.36.80.png
File size
182.24 KiB
Views
1214 views
File license
Fair use/fair dealing exception
Wolfenstein 3D Screenshot 2019.01.23 - 17.21.43.13.png
Filename
Wolfenstein 3D Screenshot 2019.01.23 - 17.21.43.13.png
File size
133.63 KiB
Views
1214 views
File license
Fair use/fair dealing exception

Reply 576 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
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? 😁

Reply 577 of 733, by Pat86

User metadata
Rank Newbie
Rank
Newbie

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?

Reply 578 of 733, by Diduz

User metadata
Rank Newbie
Rank
Newbie

First of all, thanks again to Ant_222 and YesterPlay80 for their work. 😀
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 😁 , 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. 😦

Reply 579 of 733, by Pat86

User metadata
Rank Newbie
Rank
Newbie

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-01-23, 15:32. Edited 3 times in total.