Banjo wrote:

Although I was intending to use "vanilla" DOSBox, I am happy to switch to ECE or X or another build if that allows either of the things I want and "vanilla" doesn't, as long as it's up-to-date.

The splash screen can't be deactivated by the user to prevent unscrupulous people making money with it by selling it and software running on it "disguised" as "new" native windows applications. So, to prevent giving such scumbags an alternative to vanilla DOSBox, ECE won't stop displaying the spalsh screen neither.

Firstly... I discovered DOSBox-ECE earlier this year and absolutely love it! While there are thing I do still need other builds for, ECE has become my "go to" for most DOSBox uses now... so a big thanks for your hard work there, Yesterplay80! 😀

Obviously, someone rebranding DOSBox and then trying to sell it is just reprehensible behavior (but also illegal, I would have thought?). On the other hand, if this can be accomplished by editing the source code then recompiling (out of my league right now, but certainly not out of the league of some scumbags!) what is to stop them achieving their ripoff aims that way? I just mean, if the source is available in full and these people are immoral enough to want to do this...

In any case, I'd repeat my second question: is there a way to make the splash screen appear fullscreen rather than windowed, like the game itself can be made to? As I said, I have zero problems seeing a splash screen before a game loads (when I don't want that for the sake of total retro nostalgia immersion, there's PCem!), but it's the switch to windowed->splash->fullscreen->game that I find ugly and jarring, and tends to crash fullscreen frontends for me.

If this second option is impossible (I'm actually assuming there's a simple technical reason for this behavior I'm unaware of)... I'm curious what people with arcade cabinet style setups that include DOSBox do to get around the issue?

In the past there were companies hiding dosbox usage, when contacting them, they would claim it was by accident and not intentional.
By recompiling, people can remove the splashscreen, which is true, however in that case, they can't claim it was accidental nor unintentional.

The fullscreen thing is a solvable problem. Just something that fell outside consideration when I added the splashscreen. (as I use dosbox in windowed mode primarily)
However, it is not that simple to solve, as in an ideal case, we should show the splash screen already in the wanted resolution afterwards (so 640x400 or 640x480 or 720x400 or 720x480 or maybe even more resolutions, depending on the machine and aspect settings. To do it even better, I'd have to take in account the various scaling methods and restrictions of the output. This is in order to reduce the need to switch fullscreen resolutions after the splashscreen has been showing as such a switch is very slow.
If that is not done correctly, you'd be a lot more annoyed compared to the windowed splash screen, as then the splashscreen could cause a 3 seconds longer delay(startup time), as that is how slow fullscreen resolution switching can be. (windows 10 🙁 ) (which is why I added the whole try to reuse the current sdl surface code)

Qbix wrote:

In the past there were companies hiding dosbox usage, when contacting them, they would claim it was by accident and not intentio […]
Show full quote

In the past there were companies hiding dosbox usage, when contacting them, they would claim it was by accident and not intentional.
By recompiling, people can remove the splashscreen, which is true, however in that case, they can't claim it was accidental nor unintentional.

The fullscreen thing is a solvable problem. Just something that fell outside consideration when I added the splashscreen. (as I use dosbox in windowed mode primarily)
However, it is not that simple to solve, as in an ideal case, we should show the splash screen already in the wanted resolution afterwards (so 640x400 or 640x480 or 720x400 or 720x480 or maybe even more resolutions, depending on the machine and aspect settings. To do it even better, I'd have to take in account the various scaling methods and restrictions of the output. This is in order to reduce the need to switch fullscreen resolutions after the splashscreen has been showing as such a switch is very slow.
If that is not done correctly, you'd be a lot more annoyed compared to the windowed splash screen, as then the splashscreen could cause a 3 seconds longer delay(startup time), as that is how slow fullscreen resolution switching can be. (windows 10 🙁 ) (which is why I added the whole try to reuse the current sdl surface code)

Thanks so much for your detailed reply. That makes a lot more sense about recompiling to remove the splash screen vs a simple flag/switch to do so.

I almost always use DOSBox in windowed mode too, so that's probably why I've never considered this a "problem" until now, when I was using it in a frontend that is always fullscreen.

I'm glad it's at least solvable in theory and how you outline it is how I "expected" it to work, but totally understand how it's not quite that simple; a loading delay would impact far more users than solving the issue I had would help. I'm on Windows 7 x64 but I can imagine a delay of even a few seconds would quickly become annoying over time and loading lots of games (to be honest, these days I play more games in DOSBox on my PC than I do games that don't need it!).

Am I understanding right that as of now, however, recompiling is my only option?

Banjo wrote:

Am I understanding right that as of now, however, recompiling is my only option?

For 0.74-3: yes or hex editing