DOSBox ECE (for Windows & Linux)

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Re: DOSBox ECE (for Windows & Linux)

Postby KainXVIII » 2019-11-30 @ 13:33

realnc wrote:The DOSBox-SVN core in RetroArch does this.

Whoah, i need to check it.
User avatar
KainXVIII
Member
 
Posts: 340
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: DOSBox ECE (for Windows & Linux)

Postby Pr3tty F1y » 2019-12-08 @ 11:29

What is the expected performance of software 3DFX emulation in DOSBox ECE (latest release r4294)?

I only ask as I'm seeing *really* choppy performance in Carmaggedon and Elder Scrolls: Redguard. However, despite the choppy performance, dosbox.exe never maxes out a single thread (25%) on my 4 core i5-2500k@4.4ghz. Now, I know that CPU is getting a bit long in the tooth, but the highest usage I've seen from dosbox.exe is 22%.

With how choppy the framerate is, you'd think it would me maxing out a single thread at 25%. This leads me to believe that maybe the issue is the timing within the emulation itself and perhaps there's simply a lot of waiting between the emulated CPU and emulated 3DFX GPU, but I was wondering if anyone was getting any better performance.



Also another interesting tidbit (which may already be known). DOSBox ECE's aspect ratio correction squashes the software emulated 3DFX output into too narrow an AR. You have leave AR correction off for 3DFX emulation to have the correct AR (at least in my setup).
Pr3tty F1y
Newbie
 
Posts: 12
Joined: 2017-8-19 @ 21:22

Re: DOSBox ECE (for Windows & Linux)

Postby Kisai » 2019-12-09 @ 10:22

Pr3tty F1y wrote:With how choppy the framerate is, you'd think it would me maxing out a single thread at 25%. This leads me to believe that maybe the issue is the timing within the emulation itself and perhaps there's simply a lot of waiting between the emulated CPU and emulated 3DFX GPU, but I was wondering if anyone was getting any better performance.


The problem is that nothing in Dosbox is multithreaded (except for mt32/fluidsynth if compiled to do so), and the 3D software emulator can not take advantage of multithreaded rendering. If you want higher frame rate, use one of the hardware accelerated options.

Now in THEORY yes, the software emulator could be sped up, but that's largely a fruitless exercise without having a multithreaded render path, and that just will not exist in SDL. You simply can't split the framebuffer, and synchronizing it across threads leads to more latency and screen tearing when one thread completes before another.

https://github.com/mamedev/mame/blob/81 ... voodoo.cpp

Note that it actually does do threading in the source, though I don't know if it's actually invoking hardware threads. At any rate SDL1.2 only supports OpenGL/DX9 level functionality and has no way to split the workload to threads. SDL2 doesn't either, though very recent update supports batching draw calls like a command buffer in 2.0.9 (13 months ago.) That is still something Dosbox does not take advantage of.
Kisai
Member
 
Posts: 138
Joined: 2010-5-05 @ 08:04

Re: DOSBox ECE (for Windows & Linux)

Postby XxMiltenXx » 2019-12-11 @ 17:02

Hey, I have a tearing issue with DOSBox ECE. As I want to record games, it's kind of a big issue.

Here's my setup:
1440p screen with 144Hz G-Sync, but G-Sync is disabled
Capture card with 1440p and 144Hz. They are both cloned with each other, the Capture card is main display device.
Windows 10 v1903 (Version 10.0.18362.476)

I have tried multiple things already, but to no avail:
1. openglpp & fullborderless
2. openglpp & glfullvsync
3. Force V-Sync externally via the NVIDIA Control Panel
4. surfacepp & fullborderless
5. surfacepp & fulldouble

1-4 didn't have any effect at all and #5 only degraded the performance a lot but the tearing was still there.

In order to get rid of the tearing during recording, I also tried to record with hooks instead. I have tried Bandicam, OBS & MSI Afterburner, but what puzzles me most is, that even the recordings with hooks have screen tearing. Usually hooked recording (at least with MSI Afterburner) shouldn't suffer from tearing, so I have really no idea what's going on there anymore.

I have also tried DOSBox-X and DOSBox-DAUM. DOSBox-X suffers from the same tearing as DOSBox-ECE does. Only DOSBox-Daum didn't have any tearing at all, but that one uses Direct3D instead, however, it doesn't give all features that I use in DOSBox-ECE (nuked OPL, better PC speaker emulation, pixel-perfect-scaling).

The resolution is correctly set to "Desktop".

Do you guys have any ideas on how to alleviate the issue?
XxMiltenXx
Newbie
 
Posts: 13
Joined: 2014-5-21 @ 13:53

Re: DOSBox ECE (for Windows & Linux)

Postby realnc » 2019-12-11 @ 17:52

XxMiltenXx wrote:Hey, I have a tearing issue with DOSBox ECE. As I want to record games, it's kind of a big issue.

Which games? Some DOS games don't do vsync.

Games I know of that do vsync and thus you can use them to test if vsync really works for you or not, are Stargunner (70Hz), Jazz Jackrabbit (60Hz default, 70Hz when started with "JAZZ.EXE /VGA") and Turrican 2 (60Hz).
User avatar
realnc
Member
 
Posts: 460
Joined: 2010-10-13 @ 11:02

Re: DOSBox ECE (for Windows & Linux)

Postby Pr3tty F1y » 2019-12-11 @ 21:28

Kisai wrote:The problem is that nothing in Dosbox is multithreaded (except for mt32/fluidsynth if compiled to do so), and the 3D software emulator can not take advantage of multithreaded rendering. If you want higher frame rate, use one of the hardware accelerated options.

Now in THEORY yes, the software emulator could be sped up, but that's largely a fruitless exercise without having a multithreaded render path, and that just will not exist in SDL. You simply can't split the framebuffer, and synchronizing it across threads leads to more latency and screen tearing when one thread completes before another.

https://github.com/mamedev/mame/blob/81 ... voodoo.cpp

Note that it actually does do threading in the source, though I don't know if it's actually invoking hardware threads. At any rate SDL1.2 only supports OpenGL/DX9 level functionality and has no way to split the workload to threads. SDL2 doesn't either, though very recent update supports batching draw calls like a command buffer in 2.0.9 (13 months ago.) That is still something Dosbox does not take advantage of.


Understood. Thank you. I figured it was something along those lines, but I just wanted to ask in case I was missing something.
Pr3tty F1y
Newbie
 
Posts: 12
Joined: 2017-8-19 @ 21:22

Re: DOSBox ECE (for Windows & Linux)

Postby XxMiltenXx » 2019-12-11 @ 21:29

realnc wrote:Which games? Some DOS games don't do vsync.


Ah, I thought it works the same through all games, so I assumed more games would be affected. Thus far I had tested Duke Nukem 3D, which seems to be a worst-case scenario depending on the settings (see below). DOSBox-X was far worse there, so I assumed DOSBox-ECE would be the same.

Anyway, I made a list here to show which games work and which don't.

Code: Select all
Commander Keen 1 = No Tearing
Commander Keen 4 = No Tearing
Jazz Jackrabbit = No Tearing
Prince of Persia = Low Tearing (fairly rare)
Realms of the Haunting = No Tearing
Terminal Velocity = Minimal Tearing (very rare)
Descent = Minimal Tearing (very rare)
Doom II = No Tearing
Red Baron = No Tearing
Rise of the Triad = No Tearing
Duke Nukem 3D (vesa_noflb) & 640x480 = Moderate Tearing (often)
Duke Nukem 3D (svga_s3) & 640x480 = Minimal Tearing (very rare)
Duke Nukem 3D (svga_s3) & 320x200 = Moderate Tearing (often)


So apparently it's working, but it's also game resolution and machine setting dependant within DOSBox. However, for Duke Nukem 3D I kinda need "vesa_noflb" or otherwise I do get "sprite glitches".
For Prince of Persia, the tearing might be rare, but still noticable if the prince suddenly gets cut in half.

Those with minimal tearing it's extremely small and only visible if you go frame-by-frame and even then you really have to search for it, so there's no issue with them.

But I guess it cannot be helped with Duke 3D and PoP then. I will try out different settings for Duke 3D, to see if I can get it working with V-Sync and without sprite glitches. For Prince of Persia I don't know what I could change to alleviate it.

So thanks for the clarification.
XxMiltenXx
Newbie
 
Posts: 13
Joined: 2014-5-21 @ 13:53

Re: DOSBox ECE (for Windows & Linux)

Postby 7F20 » 2019-12-12 @ 04:19

Been trying to get ECE running on my Raspberry Pi 4. Have been running the SVN build up until now with no serious issues, but I crave pixel-perfect because I'm playing on an arcade monitor (CRT).

I successfully compiled version 4280 on raspbian buster, but I'm have an issue starting up.

ECE is complaining on startup that I don't have any 640x480 resolution or higher resolution available. I put surfacepp and vgaonly in the config file, so that should take opengl out of the equation and set the console resolution at 320x240. I've also tried to use overlay and force windowed mode to 320x240.

Any ideas about this behavior and how I can overcome?
User avatar
7F20
Newbie
 
Posts: 23
Joined: 2015-4-10 @ 04:06

Re: DOSBox ECE (for Windows & Linux)

Postby 7F20 » 2019-12-12 @ 04:42

gdjacobs wrote:
Scandy wrote:There's a way to build and run DOSBOX ECE on Raspberry Pi 4?


Several ways. I usually use the build tools patch from the Debian source package.


gdjacobs, could you elaborate a bit on the "build tools patch from the Debian source package? you can just patch vanilla to be ECE? is that by downloading a .diff file and patching the source before compile?

Sorry, but I seriously can't seem to figure out what you're saying can be done.
User avatar
7F20
Newbie
 
Posts: 23
Joined: 2015-4-10 @ 04:06

Re: DOSBox ECE (for Windows & Linux)

Postby gdjacobs » 2019-12-12 @ 16:42

The patch I'm referring to adds information to build a debian package from source.
https://wiki.debian.org/BuildingTutoria ... ce_package

Get the ECE source package and unpack it. Then get this archive and unpack it in the source directory. Optionally, remove the patch directory as it might not apply cleanly to ECE.
http://deb.debian.org/debian/pool/main/ ... ian.tar.xz
User avatar
gdjacobs
l33t++
 
Posts: 6776
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: DOSBox ECE (for Windows & Linux)

Postby 7F20 » 2019-12-12 @ 18:11

gdjacobs wrote:The patch I'm referring to adds information to build a debian package from source.


Thanks so much for the more detailed explanation. I will give this a shot tonight.


I wonder if this will solve my issue in which dosbox ECE complains of no resolution of 640x480 available? (because I'm running this on a 320x240 display)
User avatar
7F20
Newbie
 
Posts: 23
Joined: 2015-4-10 @ 04:06

Re: DOSBox ECE (for Windows & Linux)

Postby pantercat » 2019-12-12 @ 20:36

I've never compiled ECE on raspberry. However the following works for me in debian x64.

1. Download and extract DOSBox ECE rXXXX (Linux source).7z https://dosboxece.yesterplay.net/download/
2. Copy sdk2_*.h from OpenGlide source (OpenGLide_XXX_src.zip) to the ECE's include directory. https://sourceforge.net/projects/openglide/
3. Compile && (optionally) discard symbols from binary to gain some space.

./autogen.sh && ./configure && make && strip src/dosbox
pantercat
Newbie
 
Posts: 47
Joined: 2018-9-06 @ 17:22

Re: DOSBox ECE (for Windows & Linux)

Postby 7F20 » 2019-12-12 @ 21:25

pantercat wrote:I've never compiled ECE on raspberry. However the following works for me in debian x64.


Thanks. I believe that this is essentially what I did. Problem is that it's crashing on startup because ECE seems to be demanding a minimum of 640*480 and I'm running a CGA monitor at 320*240.

Regular dosbox doesn't do this, so I'm hopeful that someone can help me fix it. I fiddled with all the config.txt settings that seems to make sense.
User avatar
7F20
Newbie
 
Posts: 23
Joined: 2015-4-10 @ 04:06

Re: DOSBox ECE (for Windows & Linux)

Postby gdjacobs » 2019-12-12 @ 22:00

7F20 wrote:
gdjacobs wrote:The patch I'm referring to adds information to build a debian package from source.


Thanks so much for the more detailed explanation. I will give this a shot tonight.


I wonder if this will solve my issue in which dosbox ECE complains of no resolution of 640x480 available? (because I'm running this on a 320x240 display)

That's doubtful. 320x240 is pretty low res for Xorg.
User avatar
gdjacobs
l33t++
 
Posts: 6776
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: DOSBox ECE (for Windows & Linux)

Postby 7F20 » 2019-12-12 @ 22:06

gdjacobs wrote:That's doubtful. 320x240 is pretty low res for Xorg.


I'm launching from the command line. No X desktop on my pi. I've never tried to run any dosbox from within X.

EDIT: It has been suggested to me that the 640x480 resolution minimum could be a function of a "custom splashscreen" in ECE dosbox. Is this something I can disable?
User avatar
7F20
Newbie
 
Posts: 23
Joined: 2015-4-10 @ 04:06

Re: DOSBox ECE (for Windows & Linux)

Postby gdjacobs » 2019-12-13 @ 00:08

Does kernel modesetting give you terminal output at that res?
User avatar
gdjacobs
l33t++
 
Posts: 6776
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: DOSBox ECE (for Windows & Linux)

Postby 7F20 » 2019-12-13 @ 00:57

gdjacobs wrote:Does kernel modesetting give you terminal output at that res?


absolutely. (I'm assuming you mean just a dpi=modeline in the config.txt)

https://i.imgur.com/4K34M8n.jpg
User avatar
7F20
Newbie
 
Posts: 23
Joined: 2015-4-10 @ 04:06

Previous

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 2 guests