Any reason to prefer SDL1 with current code?

[emendelson]

A few years ago, SDL1 builds provided some features that weren't in SDL2 builds, for example, the ability to patch the code to create custom items on the Windows system menu. As far as I can tell, all these features are now available in both SDL1 and SDL2, and SDL2 seems to provide more reliable keyboard support.

Question: For a system that will be used mostly in North America and Europe, is there any reason to use an SDL1 build instead of an SDL2 build? I'll be grateful for any advice.

[rderooy]

There are still some differences.

• International keyboard support is better on SDL2
• SDL vs system drawn menus on Windows
• GLIDE pass-through on Linux or macOS requires a SDL1 build (OpenGlide issue)

There are probably some others

[emendelson]

@rderooy - Thank you for that. International keyboard support is more important for my project than GLIDE pass-through. Do you have an opinion on whether an SDL-drawn or system-drawn menu is better? I can't see any reason to prefer one to the other, but maybe I'm missing something.

[Wengier]

@emendelson SDL-drawn and system-drawn menus have quite different styles (not interchangeable in them). It is not that one menu type is better than the other, but some people may be more used to a particular menu type. Also, there may be specific issue(s) in a certain SDL build, such as the Windows color issue with specific video driver(s) in SDL2 builds which has not yet been fixed, and the Glide passthrough support mentioned above. Other than these I think SDL2 builds may be preferred for the said system.

[rderooy]

I guess some windows users may prefer the system drawn menus as it looks like other menus on the system.

Another difference, but not really important right now, is that for Linux Wayland the SDL2 build is the way forward. This week the SDL project finally resolved one long standing Wayland inhibitor in SDL2 (CSD or Client-Side-Decorations support), so once the next SDL2 version is released and makes it way out to distributions we may be able to start testing DOSBox-X with Wayland.

[grapeli]

• GLIDE pass-through on Linux or macOS requires a SDL1 build (OpenGlide issue)

Test, check and evaluate.

https://user-images.githubusercontent.com/452325/127620246-bc2d1bb1-3075-48cb-835c-e4eaad447ebb.mp4

Another difference, but not really important right now, is that for Linux Wayland the SDL2 build is the way forward. This week the SDL project finally resolved one long standing Wayland inhibitor in SDL2 (CSD or Client-Side-Decorations support), so once the next SDL2 version is released and makes it way out to distributions we may be able to start testing DOSBox-X with Wayland.

I've been checking dosbox-x under wayland for a long time. Has had and has decorations for KDE and Sway without libdecor. Now only Gnome users will see them as well.

[emendelson]

Thank you for this. It makes clear that for my projects (which are macOS and Windows-only, and require international keyboard support), SDL2 makes more sense than SDL1. Thank you again!

[rderooy]

@grapeli what did you do to get Glide pass-through working? Which OpenGlide tree/patch did you use to fix the breakage?

[joncampbell123]

The problem is that some features and support in DOSBox-X is only possible with the SDL1 build because I have the freedom to modify the in-tree version as I need to.

Menus in Mac OS X and Windows, and support for the "touch bar" on Macbooks, for example.

That's why some features exist in SDL1 and others in SDL2. Each one has it's benefits and drawbacks.

[grapeli]

@rderooy I was using the git version. Without any modification. The number of games in the 3DFx version under Dos is very modest. Those with a non-statically linked glide library are even smaller. Unfortunately, not all of them work fully properly under DOSBox-X SDL2 with Openglide (Linux). The most common symptom is the lack of menu items, static graphics (Archimedean Dynasty, Carmageddon).

In the margin. For Windows programs and games I use Wine first. Wine is doing very well with Carmageddon, HoMM3, Might & Magic VII: For Blood and Honor, etc., etc., etc... (titles that were reported here and which I tested).

[rderooy]

Strange, so was I. The version from here https://github.com/voyageur/openglide And it segfaults when I tried to start Screamer Rally or GTA as mentioned here https://github.com/joncampbell123/dosbox-x/issues/2126

This issue is also preventing me from trying to get it working with the flathub and RPM builds of DOSBox-X, since they are SDL2 based.

[grapeli]

@rderooy Screamer Rally works for me rather flawlessly with Openglide in DOSBox-X SDL2. Maybe not max fps, but playable . On the very slow Westmere i5-450M (from 2010). The GPU is Intel HD Fifth generation (Gen5) with OpenGL 2.1.

https://user-images.githubusercontent.com/452325/127737348-c52d9147-a8bf-4d41-90e0-bd852e926f79.mp4

dosbox-x.log

[brunocastello]

Is this video with sdl2 build and openglide built with sdl12 compat?

Previously, I was using SDL1 build and voyageur/almeath's openglide implementation for macOS X, and I switched to kjliew's openglide implementation because of QEMU.

[grapeli]

@brunocastello Openglide was built based on the sdl12-compat library. In this case, running with the SDL-1.2 library.

It also works with sdl12-compat. I checked under Wayland. It has a drawback. There are then two separate windows, one dosbox-x and one openglide. This complicates the situation, in order for the keyboard (mouse) to work, the focus must be on this background window.

[grapeli]

@rderooy @Wengier Screamer Rally works much faster for me with voodoo_card=opengl than glide under dosbox-x (SDL2). When redundant logging is disabled, it increases by an additional 10fps.

I commented on these two lines in the voodoo_emu.cpp file. https://github.com/joncampbell123/dosbox-x/blob/master/src/hardware/voodoo_emu.cpp#L1950 https://github.com/joncampbell123/dosbox-x/blob/master/src/hardware/voodoo_emu.cpp#L2561

It is clearly visible that it was the functions of the C standard library (glibc) that loaded the most. Perf before

7.52%  libc-2.33.so              [.] __vfprintf_internal
6.52%  libc-2.33.so              [.] _IO_default_xsputn
2.58%  dosbox-x                  [.] std::_Rb_tree_increment
2.04%  libc-2.33.so              [.] __strchrnul_sse2
2.02%  dosbox-x                  [.] CPU_Core_Dyn_X86_Run
1.87%  dosbox-x                  [.] mem_writed_checked_dcx64
1.63%  dosbox-x                  [.] Voodoo_PageHandler::writew
1.61%  dosbox-x                  [.] CodePageHandler::writed_checked
1.48%  libc-2.33.so              [.] _itoa_word
1.37%  dosbox-x                  [.] register_w

and after the change.

2.86%  dosbox-x                    [.] std::_Rb_tree_increment
2.80%  dosbox-x                    [.] mem_writed_checked_dcx64
2.79%  dosbox-x                    [.] CPU_Core_Dyn_X86_Run
2.33%  dosbox-x                    [.] CodePageHandler::writed_checked
2.19%  dosbox-x                    [.] Voodoo_PageHandler::writew
2.12%  dosbox-x                    [.] register_w

This is what the FPS chart looks like. GALLIUM_HUD=fps ./dosbox-x Before after. Fps practically does not drop below 40. The average is much higher.

[brunocastello]

@Wengier I thought that there is a command to disable logging completely?