VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 920 of 1550, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
XxMiltenXx wrote on 2019-12-11, 17:02:

2. openglpp & glfullvsync

Please, post your full settings for this test case and tell me if there is a message in the log window about the activation of VSync.

Edit: as far as I understand, if the game itself is not v-synced, DOSBox can't help.

Last edited by Ant_222 on 2020-01-07, 12:50. Edited 1 time in total.

Reply 921 of 1550, by Kisai

User metadata
Rank Member
Rank
Member
Ant_222 wrote on 2020-01-06, 16:56:

and should never be used.

So all my work has been vain? Oh, no...

Not to open that fight up again, but when you released the patches originally, they made dosbox unusable, and ECE, out-of-the-box behaves exactly as the poster described. It tears, it lags, it feels like a fight to make work. That's why I never incorporate it in my own builds. If you feel ambitious, you should actually create a vulkan renderer and side-step the renderpath problem itself. However the problem still lies in how SDL is used.

If you feel ambitious, what I would like to see is the pixel perfect patch applied to the ZMBV encoder as an option, as that would remove the need for often worse nearest-neighbor rescaling done by ffmpeg later. Unfortunately I think it calls for a different codec trick (eg stored as 320x200 but DAR'd corrected to pixel perfect so video editors, ffmpeg, youtube, etc all display it correctly. It pains me to see all these smushed dosbox and emulator videos on youtube.)

Reply 922 of 1550, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Kisai wrote on 2020-01-07, 02:13:

Not to open that fight up again, but when you released the patches originally, they made dosbox unusable, and ECE, out-of-the-box behaves exactly as the poster described. It tears, it lags, it feels like a fight to make work..

I for one have never had such problems with the default settings on my old PC with AMD A4-3400 APU. Did you check the CPU load? How high is it with

output              = openglpp
fullborderless = false
fulldouble = false
fullresolution = desktop
windowresolution = desktop
glfullvsync = false
scaler = none

in both windowed and fullscreen mode? If high, then please post the game and the contents of the console log. I want to reproduce the tearing and lagging you tell about.

Kisai wrote on 2020-01-07, 02:13:

If you feel ambitious, you should actually create a vulkan renderer and side-step the renderpath problem itself. However the problem still lies in how SDL is used.

No reason to do it since SDL 2.0 solves all these problems.

Maybe we should rather continue the discussion in the thread for the Pixel-Perfect patch?

Reply 923 of 1550, by willow

User metadata
Rank Member
Rank
Member

good evening
I have a problem with dosbox ece and key mapper.
When I use crtl+F1 to use key mapper, display become black and key mapper is not displayed.
If I use dosbox daum version, key mapper works.

I use dbgl.

Does anybody have any solution?
edit: I have found the problem. It's a problem between dosbox and nvidia geforce experience

Reply 924 of 1550, by dreamer_

User metadata
Rank Member
Rank
Member

@Yesterplay80, @Ant_222
I think you already noticed, that recent SVN changes conflict with pixel-perfect patch.

Conflicts are happening with revisions trunk@4305 and trunk@4306; I already dealt with these when merging r4306 into dosbox-staging master, so decided to help you out a little:

Branch po/ece-r4305-1 contains ECE patch series rebased on top of r4305 (b59d73). Besides rebasing, I included updated metadata in commit messages wherever I could find it (authors, dates, links to specific Vogons posts). When importing to Git I cleaned all whitespace errors, so they should not issue whitespace warnings during application. diff format got unified and all patches should apply cleanly with patch -p1. Zip with numbered patch files attached.

I don't plan to work on rebasing ECE on top of 4306 ATM - conflicts in there are much more severe.

Attachments

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 925 of 1550, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
dreamer_ wrote on 2020-01-08, 14:57:

I don't plan to work on rebasing ECE on top of 4306 ATM - conflicts in there are much more severe.

That is the problem. Some major changes are currently being implemented, but I hope the developers will let me know when they have finished and I can fix the patch without risking that it breaks the next day.

Reply 926 of 1550, by XxMiltenXx

User metadata
Rank Newbie
Rank
Newbie

@Ant_222 @Kinsie

The tearing issue only occurs when machine is set to vesa_nolfb. If I use vesa_nolfb it tears even when I use the internal DOSBox video recording. It doesn't matter if V-Sync is enabled or not. If I enable V-Sync (and borderless fullscreen is disabled) I do get the message in my DOSBox terminal that V-Sync is correctly enabled, but it still tears with vesa_noflb:

Duke3DTearing.png
Filename
Duke3DTearing.png
File size
132.76 KiB
Views
3112 views
File license
Public domain

When set to svga_s3 it doesn't tear. However, for Duke Nukem 3D (and VESA resolutions) I cannot use svga_s3 as the HUD weapon sprites will sometimes flicker/vanish., This does not happen in with vesa_noflb:

Duke3DSpriteFlicker.png
Filename
Duke3DSpriteFlicker.png
File size
34.41 KiB
Views
3112 views
File license
Public domain

Prince of Persia 1 has the same issue, however, there it is set to svga_s3. It even tears with using DOSBox' internal video recording:

PoP1Tearing.png
Filename
PoP1Tearing.png
File size
6.32 KiB
Views
3108 views
File license
Public domain

I am using DOSBox Game Launcher.

Here's my Prince of Persia config

[sdl]
windowresolution=1280x960
fullscreen=true
glfullvsync=true
usescancodes=false
mapperfile=1.map

[dosbox]
captures=..\captures\1
memsize=32

[cpu]
core=normal
cycles=6000
cycleup=250
cycledown=250

[sblaster]
sbtype=sbpro2
oplrate=49716
oplemu=nuked
irq=5

[speaker]
pcspeaker=false
tandy=off
disney=false

[joystick]
joysticktype=2axis
timed=false

[midi]
midiconfig=delaysysex
mt32.analog=3

[render]
scaler=normal2x

[glide]
lfb=

[mixer]
rate=49716

[autoexec]
mount C "."
mount D "I:\" -t cdrom
mixer.com master 50:50
C:
cd \PRINCE
PRINCE.EXE
exit

Here's my Duke Nukem 3D config

[sdl]
windowresolution=1280x960
fullscreen=true
sensitivity=100,0
usescancodes=false
mapperfile=11.map

[dosbox]
captures=..\captures\11
machine=vesa_nolfb
memsize=32

[cpu]
core=dynamic
cycles=max
cycleup=250
cycledown=250

[sblaster]
oplrate=49716
oplemu=nuked
irq=5

[speaker]
pcspeaker=false
tandy=off

[render]
scaler=normal2x

[glide]
lfb=

[joystick]
joysticktype=none

[autoexec]
mount C "."
C:
cd \DUKE3D
DUKE3D.EXE
exit

Here's my Default config

[sdl]
fullresolution=2560x1440
windowresolution=1280x1024
fullscreen=true
glfullvsync=true
mapperfile=%1$d.map

[cpu]
core=dynamic
cycles=max

[sblaster]
oplrate=49716
oplemu=nuked
irq=5

[speaker]
pcspeaker=false
tandy=off
disney=false

[render]
scaler=normal2x

[glide]
lfb=

[dosbox]
memsize=32

[midi]
mt32.dac=auto

[joystick]
joysticktype=none

[autoexec]
mount C "."
exit

All other settings are the default ones.

Reply 927 of 1550, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

What happens when you try nolfblim?
NOLFBLIM (updated NOLFB) - Enables VSYNC for DOS Games

How To Ask Questions The Smart Way
Make your games work offline

Reply 929 of 1550, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
XxMiltenXx wrote on 2020-01-13, 19:05:

The tearing issue only occurs when machine is set to vesa_nolfb. If I use vesa_nolfb it tears even when I use the internal DOSBox video recording. It doesn't matter if V-Sync is enabled or not.

Does it tear only with the outputs introduced my patch, or with other outputs too?

XxMiltenXx wrote on 2020-01-13, 19:05:

If I enable V-Sync (and borderless fullscreen is disabled) I do get the message in my DOSBox terminal that V-Sync is correctly enabled, but it still tears with vesa_noflb:
Duke3DTearing.png

You mean openglpp output with glfullvsync in fullscreen mode, right? Have you tried surfacepp with fulldouble in fullscreen?

XxMiltenXx wrote on 2020-01-13, 19:05:

When set to svga_s3 it doesn't tear. However, for Duke Nukem 3D (and VESA resolutions) I cannot use svga_s3 as the HUD weapon sprites will sometimes flicker/vanish., This does not happen in with vesa_noflb

If reproducible in stock DOSBox with openglnb, this sounds like a bug worth the attention of the developers...

XxMiltenXx wrote on 2020-01-13, 19:05:

Prince of Persia 1 has the same issue, however, there it is set to svga_s3. It even tears with using DOSBox' internal video recording

In stock unmodified DOSBox with openglnb, too? Then I suggest that you report this behavior in a separate thread.

If, on the other hand, these problems appear in ECE only, then I must have broken something.

Reply 930 of 1550, by XxMiltenXx

User metadata
Rank Newbie
Rank
Newbie
Ant_222 wrote on 2020-01-13, 20:44:

Does it tear only with the outputs introduced my patch, or with other outputs too?

You mean openglpp output with glfullvsync in fullscreen mode, right? Have you tried surfacepp with fulldouble in fullscreen?

If reproducible in stock DOSBox with openglnb, this sounds like a bug worth the attention of the developers...

It happens with openglnb too as well as with surfacepp with fulldouble. Since DosFreak's fix worked, I think it's an engine issue. Specifically with the Build engine.

Ant_222 wrote on 2020-01-13, 20:44:

In stock unmodified DOSBox with openglnb, too? Then I suggest that you report this behavior in a separate thread.

If, on the other hand, these problems appear in ECE only, then I must have broken something.

I tested Prince of Persia 1 with DOSBox 0.74-3 and there it tears as well. So it's an issue with DOSBox, not yours. I will see that I contact them. However, it might also be an engine issue like with Build games, but a different one.

Reply 931 of 1550, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

I wouldn't say it's a DOSBox issue rather a game issue. It can be hacked around in certain cases for some games either via TSR or with a patch for DOSBox.

The flicker issue with the build engine is a game issue. Back in the day we used SDD to disable the LFB due to game issues so that's why the setting is in DOSBox.

The official version of DOSBox does attempt vsync, make sure doublebuffer is set to true which may work in some cases.

NOLFB was created by Ken Silverman since games that used Vesa 2.0 has issues with 2000 and above NTVDM so if the game had a fallback to 1.2 then NOLFB got them working but it also works in DOS as well.

NOLFBLIM was created since when NOLFB does the fallback to 1.2 then no more vsync.

How To Ask Questions The Smart Way
Make your games work offline

Reply 932 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
dreamer_ wrote on 2020-01-08, 14:57:
@Yesterplay80, @Ant_222 I think you already noticed, that recent SVN changes conflict with pixel-perfect patch. […]
Show full quote

@Yesterplay80, @Ant_222
I think you already noticed, that recent SVN changes conflict with pixel-perfect patch.

...

I don't plan to work on rebasing ECE on top of 4306 ATM - conflicts in there are much more severe.

Yes, that's why I didn't update ECE since r4301, because I was waiting for Ant_222 to update his patch. Thanks for generating the updated ones! 😀

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

Reply 933 of 1550, by 7F20

User metadata
Rank Member
Rank
Member
DosFreak wrote on 2020-01-13, 23:21:

NOLFB was created by Ken Silverman since games that used Vesa 2.0 has issues with 2000 and above NTVDM so if the game had a fallback to 1.2 then NOLFB got them working but it also works in DOS as well.

This reminded me of the issues with VESA drivers in the 90's. I recently watched this video where youtuber LGR is trying to run duke nuken in dos 6.22 on a newer machine: https://www.youtube.com/watch?v=bS9hiSwL1KY
He can't get the VESA drivers to work, but some other driver worked fine.

Reply 934 of 1550, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
7F20 wrote on 2020-01-23, 19:23:

I recently watched this video where youtuber LGR is trying to run duke nuken in dos 6.22 on a newer machine: https://www.youtube.com/watch?v=bS9hiSwL1KY
He can't get the VESA drivers to work, but some other driver worked fine.

Actually what LGR experienced in the video with his Geforce 980 is a BIOS bug of newer generation Geforce cards:
NVIDIA Kepler/Maxwell/Pascal VESA Bios Bug (workaround found)

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 936 of 1550, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
James-F wrote on 2020-01-24, 07:36:

I really don't like thinking about the discontinuation of ECE edition.... that sucks. :'(

Was ist los?

All hail the Great Capacitor Brand Finder

Reply 937 of 1550, by dreamer_

User metadata
Rank Member
Rank
Member
gdjacobs wrote on 2020-01-25, 00:31:

Was ist los?

DOSBox SVN made changes conflicting with several out-of-tree patches (including at least 2 distributed via ECE). Conflicts were introduced by SVN revisions: r4305, r4306, r4308 (r4308 is HEAD revision at the moment).

I dealt with these conflicts already when merging svn/trunk into dosbox-staging master, so helped out with resolving conflict with r4305 for ECE, but you'll need to wait for patch authors to work on resolving other ones (resolving merge conflicts in Git is much easier than resolving rebase conflicts in big out-of-tree patches in SVN).

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 938 of 1550, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Okay, I saw that. Seemed more like a speed bump rather than a road block, so I was wondering if there was something else going on.

I still think YP80 incorporates generally the most useful subset of patches without having to throw in the kitchen sink as well. Losing ECE would be a blow to the community unless someone else stepped up to maintain a similar branch.

All hail the Great Capacitor Brand Finder

Reply 939 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
gdjacobs wrote on 2020-01-26, 02:11:

Okay, I saw that. Seemed more like a speed bump rather than a road block, so I was wondering if there was something else going on.

TBH, the speed bumps are getting worse and worse. First I couldn't get krcrofts patch working any more, because it now depends on opusfile, which I can't get compiled under mingw, but switching to MSYS2 didn't work neither because I can't get SDL-sound working there. Then some update to SVN "killed" Ant_222s pixel perfect patch. Now the latest updates to SVN broke compatibility with VileRancours patch for the 4-6x scalers... I'm no developer and certainly no pro at setting up dev environments, plus time is short anyway atm. And it probably won't get better in the near future.

Honestly, ECEs future doesn't look to bright atm... Maybe it's time to quit and leave the stage to more capable people, who know better what they're doing (I'm looking at DOSBox-X or dosbox-staging).

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