DOSBox ECE (for Windows & Linux)

[igermi]

Set output to opengl (or openglnb) as well.

I messed with this some more. For some reason, I can't get it to stretch the full width of the screen. opengl does "blend" the graphics a little better though.

[igermi]

One thing I notice (on windows with ECE) it almost seems like the volume in the game changes a little from time to time, without me adjusting it. I don't see a setting enabled (by default) that would do this. Has anyone else noticed this?

By the way this volume issue was not a dosbox issue, it was a windows issue with "smart volume" turned on. I disabled this and the volume fluctuations stopped.

[Delfino Furioso]

Set output to opengl (or openglnb) as well.

I messed with this some more. For some reason, I can't get it to stretch the full width of the screen.
opengl does "blend" the graphics a little better though.

assuming we're dealing with games using VGA 13h Mode
they'll output at a 320x200 resolution, corresponding to a 16:10 aspect ratio - there is no way to make them fit a 16:9 display

they will always be pillar-boxed (black borders on left and right) unless you:
- patch the renderer to crop the image (why would anyone wanto to do that?) along the top/bottom edges
- let your video driver (or display hardware) stretch the 16:10 image to the 16:9 aspect ratio


with aspect=true, dosbox will stretch that 320x200 game output to a 320x240 render output, which has a 4:3 (aka 12:9, aka 16:12) aspect ratio
in this case you'll experience a more pronounced pillar-boxing (bigger black borders)






otherwise, if the game implement VGA Mode X :
- the game output resolution will be 320x240 (with a 4:3/12:9/16:12 aspect ratio)
- dosbox "aspect" configuration parameter will have no effect
- you'll experience pillar-boxing






bottom line: the only way to have dosbox fill the entirety of a 16:9 screen without cropping anything is to let the windows/linux display driver stretch the image

[collector]

Seems odd to be trying to use ECE when you want to stretch the image to completely fill the screen. One of the main features of ECE is the Pixel Perfect patch, which is intended to display the screens with the proper perspective for graphical accuracy. It makes no sense to distort it.

[aardvark82]

640x480 --> 960x720 surfacenp scaling is glitchy since ECE r4180.3
Bottom of the window doesn't update properly. Works fine on r4180.2 and older.

[Yesterplay80]

Which game is that?

[aardvark82]

Angel Devoid. Same behavior also on Windows 3.1

[Yesterplay80]

Could you please post your conf file, so far I couldn't reproduce the issue. Does that happen only when you have to change the disc or is it a constant issue? If it happens only on certain events, a savegame would be helpful as well.

[aardvark82]

It's a constant behaviour with any 640x480 resolution game i've tested, but only when scaling to 960x720.
My dosbox.conf:

Code: Select all

[sdl]
fullscreen=false
fulldouble=false
fullresolution=1920x1080
windowresolution=960x720
output=surfacenp
surfacenp-sharpness=0
autolock=true
sensitivity=100
waitonerror=true
usescancodes=true
priority=higher,normal

[dosbox]
machine=svga_s3
memsize=16

[render]
frameskip=0
aspect=true
scaler=none

[cpu]
core=dynamic
cputype=auto
cycles=fixed 29400
#cycles=max 70%
cycleup=10
cycledown=20

[mixer]
nosound=false
rate=48000
blocksize=2048
prebuffer=80

[midi]
mpu401=intelligent
mididevice=fluidsynth
midiconfig=
fluid.soundfont=.\8MBGMSFX.SF2
fluid.gain= .25

[sblaster]
sbtype=sb16
sbbase=220
irq=7
dma=1
hdma=5
sbmixer=true
oplmode=auto
oplrate=48000
oplemu=default

[gus]
gus=false
gusrate=44100
gusbase=240
gusirq=5
gusdma=1
ultradir=C:\ULTRASND

[speaker]
pcspeaker=false
pcrate=44100
tandy=auto
tandyrate=44100
disney=false

[dos]
xms=true
ems=true
umb=true
keyboardlayout=US
files=50

[joystick]
joysticktype=none
timed=true
autofire=false
swap34=false
buttonwrap=false

[serial]
serial1=dummy
serial2=dummy
serial3=disabled
serial4=disabled

[autoexec]
@echo off
SET PATH=Z:\
keyb US 437
mount C ".\VirtualC\" -freesize 2162
imgmount D ".\ISO\Angel_1.cue" ".\ISO\Angel_2.cue" ".\ISO\Angel_3.cue" ".\ISO\Angel_4.cue" -t iso -fs iso
echo.
C:
cd angel
angel.exe


[Yesterplay80]

Ah, so it's specific to that resolution, I could reproduce it on my machine as well. I'll ask the author of the pixelperfect patch if he has an idea or even solution.

[ZakMcKracken]

maybe check this topic:
viewtopic.php?f=31&t=66491

So far we haven't seen a real cause. DOSBox seems to be getting the release events from SDL, but the test program didn't have the problem.

Thanks , I see that its most probably the same problem, weird thing is I only get this if I build it myself, I have to check what revision the pre build arch package is from and try to build that one, so no problem with ECE at all

EDIT: With a fresh vanilla build of rev. 4228 my problem is gone.

[Danfun64]

Do you think you can create your own git or svn repository instead of solely relying on zip files with the complete source code? It would make applying dosbox patches and then recompiling easier.

[Yesterplay80]

Do you think you can create your own git or svn repository instead of solely relying on zip files with the complete source code? It would make applying dosbox patches and then recompiling easier.

I already made an account on GitHub, but so far didn't find the time to figure out how to work with it. Consider this WIP.

[Teppic]

Is it possible to remove V-Sync in windowed mode somehow? I've tried a lot of different options in the config file and nothing seems to change the V-Sync for Jazz Jackrabbit. I get 60fps choppy gameplay. I also tried to add dosbox to Nvidia and turned off V-Sync there, but it doesn't make any difference.

(I assume it's V-Sync causing it?)

[Yesterplay80]

Is it possible to remove V-Sync in windowed mode somehow? I've tried a lot of different options in the config file and nothing seems to change the V-Sync for Jazz Jackrabbit. I get 60fps choppy gameplay. I also tried to add dosbox to Nvidia and turned off V-Sync there, but it doesn't make any difference.

(I assume it's V-Sync causing it?)

Which output are you using?

[Teppic]

Which output are you using?

openglpp

I got it working in PCEm with less screen tearing than full screen DOSBox though (or much less noticeable to me at least), so I'll likely keep using that emulator for this specific game.

[Pr3tty F1y]

Which output are you using?

openglpp

I got it working in PCEm with less screen tearing than full screen DOSBox though (or much less noticeable to me at least), so I'll likely keep using that emulator for this specific game.

On my AMD Radeon Fury X, I notice that forcing vsync within the DOSBox config is not effective. It doesn't actually turn on vsync (or at the very least, vsync ends up being disabled and the config file ignored).

It made playing Extreme Pinball a less than satisfying experience with the judder and screen tearing.

To remedy the issue, I have been using the RadeonPro add-on (although the driver controls may operate the same way), to force vsync as always on with Dosbox and it now functions beautifully.

[realnc]

Can I use "output = opengl" and "scaler = normal6x forced" and simply forget about it? Does it have any negative effect for games that don't require 6x? Also, some games have mixed resolutions, like 640x480 main gameplay, but 320x200 or 320x240 cutscenes, so the former would require 3x and only the latter 6x (I use a 1440p display.) Can I just use 6x for everything?

[realnc]

Can I use "output = opengl" and "scaler = normal6x forced" and simply forget about it?

Answering my own question: nah, it's slow as hell during fade effects. The game slows down to a crawl when using 6x with a 640x480 game.

[Yesterplay80]

Can I use "output = opengl" and "scaler = normal6x forced" and simply forget about it?

Answering my own question: nah, it's slow as hell during fade effects. The game slows down to a crawl when using 6x with a 640x480 game.

Unfortunately, that's normal because software scaling consumes massive amounts of CPU power.