VOGONS

Common searches


Reply 620 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote:
Btw: Is there a certain reason why you mix up the settings for the output and the mouse? […]
Show full quote

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.

By the way, this is fixed, but my patch no longer applies 4185. I'll update it. Edit: updated.

Reply 621 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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

Attachments

  • Filename
    vsync.zip
    File size
    1.29 KiB
    Downloads
    73 downloads
    File comment
    A program to test V-sync in MS-DOS
    File license
    Fair use/fair dealing exception

Reply 622 of 733, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

The latest patch is integrated in my ECE build 4185. 😀

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

Reply 623 of 733, by Ant_222

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

Reply 624 of 733, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

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!

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

Reply 625 of 733, by Ant_222

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

Reply 628 of 733, by KainXVIII

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

Reply 629 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 630 of 733, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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

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.

Reply 631 of 733, by Ant_222

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

Reply 632 of 733, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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?

Reply 633 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 634 of 733, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 635 of 733, by Ant_222

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

Attachments

  • Filename
    pp23rc.diff
    File size
    85.47 KiB
    Downloads
    62 downloads
    File license
    Fair use/fair dealing exception

Reply 636 of 733, by aaronp

User metadata
Rank Newbie
Rank
Newbie

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

Reply 638 of 733, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

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.


my important / useful posts are here

Reply 639 of 733, by Ant_222

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