Not much you can do other than create a custom resolution to move the scaling to the graphics driver.

Did you test other output modes and with the ATI binary blob driver?

Edit: in dosbox-SVN source code, one difference between normal2x and rgb2x is the color depth output. It appears that normal2x may output 8bpp but rgb2x is at 15bpp or higher (or RGB mode). I previously posted a patch to fix a related issue and you may test it in a custom build.

I decided to try out the SVN Daum build under Wine, and I don't have this issue with the output set to direct3D, but I start running into other issues, like microstutter, and One Must Fall crashing after a match ends. 🤣 Being able to use shaders is pretty awesome though.

Using the Linux Daum build with output set to surface, I get pretty much the same results as I do in the normal 0.74 build with opengl, save for more accurate textmode scaling, and when I try opengl, it displays in a tall, horizontally-squashed window. Click the screenshot below to see.

@truth5678: I found your website, and the opengl DosBox patches on it. Do I just apply them to the stock DosBox source?

It's difficult to help since you haven't followed the above suggestions. It also may not help to detour in an effort to find negative results from other builds and configurations, especially given the use of the open source video driver (which also has gone untested): http://www.x.org/wiki/RadeonFeature/ ; http://www.reddit.com/r/linux_gaming/comments … vers_for_a_old/.

I tried the binary blob driver, and I've found no difference other than poorer performance in certain applications, namely Chocolate Doom, and Foobar2000 when run under Wine.

And I have tried other output modes. Nothing seems to help. The only way I can get proper scaling with the rgb2x shader is by running with the Windows version of SVN Daum, but that has its own issues. I'll give the mainline Windows Dosbox build a try next.

EDIT: I've found that using the SVN Daum build with the output mode set to ddraw solves my problems. It even works fine with the open source radeon drivers. The fglrx drivers gave me a significant boost in 3dmark2001se under Wine, and a small boost in Black Shades, also under Wine, but they caused problems elsewhere.

Other options include compiling your own dosbox build and following gog.com's dosbox linux requirements.

Definitely test this patch in your linux dosbox build: http://sourceforge.net/p/dosbox/bugs/385/.

I've tried compiling DosBox before, and it's much more of a hassle than it's worth. I'm just going to stick with using the Windows version through Wine. The mainline build works great, and I'd almost argue that it renders the native Linux version unnecessary, at least on x86. 😉

There's nothing wrong with using wine. In fact there is current work on updating its drivers which should result in a substantial speed increase. I forgot the details, but mesa3d and a fork with d3d9 work has further information about it. 😀

You may also look at the wine configuration file for additional settings and this article has some interesting points about wine in general: http://www.phoronix.com/scan.php?page=news_item&px=MTI5NjU.

I used to hate using wine, and I trashed many a Linux installation over problems I've had with it, but that was before I learned how to use seperate prefixes for my programs. Now, I use Linux as my everyday OS, and Wine works great for the programs I use on it.

Also, I ran mprime recently, and it encountered a fatal error after running for an hour, so I tweaked my overclocking settings and ran it again for 12 hours straight. No errors. 😁 I figure this may be what caused OMF to crash in the Daum build. I was having problems in other programs too, like Pale Moon and OpenLugaru.

That's good news. If you find a configuration that works, and the linux distribution updates to a newer version, then you may always edit the default repository "url" to point to an archive with software for your version. Otherwise, it takes some time to upgrade the OS and find a stable configuration and customization for everything.

Sorry for bumping this old thread, but as someone that loves the rgb scaler, I managed to get it displayed within the full screen on dosbox 0.74 setting it like this: (for 1080p displays only)

fullscreen=true
fulldouble=false
fullresolution=1280x720 (1600x900 in case a game runs at 800x600)
output=ddraw (obviously)
aspect=true
scaler=rgb3x forced

Tested above settings with Screamer Rally, Indycar Racing 2, Nascar Racing 2 (all ran at 640x480) and Shadow Warrior (800x600).

I like this way a lot hence it gives a subtle posphor effect, with great quality.

Hope this helps the OP or anybody else.

Regards.

mrk1001 wrote:

Sorry for bumping this old thread, but as someone that loves the rgb scaler, I managed to get it displayed within the full scree […]
Show full quote

Sorry for bumping this old thread, but as someone that loves the rgb scaler, I managed to get it displayed within the full screen on dosbox 0.74 setting it like this: (for 1080p displays only)

fullscreen=true
fulldouble=false
fullresolution=1280x720 (1600x900 in case a game runs at 800x600)
output=ddraw (obviously)
aspect=true
scaler=rgb3x forced

Tested above settings with Screamer Rally, Indycar Racing 2, Nascar Racing 2 (all ran at 640x480) and Shadow Warrior (800x600).

I like this way a lot hence it gives a subtle posphor effect, with great quality.

Hope this helps the OP or anybody else.

Regards.

My original question was regarding the Linux build, so ddraw won't really help. 🤣 As far as the other settings, I could see them working fine in fullscreen, but I think I specifically wanted to run in windowed mode.

Well my bad then. My post was due to this part:

or the game uses a small area in the center of the screen in fullscreen mode

.

I was struggling also with that then I messed up with the resolutions until I found the sweet spot to get the scaler to use the whole screen.

regards.