Returning to TTF mode from VESA mode sets default, instead of user-specified, colors

[RobertJSawyer]

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

Have you checked that no other similar bug report(s) already exists?

• I have searched and didn't find any similar issues.

What operating system(s) this bug have occurred on?

Windows 7 32-bit SP1

What version(s) of DOSBox-X have this bug?

0.83.23 SLD1 32-bit

Describe the bug

When I toggle from TTF mode to VESA graphics and then return to TTF mode, instead of conforming to the "colors" directive in the TTF section of DOSBOX-X.CONF, the default VGA standard colors are used.

For testing purposes, here's a colors directives that sets a soft green background color for everything that had a black background and makes some other obvious substations as well.

colors = #c0dcc0 #0e0e0e #0000FF #000000 #000000 #00FF00 #000000 #FF0000 #000000 #0e0e0e #000000 #000000 #000000 #000000 #000000 #000000

My use case: in WordStar 7.0 for DOS, going from text mode into WordStar's Advanced Page Preview, and then returning to text mode. I can reset my choice of colors by running a batch file with appropriate SETCOLOR commands, but it would be nice if DOSBox-X returned to TTF mode with the colors the user had in fact specified for that mode.

Expected behavior

User color choice obeyed whenever (re)entering TTF mode.

Steps to reproduce the behaviour

Put this color directive into DOSBox-X.conf under the TTF section:

colors = #c0dcc0 #0e0e0e #0000FF #000000 #000000 #00FF00 #000000 #FF0000 #000000 #0e0e0e #000000 #000000 #000000 #000000 #000000 #000000

Toggle from text mode to graphics mode then back again. DOSBox-X ignores the DOSBOX-X.conf value and instead uses the default VGA color palette.

Used configuration

No response

Emulator log

No response

Additional context

No response

[Wengier]

With the latest version (as fixed by PR #3351), if you append a leading "+" to the COLORS option, e.g. colors = +#c0dcc0 ..., then the color scheme should stay for your case. Hope this helps.

[grapeli]

@Wengier
This is not exactly the same error as reported, but it is worth noting that ttf colors cannot be changed on the command line. The command is too long.

When invoked from the command line at dosbox-x startup, it works fine.
dosbox-x -set output=ttf -set "ttf colors=#c0dcc0 #0e0e0e #0000FF #000000 #000000 #00FF00 #000000 #FF0000 #000000 #0e0e0e #000000 #000000 #000000 #000000 #000000 #000000"

[Wengier]

@grapeli Indeed you cannot really change the COLORS option from the command-line (since as you said it is too long), but in DOSBox-X there is a SETCOLOR command exactly for the purpose of changing color schemes from the command-line, e.g.

SETCOLOR 0 #c0dcc0
SETCOLOR 1 #0e0e0e
...

The effect is the same as COLORS option, just with a different syntax. You can type SETCOLOR /? for more help information for this command.

[RobertJSawyer]

Wonderful, @Wengier! Thank you! Please forgive my ignorance but how do I download the revised (32-bit Windows) version?

Thanks again!

[grapeli]

@Wengier
Thanks for the clarification.

[Wengier]

@RobertJSawyer You can download 32-bit Windows builds from:

https://github.com/Wengier/dosbox-x/suites/5775324969/artifacts/192358311

Hope this helps.

[RobertJSawyer]

Thank you, @Wengier!

The "+" in front of the color codes does indeed fix my problem. I'm very grateful.

But perhaps I screwed up replacing the files properly, but the new version starts up running glacially slowly on my 32-bit Windows 7 Dell laptop, which is the only computer I have with me to test this on (I'm away from home for a few days). I have to press F11+Left every session to get it back to normal speed.

I'm using the same .conf file I've always used (except for trying out the new "+" parameter, although its presence or absence makes no difference to this initial-speed issue). The loading of DOSBox-X becomes super-slow starting with the "Welcome to DOSBox-X" blue-colored screen; I can see it paint in from top to bottom, and everything moves at a snail's pace after that until I press F11+Left.

Sawyer DOSBox-X CONF.zip

[Wengier]

@RobertJSawyer I tried the config file you posted, and compared the loading speed between DOSBox-X 0.83.16/0.83.20 and the latest build, but have not found a difference between the loading speed yet. So I am surprised to hear the slowdown as you said. Maybe you can try a different config file (including the default one) and see how it performs?

[RobertJSawyer]

The default .conf file seems to work fine with one exception.

I'm working on tracking down whatever difference there is in my .conf file that causes the problem.

Many thanks for all your help, @Wengier! I am very grateful to you!

[RobertJSawyer]

Hi, @Wengier. :)

Working with an otherwise unmodified version of the dosbox-x.conf file that was included with the new test release, adding a bunch of mount commands and changing

shell =

to

shell = 4DOS.COM

is enough to trigger an enormous slowdown in the mounting of drive letters. The difference is obvious at a glance.

The attached .conf file has only the shell change and the mount commands I use, all of which are existing paths on my system, and all mount successfully, but much more slowly under this new DOSBox-X release.

Under previous releases of DOSBox-X, there's no difference in the speed of executing the MOUNT commands regardless of the SHELL = setting.

Sawyer-test-conf-file-2.zip

[Wengier]

@RobertJSawyer I cannot really test the build with your config file(s) as is, because none of the paths for mounts as listed in your config files (like C:\SYNC\F\ and C:\Sync\N\-Res\) exist on my system. So I tried to point to some existing paths in my system, but I have not noticed the said enormous slow down yet (in comparison with a release like 0.83.16 or 0.83.20). Have you tried official releases like 0.83.23 or an earlier one? Perhaps you can post videos showing comparisons between the builds, so that one may visualize the problem you mentioned. Thanks.

[RobertJSawyer]

Hi, @Wengier. I'm traveling until April 12, and only have a 32-bit Windows 7 Pro laptop with me. I'll be able to do more extensive testing once I'm back home, but here are videos demonstrating the difference between "Shell = [blank]" and "Shell = 4DOS" with the build you supplied me with yesterday. No previous build ever showed this disparity.

Without 4DOS

With 4DOS

All best wishes!

[Wengier]

@RobertJSawyer I tried the config on my system, and I noticed they all have a somewhat slowdown when mounting drives with shell=4DOS.COM, no matter which previous release I tried. So I still wonder how there can be a speed difference among different releases on your system.