jmarsh wrote:

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 wrote:

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.

igermi wrote:

jmarsh wrote:

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

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.

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.

Which game is that?

Angel Devoid. Same behavior also on Windows 3.1

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.

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

1[sdl]
2fullscreen=false
3fulldouble=false
4fullresolution=1920x1080
5windowresolution=960x720
6output=surfacenp
7surfacenp-sharpness=0
8autolock=true
9sensitivity=100
10waitonerror=true
11usescancodes=true
12priority=higher,normal
13
14[dosbox]
15machine=svga_s3
16memsize=16
17
18[render]
19frameskip=0
20aspect=true
21scaler=none
22
23[cpu]
24core=dynamic
25cputype=auto
26cycles=fixed 29400
27#cycles=max 70%
28cycleup=10
29cycledown=20
30
31[mixer]
32nosound=false
33rate=48000
34blocksize=2048
35prebuffer=80
36
37[midi]
38mpu401=intelligent
39mididevice=fluidsynth
40midiconfig=
41fluid.soundfont=.\8MBGMSFX.SF2
42fluid.gain= .25
43
44[sblaster]
45sbtype=sb16
46sbbase=220
47irq=7
48dma=1
49hdma=5
50sbmixer=true
51oplmode=auto
52oplrate=48000
53oplemu=default
54
55[gus]
56gus=false
57gusrate=44100
58gusbase=240
59gusirq=5
60gusdma=1

61ultradir=C:\ULTRASND
62
63[speaker]
64pcspeaker=false
65pcrate=44100
66tandy=auto
67tandyrate=44100
68disney=false
69
70[dos]
71xms=true
72ems=true
73umb=true
74keyboardlayout=US
75files=50
76
77[joystick]
78joysticktype=none
79timed=true
80autofire=false
81swap34=false
82buttonwrap=false
83
84[serial]
85serial1=dummy
86serial2=dummy
87serial3=disabled
88serial4=disabled
89
90[autoexec]
91@echo off
92SET PATH=Z:\
93keyb US 437
94mount C ".\VirtualC\" -freesize 2162
95imgmount D ".\ISO\Angel_1.cue" ".\ISO\Angel_2.cue" ".\ISO\Angel_3.cue" ".\ISO\Angel_4.cue" -t iso -fs iso
96echo.
97C:
98cd angel
99angel.exe

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.

Qbix wrote:

maybe check this topic:
Dosbox dropping pressed keys?

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.

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.

Danfun64 wrote:

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.

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?)

Teppic wrote:

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?

Yesterplay80 wrote:

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.

Teppic wrote:

Yesterplay80 wrote:

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.

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 wrote:

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.

realnc wrote:

realnc wrote:

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.