VOGONS

Common searches


Reply 640 of 725, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

And did CRT's work at 70Hz or was there tearing?

Tearing is a matter of vsync and buffering in the GPU, old dos games did not have this technology yet and relied on the VGA card refreshrate output and divisions of it.
CRT's are analog and display the image at any requested refresh rate, so no tearing on CRT and smooth 70Hz when the game outputs 70fps or divisions of it.
When you FORCE a game to run other refreshrates you break its reference timing.

I never saw them run slower, only jittery.

Supaplex, MK1, MK3, Prince2, even Duke3D, and many more games that require capped 70Hz as reference which VSync breaks since it forces the game to 60Hz.
Other games like Doom don't care since they are well programmed and have their reference timing not from the GPU.

Last edited by James-F on 2019-02-15, 08:54. Edited 2 times in total.


my important / useful posts are here

Reply 641 of 725, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote:

CRT's are analog and display the image at any requested refresh rate, so no tearing on CRT and smooth 70Hz.

In my early Windows 95/98 days, I used to have CRT that couldn't handle 70Hz at a comfortably high resolution and worked at 60Hz. Could any monitor in the DOS era work at 70Hz?

I never saw them run slower, only jittery.

Supaplex, MK1, MK3, Prince2, and many more games that require capped 70Hz as reference which VSync breaks since it forces the game to 60Hz.[/quote]Then I don't understand how VSync works. I thought all it did was synchronise video memory updates with montitor refreshes, rather than vice versa, and thefore could not affect the timing in the program...
Edit:

I do not recommend using vsync in Dosbox.

To clarify—you can turn off VSync in my patch via fulldouble for surfacepp and via glfullvsync for openglpp.

Reply 642 of 725, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Could any monitor in the DOS era work at 70Hz?

Yes.
There was no particular refresh rate either, you could run at 67.5Hz or 115Hz and it would be perfect, CRT is an analog device.

Then I don't understand how VSync works. I thought all it did was synchronise video memory updates with montitor refreshes, rather than vice versa, and thefore could not affect the timing in the program...

Maybe Dosbox has something to do with it, but I am 100% sure you should not force an old dos game from 70hz to 60hz, that'll break it in most cases.
I'm reminding that 99.99% dos games are 320x200@70Hz.

I'm running my Pentium 233 MMX through a OSSC and my LCD monitor reports 70Hz and runs smoothly.
70hz.jpg


my important / useful posts are here

Reply 643 of 725, by syche

User metadata
Rank Newbie
Rank
Newbie
Ant_222 wrote:

In my early Windows 95/98 days, I used to have CRT that couldn't handle 70Hz at a comfortably high resolution and worked at 60Hz. Could any monitor in the DOS era work at 70Hz?

It depended on the resolution as far as I remember. The higher the resolution the lower the refresh rate was allowed. The upper limits on both were defined by two factors: your video adapter RAMDAC's pixel clock (basically pixels per second) and your CRT monitor's horizontal scan rate (horizontal lines per second). But 90% of DOS-era games (at least in early to mid 90's) adhered to the old VGA standard anyway (since it was supported by all video adapters) for best compatibility and to avoid issues, hence the 320x200@70Hz mode used by a lot of games, since it's a standard VGA mode that AFAIK also allowed some flexibility in graphics manipulations and speed.

Then I don't understand how VSync works. I thought all it did was synchronise video memory updates with montitor refreshes, rather than vice versa, and thefore could not affect the timing in the program...

I think, it's on a case by case basis. For what it's worth I've just played through 3 first levels of Prince 2 now and I've been playing Shadow Warrior (build engine game) the last couple of weeks all with Vsync turned on and tbh I haven't noticed any serious issues with either of the games. Vsync works really well with those games, as far as I'm concered. So it depends on a game and it also depends on personal preferences. I think some people (like me) would rather play with Vsync turned on, even if it breaks some aspects of the game (like music). Good example is Jazz Jackrabbit, to me the game is basically unplayable without Vsync, so to me inconsistent music speed in menus is nothing compared to a perfectly playable game. Good thing though is now we have a choice, so I want to thank you for that.

Reply 644 of 725, by KainXVIII

User metadata
Rank Member
Rank
Member

Is it normal that Commander Keen 4 runs in 320x400 resolution when machine=vgaonly? Latest ECE version.
PS - also i can't fix judder scrolling even with compatibility options..

Reply 645 of 725, by FulValBot

User metadata
Rank Newbie
Rank
Newbie
James-F wrote:
Show quote

Could any monitor in the DOS era work at 70Hz?

Yes.
There was no particular refresh rate either, you could run at 67.5Hz or 115Hz and it would be perfect, CRT is an analog device.

Then I don't understand how VSync works. I thought all it did was synchronise video memory updates with montitor refreshes, rather than vice versa, and thefore could not affect the timing in the program...

Maybe Dosbox has something to do with it, but I am 100% sure you should not force an old dos game from 70hz to 60hz, that'll break it in most cases.
I'm reminding that 99.99% dos games are 320x200@70Hz.

I'm running my Pentium 233 MMX through a OSSC and my LCD monitor reports 70Hz and runs smoothly.
70hz.jpg

Yes, i confirm this; Quake1 was lagging with 60hz and not with other refresh rate (tested with 144hz; i think that it works fine because is a multiple of 72, and Quake1 is a 70fps game), same with other games; these lags are NOT caused by v-sync because in Quake1 was disabled as default and i don't have enabled it in .conf

Last edited by FulValBot on 2019-06-01, 09:17. Edited 1 time in total.

Reply 646 of 725, by Yesterplay80

User metadata
Rank Member
Rank
Member

Unfortunately, SVN r4228 once again breaks compatibility with your patch, Ant_222.

And do you maybe have a solution for the problem mentioned here?

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 647 of 725, by Px1994

User metadata
Rank Newbie
Rank
Newbie

Hello,

is it possible to tweak the 320x350 VGA-Mode in Pinball Dreams and Pinball Fantasies with a trick? Using borderless mode and in borderless mode we can choose the resolution that we want also 320x350 x multiplier. Black border does'nt matter, it will be cool if the pixel perfect patch can check the borderless mode and upscale to the maximum. 960x1050 for 1080p in borderless mode.

I think in the borderless mode every pixel perfect ratio can be calculated.

At the moment the pixel perfect patch calculate this:

Available area: 1920x1080 (fullscreen)
Scaling: 320x350 (0.69) --[4.0 x 3.0]--> 1280x1050 (1)
attempting to fix the centering to 320 15 1280 1050
Available area: 960x1050 (borderless)
Scaling: 320x350 (0.69) --[3.0 x 2.0]--> 960x700 (1)

Is it possible to patch an option that following will be calculated:

Available area: 1920x1080 (fullscreen)
Scaling: 320x350 (0.69) --[3.0 x 3.0]--> 960x1050 (1)

Available area: 960x1050 (borderless)
Scaling: 320x350 (0.69) --[3.0 x 3.0]--> 960x1050 (1)

???

An special option where a user can put here own calcualation? or soemwhat?

Reply 648 of 725, by Yesterplay80

User metadata
Rank Member
Rank
Member

I'm not sure I got what you're trying to do. You want to use the pixel perfect output, but without a pixel perfect resolution? If so, you don't have to use pixel perfect as output at all, just specify the desired resolution in the conf file.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 649 of 725, by Yesterplay80

User metadata
Rank Member
Rank
Member

I stumbled upon a problem with DOSBox ECE that occurs when I try to stream a game with OBS or PlayClaw: Whenever I switch from fullscreen to windowed in DOSBox ECE (change the resolution), the screen in OBS gets black or dark grey and stops updating, no matter if I stay in windowed mode or return to full screen. Every now and then DOSBox even crashes after switching modes.

It doesn't matter if I use a pixel perfect output mode or just opengl(nb), or if I enable glfullsync or not, so at first I thought it was a problem of OBS or Windows on my PC. So i tried it on another machine and the same thing happened. Then I tried different older versions of DOSox ECE, as well as older versions of OBS, but still the error occured. I then started trying out other builds and those worked fine, so it had to be a problem with just DOSBox ECE. So I compiled a build of ECE that included everything BUT the pixel perfect patch, because it's the one introducing the most changes to the original source code. And voilà: It worked again. So it looks as if it's the pixel perfect patch causing the trouble. Maybe some of the recent updates to sdlmain.cpp in the SVN have to be adapted in a different way and not by just inserting them in your diff alongside your other changes, which is all I could do.

Could you please look into this, Ant_222 (if you are even still reading this or supporting the patch at all)?

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 650 of 725, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

I have missed the update to this thread. I will try to understand what is going on. What are OBS and PlayClaw? So the problem appears even in modes where the pixel-perfect mode is inactive?

Reply 651 of 725, by Yesterplay80

User metadata
Rank Member
Rank
Member

Open Broadcast Studio (OBS) and Playclaw are both streaming tools, used by many streamers for Twitch, YouTube, etc.

Yes, strangely this problem occurs ONLY when I select opengl or openglnb. OBS requires a a hardware output mode for its game capture mode to work, it somehow grabs the picture from the GPU. Other modes, like surfacepp for example, work fine, so I could use the window capturing mode in OBS, but those are less performant and/or more blurry. However, the problem seems to be OpenGL related.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 652 of 725, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

Did these streaming tools stop working when the first version with OpenGL support came out? Since I still have only Windows XP, I ask you to help me by consulting the OBS community. Maybe they can diagnose the problem and so help me to localise and fix it in the patch? Unfortunately, I can't reproduce the problem myself because OBS will not install on Windows XP.

Reply 653 of 725, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote:

Unfortunately, SVN r4228 once again breaks compatibility with your patch, Ant_222.

And do you maybe have a solution for the problem mentioned here?

Just to make sure I haven't missed anything, do both of these problems still require solution?

Reply 654 of 725, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Px1994 wrote:

is it possible to tweak the 320x350 VGA-Mode in Pinball Dreams and Pinball Fantasies with a trick? Using borderless mode and in borderless mode we can choose the resolution that we want also 320x350 x multiplier. Black border does'nt matter, it will be cool if the pixel perfect patch can check the borderless mode and upscale to the maximum. 960x1050 for 1080p in borderless mode.

Scaling-wise, borderless mode should be equivalent to fullscreen mode, because in both cases DOSBox controls the entire area of the display.

Px1994 wrote:
Show quote

At the moment the pixel perfect patch calculate this:

Available area: 1920x1080 (fullscreen)
Scaling: 320x350 (0.69) --[4.0 x 3.0]--> 1280x1050 (1)
attempting to fix the centering to 320 15 1280 1050
Available area: 960x1050 (borderless)
Scaling: 320x350 (0.69) --[3.0 x 2.0]--> 960x700 (1)

I don't understand why the available area in borderless mode is not the same as in fullscreen mode. Have you an idea?

Px1994 wrote:
Show quote

Is it possible to patch an option that following will be calculated:

Available area: 1920x1080 (fullscreen)
Scaling: 320x350 (0.69) --[3.0 x 3.0]--> 960x1050 (1)

Available area: 960x1050 (borderless)
Scaling: 320x350 (0.69) --[3.0 x 3.0]--> 960x1050 (1)

Although technically possible, it will result in a heavily disproportional, super narrow image. Do you really want it?

Reply 655 of 725, by Yesterplay80

User metadata
Rank Member
Rank
Member
Ant_222 wrote:
Yesterplay80 wrote:

Unfortunately, SVN r4228 once again breaks compatibility with your patch, Ant_222.

And do you maybe have a solution for the problem mentioned here?

Just to make sure I haven't missed anything, do both of these problems still require solution?

Yes. I added the changes made in r4228 to your patch in my build, but generally they are missing from your latest patch. The problem with scaling a agme to 960x720 still exists as well.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 657 of 725, by Yesterplay80

User metadata
Rank Member
Rank
Member
Ant_222 wrote:

Did these streaming tools stop working when the first version with OpenGL support came out? Since I still have only Windows XP, I ask you to help me by consulting the OBS community. Maybe they can diagnose the problem and so help me to localise and fix it in the patch? Unfortunately, I can't reproduce the problem myself because OBS will not install on Windows XP.

I could try but the log files of OBS shows no errors, so it'll be as hard to diagnoe ofr them as it is for you. And yes, the thought that the problem came up when you introduced the possibility to turn VSync for OpenGL on or off already came to my mind as well. Do you maybe have an old diff from before you introduced this setting? I already wanted to try out A16, but it isn't linked here.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 658 of 725, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Yesterplay80 wrote:

I could try but the log files of OBS shows no errors, so it'll be as hard to diagnoe ofr them as it is for you.

Not quite, for they can investigate the problem from the other side and see what happens inside OBS that prevents proper video capture.

Yesterplay80 wrote:

And yes, the thought that the problem came up when you introduced the possibility to turn VSync for OpenGL on or off already came to my mind as well. Do you maybe have an old diff from before you introduced this setting? I already wanted to try out A16, but it isn't linked here.

Unfortunately not, although a little self-discipline would have helpled. I will prepare a version without the VSync feature for you test.

Reply 659 of 725, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Ant_222 wrote:

I will prepare a version without the VSync feature for you test.

Attached.

Attachments

  • Filename
    pp24a_novsync.diff
    File size
    85.01 KiB
    Downloads
    2 downloads
    File license
    Fair use/fair dealing exception