VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 660 of 1550, by igermi

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 661 of 1550, by igermi

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 662 of 1550, by Delfino Furioso

User metadata
Rank Newbie
Rank
Newbie
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

Reply 663 of 1550, by collector

User metadata
Rank l33t
Rank
l33t

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.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 664 of 1550, by aardvark82

User metadata
Rank Newbie
Rank
Newbie

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.

Attachments

Reply 667 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

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.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 668 of 1550, by aardvark82

User metadata
Rank Newbie
Rank
Newbie

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

[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
Show last 40 lines
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

Reply 669 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

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.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 670 of 1550, by ZakMcKracken

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 671 of 1550, by Danfun64

User metadata
Rank Member
Rank
Member

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.

Reply 672 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 673 of 1550, by Teppic

User metadata
Rank Newbie
Rank
Newbie

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

My AdLib recordings

Reply 674 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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?

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 675 of 1550, by Teppic

User metadata
Rank Newbie
Rank
Newbie
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.

My AdLib recordings

Reply 676 of 1550, by Pr3tty F1y

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 677 of 1550, by realnc

User metadata
Rank Oldbie
Rank
Oldbie

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?

Reply 678 of 1550, by realnc

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 679 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
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.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)