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.

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

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

1output              = openglpp
2fullborderless      = false
3fulldouble          = false
4fullresolution      = desktop
5windowresolution    = desktop
6glfullvsync         = false
7scaler              = 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?

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

@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.

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.

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

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:

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:

I am using DOSBox Game Launcher.

All other settings are the default ones.

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

It does fix the tearing for Duke Nukem 3D! Thanks.

Any idea about Prince of Persia though?

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.

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.

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.

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! 😀

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.

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)

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

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?

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

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.

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