VIDEO Patch for pixel-perfect scaling (SDL1)

Here you can discuss the development of patches.

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

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

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-2-15 @ 08:54, edited 2 times in total.
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:51

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.
Ant_222
Member
 
Posts: 468
Joined: 2010-7-24 @ 21:29

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

Postby James-F » 2019-2-15 @ 09:03

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.
Image
User avatar
James-F
Oldbie
 
Posts: 1448
Joined: 2015-11-30 @ 04:10

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

Postby syche » 2019-2-18 @ 09:36

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.
syche
Newbie
 
Posts: 8
Joined: 2016-8-13 @ 09:47

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

Postby KainXVIII » 2019-4-05 @ 08:58

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..
User avatar
KainXVIII
Member
 
Posts: 318
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

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

Postby FulValBot » 2019-4-07 @ 12:07

James-F wrote:
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.
Image


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-6-01 @ 09:17, edited 1 time in total.
FulValBot
Newbie
 
Posts: 75
Joined: 2008-3-01 @ 18:43

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

Postby Yesterplay80 » 2019-5-27 @ 07:12

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)
User avatar
Yesterplay80
Member
 
Posts: 414
Joined: 2016-2-23 @ 11:02
Location: Germany

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

Postby Px1994 » 2019-6-25 @ 19:10

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?
Px1994
Newbie
 
Posts: 2
Joined: 2019-6-25 @ 14:41

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

Postby Yesterplay80 » 2019-7-09 @ 12:18

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)
User avatar
Yesterplay80
Member
 
Posts: 414
Joined: 2016-2-23 @ 11:02
Location: Germany

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

Postby Yesterplay80 » 2019-7-11 @ 10:00

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)
User avatar
Yesterplay80
Member
 
Posts: 414
Joined: 2016-2-23 @ 11:02
Location: Germany

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

Postby Ant_222 » 2019-7-25 @ 09:06

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?
Ant_222
Member
 
Posts: 468
Joined: 2010-7-24 @ 21:29

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

Postby Yesterplay80 » 2019-7-25 @ 09:27

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)
User avatar
Yesterplay80
Member
 
Posts: 414
Joined: 2016-2-23 @ 11:02
Location: Germany

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

Postby Ant_222 » 2019-7-25 @ 20:25

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.
Ant_222
Member
 
Posts: 468
Joined: 2010-7-24 @ 21:29

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

Postby Ant_222 » 2019-7-25 @ 20:31

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?
Ant_222
Member
 
Posts: 468
Joined: 2010-7-24 @ 21:29

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

Postby Ant_222 » 2019-7-25 @ 20:41

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:At the moment the pixel perfect patch calculate this:

Code: Select all
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:Is it possible to patch an option that following will be calculated:

Code: Select all
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?
Ant_222
Member
 
Posts: 468
Joined: 2010-7-24 @ 21:29

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

Postby Yesterplay80 » 2019-7-26 @ 06:53

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)
User avatar
Yesterplay80
Member
 
Posts: 414
Joined: 2016-2-23 @ 11:02
Location: Germany

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

Postby Ant_222 » 2019-7-27 @ 20:22

OK, I will first restore compatibility, and then debug the 960x720 problem. Update: compatibility restored (but I have not fixed any bugs yet). Update: The scaling bug fixed.
Ant_222
Member
 
Posts: 468
Joined: 2010-7-24 @ 21:29

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

Postby Yesterplay80 » 2019-7-30 @ 13:51

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)
User avatar
Yesterplay80
Member
 
Posts: 414
Joined: 2016-2-23 @ 11:02
Location: Germany

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

Postby Ant_222 » 2019-8-01 @ 21:05

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.
Ant_222
Member
 
Posts: 468
Joined: 2010-7-24 @ 21:29

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

Postby Ant_222 » 2019-8-07 @ 20:39

Ant_222 wrote:I will prepare a version without the VSync feature for you test.
Attached.
You do not have the required permissions to view the files attached to this post.
Ant_222
Member
 
Posts: 468
Joined: 2010-7-24 @ 21:29

PreviousNext

Return to DOSBox Patches

Who is online

Users browsing this forum: No registered users and 2 guests