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-2-02 @ 11:29

Yesterplay80 wrote: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.
By the way, this is fixed, but my patch no longer applies 4185. I'll update it. Edit: updated.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby Ant_222 » 2019-2-03 @ 20:43

Instead of using several games, it is much easier to test V-sync with the little program in the attachment.
You do not have the required permissions to view the files attached to this post.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby Yesterplay80 » 2019-2-03 @ 20:48

The latest patch is integrated in my ECE build 4185. :)
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 441
Joined: 2016-2-23 @ 11:02
Location: Germany

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

Postby Ant_222 » 2019-2-05 @ 22:14

Yesterplay80 wrote:The latest patch is integrated in my ECE build 4185. :)
Thank you, but I fear it is not the latest patch—alpha 19 instead of alpha 21. If anybody needs the emulation of fullscreen as a borderless window, kindly ask Yesterplay80 to include it!
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby Yesterplay80 » 2019-2-06 @ 21:27

Whaaaaaaaaaaat??? :wink:

Either I missed an update or forgot to replace the readme file, sorry! However, it doesn't matter, new builds based on r4191 are available NOW. Definitely containing your pixel perfect patch A21 this time!
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 441
Joined: 2016-2-23 @ 11:02
Location: Germany

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

Postby Ant_222 » 2019-2-06 @ 21:34

Yesterplay80 wrote:Either I missed an update or forgot to replace the readme file, sorry!
It was not only the readme, because the new setting fullborderless was missing, but no problem at all at all!
Yesterplay80 wrote:However, it doesn't matter, new builds based on r4191 are available NOW. Definitely containing your pixel perfect patch A21 this time!
Tested and confirmed.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby KainXVIII » 2019-2-07 @ 10:41

I don't know - either borderless window mode not working or it does not help with screen tearing..
User avatar
KainXVIII
Member
 
Posts: 331
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

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

Postby Ant_222 » 2019-2-07 @ 10:45

KainXVIII wrote:I don't know - either borderless window mode not working or it does not help with screen tearing..
Probably the latter. What windows are you on?
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby KainXVIII » 2019-2-07 @ 15:23

Ant_222 wrote:
KainXVIII wrote:I don't know - either borderless window mode not working or it does not help with screen tearing..
Probably the latter. What windows are you on?

Win10.
User avatar
KainXVIII
Member
 
Posts: 331
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

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

Postby Ant_222 » 2019-2-07 @ 15:28

To check whether it is a borderless window, you can try putting another window on top of DOSBox, such as Taskbar or Task Manager. This test works in Windows XP.

Please, try if the borderless window has V-Sync in bladeSk's fork. Note that it uses different config parameters.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby aaronp » 2019-2-07 @ 16:04

I'm getting a really bizarre segfault when using opengl (any type) with the latest patch accompanied by the message

Code: Select all
Failed to turn V-Sync off: Couldn't open /usr/local/lib/timidity/timidity.cfg


It's bizarre because as far as I can tell, timidity isn't actually referenced anywhere in the code. From a glance, it looks like this is actually an error message from SDL. Why the heck is SDL trying to open a file from timidity? I'm too tired try and figure that one out. :dead:

Anyway, that's actually unrelated to the segfault. This is another case of setvsync having a return value in the type signature that isn't ever actually returned. setting the return type to void fixes the dosbox segfault... At which point loading dosbox with openglepp causes gnome-shell (my desktop environment) to segfault. :lol: I think amdgpu doesn't like something you're doing with openglepp, but I don't know much about opengl.

As an aside, if you're going to support borderless fullscreen (awesome!) would you be willing add a cfg option to set the _NET_WM_BYPASS_COMPOSITOR window hint in x11 (I believe Windows as a similar option)? Obviously this negates the whole v-sync thing, but hopefully that would allow people to alt-tab dosbox without having to constantly switch between windowed and fullscreen, without sacrificing performance from compositing.
aaronp
Newbie
 
Posts: 25
Joined: 2016-10-16 @ 19:32

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

Postby Ant_222 » 2019-2-07 @ 19:36

aaronp wrote:It's bizarre because as far as I can tell, timidity isn't actually referenced anywhere in the code. From a glance, it looks like this is actually an error message from SDL. Why the heck is SDL trying to open a file from timidity? I'm too tired try and figure that one out.
Yes, it is an error message from SDL. Yes, it is super crazy.
aaronp wrote:Anyway, that's actually unrelated to the segfault. This is another case of setvsync having a return value in the type signature that isn't ever actually returned. setting the return type to void fixes the dosbox segfault
Thank you, fixed in the patch.
At which point loading dosbox with openglepp causes gnome-shell (my desktop environment) to segfault. :lol: I think amdgpu doesn't like something you're doing with openglepp, but I don't know much about opengl.
You shall have to help me with resolving this error because I don't have a Linux installation. Does openglnb work with the patch? Does it work in stock DOSBox? Edit: Did you try with fullborderless both true and false?
As an aside, if you're going to support borderless fullscreen (awesome!) would you be willing add a cfg option to set the _NET_WM_BYPASS_COMPOSITOR window hint in x11 (I believe Windows as a similar option)? Obviously this negates the whole v-sync thing, but hopefully that would allow people to alt-tab dosbox without having to constantly switch between windowed and fullscreen, without sacrificing performance from compositing.
If that is going to introduce OS-specific conditional compilation then I would rather not, because I really should like to keep the footprint of the patch to a minimum. It is already larger than I want and I am considering a simplification because I hope that one day I am allowed to include it into official SVN. Another reason is that a small patch is easier to keep in sync with the latest SVN trunk.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby aaronp » 2019-2-07 @ 23:09

Thank you, fixed in the patch.


I'll take "Reasons why C++ sucks" for 200, Alex. :lol:

You shall have to help me with resolving this error because I don't have a Linux installation. Does openglnb work with the patch? Does it work in stock DOSBox? Edit: Did you try with fullborderless both true and false?


This is openglpp only. It definitely is happening with fullborderless=false. It's a bit of a pain to test because I have to reboot my computer every time. From my system logs though, I think what's happening is that dosbox is trying to create a massively big window and breaking everything. I was actually running out of both RAM and VRAM at some point and triggering the oom killer, and the "available area" info reported by dosbox was really big.

If that is going to introduce OS-specific conditional compilation then I would rather not, because I really should like to keep the footprint of the patch to a minimum. It is already larger than I want and I am considering a simplification because I hope that one day I am allowed to include it into official SVN. Another reason is that a small patch is easier to keep in sync with the latest SVN trunk.


Makes sense. SDL2 will do this for you, but unfortunately I don't think it's a feature of SDL1. In that case, though, I wonder if it doesn't make sense to split the fullscreen/v-sync stuff into a separate patch?
aaronp
Newbie
 
Posts: 25
Joined: 2016-10-16 @ 19:32

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

Postby Ant_222 » 2019-2-10 @ 15:02

I am temporarily without an internet connection (and I have no smartphone), so I have dropped by my friend for a quick notice.
aaronp wrote:This is openglpp only. It definitely is happening with fullborderless=false.
In fullscreen only? Is it OK with surfacepp?
aaronp wrote:It's a bit of a pain to test because I have to reboot my computer every time. From my system logs though, I think what's happening is that dosbox is trying to create a massively big window and breaking everything. I was actually running out of both RAM and VRAM at some point and triggering the oom killer, and the "available area" info reported by dosbox was really big.
Thanks, this is useful information. So you can save and read the output of the debug console window. Does the error persist if you explicitly specify your native resolution for fullresolution and something a bit lower than the native in windowresolution?
aaronp wrote:In that case, though, I wonder if it doesn't make sense to split the fullscreen/v-sync stuff into a separate patch?
I could try it, but I fear these patches won't be orthogonal and additive simultaneously with my patch and with plain SVN.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby aaronp » 2019-2-10 @ 23:47

I could try it, but I fear these patches won't be orthogonal and additive simultaneously with my patch and with plain SVN.


After some testing, it looks like alt+tab and friends is still captured in borderless fullscreen, anyway. That mode wouldn't be too useful to me without additional work, so that drops my interest a bit. :P

Surfacepp works fine, and it looks like openglpp does work as well if you manually set the resolution rather than use desktop. In this case, I am able to switch between fullscreen and windowed without an issue.
aaronp
Newbie
 
Posts: 25
Joined: 2016-10-16 @ 19:32

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

Postby Ant_222 » 2019-2-11 @ 21:24

aaronp wrote:After some testing, it looks like alt+tab and friends is still captured in borderless fullscreen, anyway.
What do you mean by captured?
aaronp wrote:That mode wouldn't be too useful to me without additional work, so that drops my interest a bit. :P
I should be very grateful I you would help me with the least that I must do, i.e. fix the crash you reported. Can you please try to reproduce the error with the attached patch. If the error is there, please post your config file and and corresponding DOSBox output.
You do not have the required permissions to view the files attached to this post.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby aaronp » 2019-2-11 @ 22:17

No problem, I just meant that I was less interested in the borderless fullscreen mode in particular (not the rest of this patch) because alt+tab and other wm shortcuts are still being sent to dosbox rather than the window manager.

I can confirm that your new patch works fine for me with output=openglpp and fullresolution=desktop. Seems that issue is fixed. :)
aaronp
Newbie
 
Posts: 25
Joined: 2016-10-16 @ 19:32

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

Postby Ant_222 » 2019-2-11 @ 22:22

Excellent, and thanks for testing. You might be interested in the work of my competitor, who seems more willing to fine-tune Windows-specific window-management stuff.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

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

Postby James-F » 2019-2-15 @ 08:12

I want to add that most DOS games lock their music and game speed to 70Hz, so when you enable vsync (glfullvsync=true) on a 60Hz monitor, many games will run slower and may have sound/music problems.
I do not recommend using vsync in Dosbox.
User avatar
James-F
Oldbie
 
Posts: 1448
Joined: 2015-11-30 @ 04:10

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

Postby Ant_222 » 2019-2-15 @ 08:27

James-F wrote:I want to add that most DOS games lock their music and game speed to 70Hz
And did CRT's work at 70Hz or was there tearing?
so when you enable vsync (glfullvsync=true) on a 60Hz monitor, many games will run slower and may have sound/music problems.
I never saw them run slower, only jittery.
I do not recommend using vsync in Dosbox.
How is V-sync implemented in Desktop composition in Windows 8 and later? If you have such a Windows with Aero enabled, try any 70Hz game with this fork.
Ant_222
Member
 
Posts: 478
Joined: 2010-7-24 @ 21:29

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 1 guest