"watching video" surely uses different settings (refresh rate etc.) even if the
same resolution is set, so that's no way to assure that it's not a graphics driver
problem (maybe even upgrade SDL).

First of all try to move the screen to the right using the knobs of your monitor.

wd wrote:

First of all try to move the screen to the right using the knobs of your monitor.

Sorry to interfere, but wd, Malvineous was talking about windowed modes, so adjusting the monitor would not help very much. The screenshot does very much look like an incorrectly adjusted CRT, though.

I'm no Linux user, so i can't be much of a help with that specific issue. Malvineous, i think you should give some additional details about your system and config, so other users can verify the problem (distribution, graphics card, graphics driver version, DOSBox version, SDL version, etc.).

You could also try using one of the OpenGL output methods (not sure which one is valid in Linux). The OpenGL output supports scaling, AFAIK. You could also play around with the "aspect" setting, and the values for the "scaler" option.

Thanks for your replies! It's definitely not the monitor (otherwise the screenshot would've appeared fine, I would've had to take a photo) and my screen settings are the same for watching video and DOSBox - don't change the resolution, don't change the refresh rate. FWIW that screenshot was taken on an LCD monitor anyway connected via DVI, but I had the same problem on my old CRT. Also if I take the screenshot from within DOSBox it comes out fine (so its internal idea of what's on the screen is fine), I had to use GIMP to grab it accurately. When it's in a window, the rest of the screen is fine, I can move windows over the top of the affected area without distorting them.

The thing that really proved to me that it's not the video card is that you only see the problem when the entire DOSBox screen is refreshed at once. If you only update the left or the right part of the screen it's fine, as you can see in this screenshot - the right-hand side of the screen is black, because everything that should be drawn there is ending up back on the left-hand side of the screen - but you don't get that funny interlaced effect because only one side of the screen is being drawn at a time, so there's no "conflict." To me, this looks more like a problem with DOSBox rather than SDL, but then again I don't know whether it's SDL that takes care of only updating the parts of the surface that have changed.

Unfortunately I can't try the OpenGL output methods, because they all crash my windowmanager (Compiz Fusion) - but that's the windowmanager's fault, as far as I can tell. On my last PC was using one of the OpenGL output methods precisely because it didn't have this problem.

I suspect the issue might be related to the screen resolution, as I've seen the problem at and above 1600x1200. I'm using the option "scaler=normal2x forced" and "aspect=true".

Combining my last PC and my current one (both of which had the problem) the specs seem pretty widespread - Slackware 32-bit/Gentoo 64-bit, nVidia FX5200/8600GT, various driver versions, currently 169.07, DOSBox 0.72, sdl-config --version reports 1.2.11.

I'd be surprised if the problem couldn't be reproduced by running in 1600x1200+ with the above settings, using the overlay output method, as that's all I've done in the past to see the problem!

So you want me to try these settings?

1[render]
2aspect=true
3scaler=normal2x forced
4
5[sdl]
6windowresolution=1700x1300
7output=overlay

And are you running in windowed mode, or fullscreen mode?

All I can say is that it looks perfectly normal here.

MiniMax: you did see that the problem is on Linux, didn't you? I think the parameters to test would be the DOSBox settings Malvineous is using (aspect=true, scaler=normal2x forced, windowresolution=1700x1300, output=overlay), Linux OS, high desktop resolution, NVidia card, and maybe Compiz Fusion (don't know if the WM could have an impact).

Malvineous: some more things you could try to narrow down the source of the problem:

- try different window sizes
- try different screen resolutions and colour modes
- try other scalers (with and without the "forced" parameter)
- switch the WM to something else, and try OpenGL output mode

One strange thing i've noticed:

I'd be surprised if the problem couldn't be reproduced by running in 1600x1200+ with the above settings

When running the desktop at 1600x1200 and setting DOSBox' window size to 1700x1300 (=window larger than desktop area), i wouldn't be suprised if there was graphics corruption. Are you sure the window size you're using is smaller than your current desktop resolution?

ADDiCT wrote:

MiniMax: you did see that the problem is on Linux, didn't you?

Sure did. I also noticed this passage:

Malvineous wrote:

To me, this looks more like a problem with DOSBox rather than SDL, but then again I don't know whether it's SDL that takes care of only updating the parts of the surface that have changed.

I don't know more than Malvineous about how DOSBox, SDL and the underlying OS interacts, but as I said, it works for me on Win XP, where the SDL-library comes as part of DOSBox. If I remember correctly, on Linux, SDL is a separately installed component of unknown origin, so that is where I would look first.

Okay, I've done some more experimenting, and to answer your questions:

The problem exists in both windowed and fullscreen mode. The window is 1280x800, which is and has always been less than the screen resolution. The problem exists at 1600x1200 and 2560x1600.

The window size is at the "default", i.e.

1[sdl]
2windowresolution=original
3output=overlay
4
5[render]
6aspect=true
7scaler=normal2x forced

If I remove "forced" from the "scaler" option, then the problem goes away, however this is because all the "high resolution" modes (the ones that have the problem) are no longer scaled. For example the initial text-mode screen (the one in my screenshots) is 640x400, and this appears fine. But when the "forced" option is in effect the window is doubled to 1280x800, and the problem appears.

If I leave the "forced" option on, but change the "windowresolution" to 640x400, then the window goes back to the non-scaled size, but the wrapping problem is still there.

Likewise if I set the windowresolution to 1280x800 but remove the "forced" option, the window is at the correct size and the wrapping problem is not there (but of course it doesn't look as good because the scaler isn't being used.)

So it looks like the problem lies with the "forced" option to the scaler. I notice that in the two screenshots I posted, the wraparound occurs at X-coordinate 1023, which would make sense if only 10-bits were being used for storing the number, as 1024 would wrap around back to zero.

I've also tried some of the other scalers. Without the "forced" option they don't affect hires modes, so I tried them all with the "forced" option:

• normal3x forced - segfault
• advmame2x forced - has same wrapping problem
• advmame3x forced - segfault
• hq2x forced - works, but doesn't resize in full-screen mode
• 2xsai forced - works, but doesn't resize in full-screen mode
• super2xsai forced - works, but doesn't resize in full-screen mode
• supereagle forced - works, but doesn't resize in full-screen mode
• advinterp2x - works, but doesn't resize in full-screen mode
• advinterp3x - works, but doesn't resize in full-screen mode
• scan2x - works, but doesn't resize in full-screen mode
• rgb2x - works, but doesn't resize in full-screen mode
• tv2x - works, but doesn't resize in full-screen mode

I have the option "fullresolution=2560x1600" in the [sdl] section, to prevent my screen resolution from being changed when I switch into full-screen mode. The pattern I can see here is that those scalers that expand their display to this full screen resolution are affected by the problem, but the other scalers that don't expand (they just draw the same size display in the middle of the full screen window) aren't affected.

The problem doesn't appear with the "surface" output method, but that too does not resize to take up the whole screen when switching into full-screen mode. (Perhaps it does not report the true screen resolution to the scalers?)

Nice work Malvineous. I am too tired to do any testing now. Will come back later.