realnc wrote:

The DOSBox-SVN core in RetroArch does this.

Whoah, i need to check it.

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 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/813433cf … ideo/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.

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

Kisai wrote:

The problem is that nothing in Dosbox is multithreaded (except for mt32/fluidsynth if compiled to do so), and the 3D software em […]
Show full quote

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/813433cf … ideo/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.

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.

1Commander Keen 1 = No Tearing
2Commander Keen 4 = No Tearing
3Jazz Jackrabbit = No Tearing
4Prince of Persia = Low Tearing (fairly rare)
5Realms of the Haunting = No Tearing
6Terminal Velocity = Minimal Tearing (very rare)
7Descent = Minimal Tearing (very rare)
8Doom II = No Tearing
9Red Baron = No Tearing
10Rise of the Triad = No Tearing
11Duke Nukem 3D (vesa_noflb) & 640x480 = Moderate Tearing (often)
12Duke Nukem 3D (svga_s3) & 640x480 = Minimal Tearing (very rare)
13Duke 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.

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?

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.

The patch I'm referring to adds information to build a debian package from source.
https://wiki.debian.org/BuildingTutorial#Get_ … _source_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/d/dosb … 1.debian.tar.xz

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)

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

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.

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?

Does kernel modesetting give you terminal output at that res?

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

XxMiltenXx wrote on 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. […]
Show full quote

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?

The problem is that you're trying to use ECE which uses SDL 1.2.
The Pixel-perfect scaling in SDL 1.2 builds exponentially makes dosbox slower, and should never be used. Even if you have the CPU power to spare, the SDL1.2 render path makes it too slow to be useful. That's why you see tearing.

There's only three "good" options:
If you want to record, but not stream, use the dosbox internal recording without frameskip. Then load this video into your video editor and do what you will with it.
If you want to stream, but not record, then you are completely at the mercy of how you play the game. This means either running the game at 320x200/320x240/640x480 in a tiny window or blowing it up to full screen using the nVidia "GPU Scaling" option. If you make dosbox do the scaling past 2X, it will be stupidly slow.
If you want to stream using OBS, you need a SDL2 build, and that means losing some of the other features that don't work by design (like glide support)

Recording Voodoo2/Glide support is a crapshoot and unfortunately the way you get it to work is complicated since it creates another render context if it uses the GPU.

If you get a SDL 2.0 build, the default option is always a hardware surface, which OBS can deal with and most GPU's will scale the 320x200/320x240/640x480 resolution of games to full screen not unreasonably. ECE, which uses SDL1.2 basically caps out at 1280x900. The Pixel-perfect patch and things like normal3/4/5/6 scaling rely only on the CPU, so unless you have a 5Ghz CPU, those options will likely be unusable if enabled.

XxMiltenXx wrote on 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.

Does this fork help?

2. openglpp & glfullvsync

glfullvsync works in true fullscreen mode only, but does not work in a borderless window. Did you have fullborderless off when testing with glfullvsync?

Kisai wrote on 2020-01-06, 16:29:

The problem is that you're trying to use ECE which uses SDL 1.2.
The Pixel-perfect scaling in SDL 1.2 builds exponentially makes dosbox slower,

What exponential dependency are you talking about? There can be no slowdown whatsoever with openglpp (at least, without glfullvsync) because it uses hardware scaling.

and should never be used.

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

Even if you have the CPU power to spare, the SDL1.2 render path makes it too slow to be useful. That's why you see tearing.

What makes you think so? If you see tearing with

1output = surfacepp
2fullborderless = false
3fulldouble = true
4fullscreen = true

then it is certainly not because of DOSBox.

If you want to record, but not stream, use the dosbox internal recording without frameskip. Then load this video into your video editor and do what you will with it.

Good option!

If you get a SDL 2.0 build, the default option is always a hardware surface, which OBS can deal with and most GPU's will scale the 320x200/320x240/640x480 resolution of games to full screen not unreasonably.

But, to the best of my knowledge, none of them can do pixel-perfect scaling and always introduce interpolation artefacts. I wish the maintaners of those builds would consider supporting pixlel-perfect scaling, which is really easy with SDL 2.0, which has SDL_RenderSetScale() and SDL_RenderSetIntegerScale(). Let them consult me as an expert.

ECE, which uses SDL1.2 basically caps out at 1280x900. The Pixel-perfect patch and things like normal3/4/5/6 scaling rely only on the CPU, so unless you have a 5Ghz CPU, those options will likely be unusable if enabled.

Not true—openglpp is hardware-based pixel-perfect scaling. Check your CPU load while testing.