Dosbox on pi 4, game window is fullscreen but not centered on screen

Efriim

@quicksilver
You can try output surface with aspect on, but it looks like butt. I'll let you know if I find a better way.

Actually there are other configurations that look worse.

mitu

Try changing aspect = true in the dosbox-SVN.conf, it should scale the output better.

quicksilver

@mitu you mean with dispmanx enabled too? I believe I already tried this but I will try again.

mitu

@quicksilver It doesn't matter if dispmanx is enabled.

quicksilver

@mitu with dispmanx enabled or disabled the aspect option doesn't help to center the game window. The aspect ratio and scaling are correct it's just that the game window is aligned to the left of the screen. On the pi 3 it's centered properly.

mitu

What's your screen resolution ?

quicksilver

@mitu 1920x1080

mitu

Will need to test with this resolution, mine is 4:3. You can try fiddling with the fullresolution option in the cofiguration file and set it to 1920x1080.

quicksilver

To get it to display properly scaled and centered I had to use these settings in my dosbox config:

fullscreen = false
windowresolution = 1920x1080
aspect = true

mitu

Nice. I just moved my Pi4 to my 1080p screen and experienced the issue - though I haven't got time to fiddle with all the options yes.

quicksilver

@mitu Ive been noticing that dosbox performance on my pi 4 is actually worse than my pi 3 in some cases. On my pi 4 setting output=overlay is the only way to get the games scaled to fullscreen. Output=surface is more performant but will not scale on a pi 4 (the dosbox-svn.conf even states that scaling is not possible with output=surface). Yet output=surface is the default setting on my pi 3 and it's scaled perfectly. How did scaling work on previous pi models?

mitu

It has to do with the framebuffer video driver included in the sdl1 library used by dosbox. The PI4 has a different kind of driver (it's basically emulated on top of the DRM/KMS primary video plane) which doesn't support resolution changing, as in the previous PI models.
For the Pi3, the scaling might have worked with 2 methods - either the fbcon SDL1 driver did the scaling to a resolution supported by the framebuffer, or the scaling was done by using the SDL1 dispmanx driver (PI specific). The former is not supported anymore on the Pi4, the latter works, but it's not 100% behaving the same as on a Pi3.

quicksilver

Thanks for the explanation, I'll keep fiddling with the display settings to see if it makes any difference. For now though dosbox performance on the pi 4 is very poor compared to the pi 3, some of my games aren't even playable anymore. Dosbox-sdl2 is worse and lr-dosbox is worse still. I think I'll try with dispmanx turned on even though the aspect ratio is wrong I'm curious if it improves performance at all.

quicksilver

Update:

Did some testing, dispmanx doesn't improve performance. It actually makes it worse.

It's output=overlay that's slowing everything down. Output=surface and everything is way faster and responsive, unfortunately it doesn't allow scaling so we're stuck with a small game window.

Is there anyway to use runcommand to force a lower resolution video mode? I tried it and doesn't seem to work, so I would assume that's part of what's not functioning on the pi 4?

mitu

@quicksilver said in Dosbox on pi 4, game window is fullscreen but not centered on screen:

Is there anyway to use runcommand to force a lower resolution video mode? I tried it and doesn't seem to work, so I would assume that's part of what's not functioning on the pi 4?

It works for SDL2 based emulators, RetroArch or Xorg based programs. Given dosbox is SDL1 app, it might not work.

quicksilver

@mitu that make sense why it isn't working then. I'll have to stick with using my pi3 for dos games for now in that case. Thanks again for the help.

quicksilver

Just an update for anyone following this thread. ~~I was able to get decent performance using dosbox-sdl2 by turning vsync off and using a lower resolution video mode in the runcommand menu. So it is a viable alternative for some games,~~ (see post below)however it doesnt seem to support .mp3/.ogg audio format which quite a number of GOG games utilize. This results in a CD-ROM not inserted error.

nemo93

hey @quicksilver perhaps you could give dosbox-staging a try? SDL2 as well as MP3/OGG are supported features. Devs are nice and eager to add more features like autotype or bundling DOS/32A directly - like Dosbox-X iirc. As of typing there's no support for MT-32 or Fluidsynth but it's being discussed.

I've created a (too long) thread to discuss this. Dosbox-staging is the version I'm now using as default along with dos32a extender, it provides nice compatibility, decent performance, no/less tearing (eg. Rayman, Raptor especially) and joypad support out-of-the-box on my Pi3B+.

quicksilver

I wanted to give another update about dosbox performance on the pi 4. I must have been mistaken about dosbox-sdl2, I cannot get decent performance using it. It's usable for undemanding titles but for late release dos titles it's not really up to the task. Currently I'm using dosbox-svn for all my games. The problem I have been having is that using output=overlay provides proper scaling but gives pretty poor performance. Output=surface is much more performant but doesn't support scaling, which means you end up with a nice fast dosbox but in a tiny little window. However I discovered that if I enable dispmanx, set output=surface and use windowed mode set to the resolution of my display I get a fullscreen image (albeit stretched) and much improved performance. Unfortunately dispmanx does hinder performance a little bit but it's still better than using output=overlay.

@nemo93 I had trouble building dosbox-staging. During the compilation process I kept getting an error saying it couldn't find "opusfile".

mitu

@quicksilver What games are you using as a benchmark ?

For the dosbox-staging compilation, you probably need libopus-dev and libopusfile-dev installed.