VIDEO Patch for pixel-perfect scaling (SDL1)

[Ant_222]

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]

Instead of using several games, it is much easier to test V-sync with the little program in the attachment.

[Yesterplay80]

The latest patch is integrated in my ECE build 4185.

[Ant_222]

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!

[Yesterplay80]

Whaaaaaaaaaaat???

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!

[Ant_222]

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!

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.

[KainXVIII]

I don't know - either borderless window mode not working or it does not help with screen tearing..

[Ant_222]

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?

[KainXVIII]

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.

[Ant_222]

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.

[aaronp]

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.

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. 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.

[Ant_222]

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.

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.

[aaronp]

Thank you, fixed in the patch.

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

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?

[Ant_222]

I am temporarily without an internet connection (and I have no smartphone), so I have dropped by my friend for a quick notice.

This is openglpp only. It definitely is happening with fullborderless=false.

In fullscreen only? Is it OK with surfacepp?

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?

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.

[aaronp]

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.

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.

[Ant_222]

After some testing, it looks like alt+tab and friends is still captured in borderless fullscreen, anyway.

What do you mean by captured?

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.

[aaronp]

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.

[Ant_222]

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.

[James-F]

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.

[Ant_222]

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.