VOGONS

Common searches


dosbox-staging (DOSBox Git repo)

Topic actions

  • This topic is locked. You cannot reply or edit posts.

Reply 180 of 236, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Hi.
So it's DOSBox on Github with all the excellent patches across the years, not including kitchen sink.
This is Fantastic!!!!

Is there a way to get the prebuilt snapshots for Windows?
I have a 404 on the github snapshot link.
edit: never mind, I had to log in.


my important / useful posts are here

Reply 181 of 236, by dreamer_

User metadata
Rank Member
Rank
Member
James-F wrote on 2020-01-29, 13:21:

Hi.
So it's DOSBox on Github with all the excellent patches across the years, not including kitchen sink.
This is Fantastic!!!!

Yeah, that's quite accurate description, thanks 😀

We don't include all the patches, but we're slowly cleaning up and importing more. Just today I merged-in pull request with CGA/mono patch, we have multiple improvements lined-up in review, and more patches from ECE being worked on.

James-F wrote on 2020-01-29, 13:21:

Is there a way to get the prebuilt snapshots for Windows?
I have a 404 on the github snapshot link.
edit: never mind, I had to log in.

Ouch, the latest snapshot downloads require users to log-in? That's unfortunate - GitHub Actions feature is in Beta still, so issues like this might pop sometimes.

I attached today's snapshot for users to test (the latest fix from SVN trunk r4312 is already merged-in).

Attachments

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 182 of 236, by citrixscu

User metadata
Rank Newbie
Rank
Newbie
James-F wrote on 2020-01-29, 13:21:

Hi.
So it's DOSBox on Github with all the excellent patches across the years, not including kitchen sink.
This is Fantastic!!!!

It's a clean build without tons of extra stuff, yes. I miss Ant's pixel perfect scaling patch but do not know enough about the changes in pixel scaling from SDL to SDL2 to do any meaningful comparisons.

Reply 183 of 236, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Using high scale factor like x6 with interpolated (bilinear filtering) like opengl.
This is effectively replaces the "surfacenp" (super sampling) in Ant_222 pixel perfect patch.

It maintains nice and even pixels while not being very blurry.
Nearest Neighbor no blur (NB) options can't reproduce that look.


my important / useful posts are here

Reply 184 of 236, by dreamer_

User metadata
Rank Member
Rank
Member
citrixscu wrote on 2020-01-29, 13:51:

I miss Ant's pixel perfect scaling patch but do not know enough about the changes in pixel scaling from SDL to SDL2 to do any meaningful comparisons.

Ant is learning Git and cooperating with us to include his patch in dosbox-staging; very, very early version of pixel-perfect scaling is on branch as/pp.

James-F wrote on 2020-01-29, 14:08:

This is effectively replaces the "surfacenp" (super sampling) in Ant_222 pixel perfect patch.
(…)
Nearest Neighbor no blur (NB) options can't reproduce that look.

Thank you for creating a feature request about this; discussion continues in #152.

Personally, I think we need both pixel-perfect output and improved scalers - only when both will be in, on top of SDL2, we'll be able to do meaningful comparisons and decide how to go forward.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 185 of 236, by citrixscu

User metadata
Rank Newbie
Rank
Newbie
dreamer_ wrote on 2020-01-29, 15:00:
Ant is learning Git and cooperating with us to include his patch in dosbox-staging; very, very early version of pixel-perfect sc […]
Show full quote
citrixscu wrote on 2020-01-29, 13:51:

I miss Ant's pixel perfect scaling patch but do not know enough about the changes in pixel scaling from SDL to SDL2 to do any meaningful comparisons.

Ant is learning Git and cooperating with us to include his patch in dosbox-staging; very, very early version of pixel-perfect scaling is on branch as/pp.

James-F wrote on 2020-01-29, 14:08:

This is effectively replaces the "surfacenp" (super sampling) in Ant_222 pixel perfect patch.
(…)
Nearest Neighbor no blur (NB) options can't reproduce that look.

Thank you for creating a feature request about this; discussion continues in #152.

Personally, I think we need both pixel-perfect output and improved scalers - only when both will be in, on top of SDL2, we'll be able to do meaningful comparisons and decide how to go forward.

This is all great. I can see Ant's commits in the as/pp branch, so I'll keep my eye on it. Thanks again for taking on this project.

Reply 186 of 236, by Kisai

User metadata
Rank Member
Rank
Member
dreamer_ wrote on 2020-01-01, 13:38:
awgamer wrote on 2020-01-01, 12:25:

Is the incorporated mt32 emulation in the same process or threaded? Running munt would still be the way to go with it being a separate process if the former.

It's only on ECE branch ATM (not on master) - I haven't looked into details of threading yet. Implementing mt32 on master branch will require more work - munt is not packaged by any repository (not for Linux, not in brew for macOS, not in vcpkg for Windows), so we'll need to implement some buildsystem changes first to make it easy to (conditionally) compile.

I agree, that running mt32 emulation on the same thread as the main emulation would be unacceptable (same goes for fluidsynth patch BTW).

Just to jump back in time here. I consider the MT32 and Fluidsynth patches to be important, but the way I build them is basically windows-specific. MT32 uses the threads in SDL1 or SDL2 (and that's the only difference between building them that way.) Fluidsynth I excised glib so that it would build on Windows without needing it. So it does use the threading functions in glib (or native threads without it.) Please see the respective patches to source code elsewhere on the forum. My build process is designed so that they can be compiled into dosbox staticly, because they're intended to be kept with the game that needs them, but there's nothing preventing them from being compiled as loadable libraries other than being a mess since 32-bit dll's and 64-bit dlls have the same name and you have to rebuild all of these support libraries as 64-bit and do a lot of invasive nonsense to give them different names. Hence built static serves my purpose.

MT32 and Fluidsynth are not particularly invasive into the DOSBOX code, the versions I have basically do this:

midi.cpp

#if C_MUNT
#include "midi_mt32.h"
static MidiHandler_mt32 &Midi_mt32 = MidiHandler_mt32::GetInstance();
#endif

#if C_FLUIDSYNTH
#include "midi_fluidsynth.h"
static MidiHandler_fluidsynth Midi_fluidsynth;
#endif

DB_Midi midi;

Don't ask why it's here. It probably could be inside the respective include files but some linking nonsense kept having me just stick it here, but to keep the changes from the main dosbox code as much as possible. The MUNT patch works with the stock code from git compiled as a library.

There are minor bug-fixes/feature-checks in the midi_mt32.cpp from the version you'd find on the MUNT git.

	service->setDACInputMode((MT32Emu::DACInputMode)section->Get_int("mt32.dac"));

service->setReversedStereoEnabled(section->Get_bool("mt32.reverse.stereo"));
#if MT32EMU_VERSION_MAJOR >= 2 && MT32EMU_VERSION_MINOR >1
service->setNiceAmpRampEnabled(section->Get_bool("mt32.niceampramp"));
#endif
//Feature only available in 2.3.0 SVN as of 2019-03-24
#if MT32EMU_VERSION_MAJOR >= 2 && MT32EMU_VERSION_MINOR >3

service->setNicePanningEnabled(section->Get_bool("mt32.nicepanning"));
service->setNicePartialMixingEnabled(section->Get_bool("mt32.nicepartials"));
#endif

And the SDL switch:

#if SDL_VERSION_ATLEAST(2,0,0)
thread = SDL_CreateThread(processingThread,"MT32 Thread", NULL);
#else
thread = SDL_CreateThread(processingThread, NULL);
#endif

I've been able to do some silly things with the mt32 patch which brings it past the quality of a real MT32, but it's also incredably easy to screw up.

Mainly:

	/*begin gain and reverb tuning*/
service->setOutputGain(0.01f * section->Get_int("mt32.output.gain"));
service->setReverbOutputGain(0.01f * section->Get_int("mt32.reverb.output.gain"));
/*end reverb tuning*/

If this is set to 0, things go off the rails. Likewise, I believe the original patch had more string-to-int stuff, when these are floats.

The Fluidsynth patch itself on the other hand, has a lot more tunables and more errors I fixed in string-to-int that I believe I fixed, but I also added stuff that I felt was edge case (like stacking two SoundFonts which Fluidsynth supports.) According to my records I last made changes to MT32 stuff on 10/20/2019 and FluidSynth on 9/22/2019

I'll probably have to rebase to see if these patches all still work as the work I put into the avi file fixes has been superceded in svn so my source tree is probably messed up. If the git staging starts with SDL2, then the only patches I would normally add are in fact the mt32 and fluidsynth since those come after SDL2 in my patches.

MT32options.h and fluidsynthoptions.h are how I keep the patches from stomping on too much of dosbox.cpp

	const char* mputypes[] = { "intelligent", "uart", "none",0};
// FIXME: add some way to offer the actually available choices.
const char *devices[] = { "default", "win32", "alsa", "oss", "coreaudio", "coremidi", "mt32", "fluidsynth", "none", 0};
Pstring = secprop->Add_string("mpu401",Property::Changeable::WhenIdle,"intelligent");
Pstring->Set_values(mputypes);
Pstring->Set_help("Type of MPU-401 to emulate.");

Pstring = secprop->Add_string("mididevice",Property::Changeable::WhenIdle,"default");
Pstring->Set_values(devices);
Pstring->Set_help("Device that will receive the MIDI data from MPU-401.");

Pstring = secprop->Add_string("midiconfig",Property::Changeable::WhenIdle,"");
Pstring->Set_help("Special configuration options for the device driver. This is usually the id or part of the name of the device you want to use (find the id/name with mixer/listmidi).\n"
"Or in the case of coreaudio, you can specify a soundfont here.\n"
"When using a Roland MT-32 rev. 0 as midi output device, some games may require a delay in order to prevent 'buffer overflow' issues.\n"
"In that case, add 'delaysysex', for example: midiconfig=2 delaysysex\n"
"See the README/Manual for more details.");

#include "mt32options.h"
#include "fluidsynthoptions.h"

It goes there in mine. In some earlier versions I had the configuration directives C_MUNT and C_FLUIDSYNTH around them.

I don't know if I've ever included these with previous patches on the forums, but I'll have to go check what works and come back to it.

Reply 187 of 236, by dreamer_

User metadata
Rank Member
Rank
Member

@Kisai thanks for summary, but discussing implementation details on Vogons is really inconvenient - it's too easy to derail the discussion or lose someone's comment. The most productive way forward will be to open two new topics in dosbox-staging bugtracker (one for MT32, other for Fluid), or maybe even PRs straight away (but both MT-32 patch and Fluidsynth support require so much additional work, that I think an issue will better than PR for now).

Before reading my essay below 😉 : both patches were included in ECE, so if you only want the ability to easily cherry-pick them - they're already there. If you want me to include modifications to these patches on a separate branches (not merged to master), then no problem - just point me to exact patches or to branch in your fork on GitHub. My comments below apply to merging MT-32 into the master branch of dosbox-staging.

Kisai wrote on 2020-02-08, 08:36:

Just to jump back in time here. I consider the MT32 and Fluidsynth patches to be important, but the way I build them is basically windows-specific. (...)

I also consider them important; MT32 more than Fluidsynth (based on brief time I looked at Fluidsynth patch, I think this approach is flawed). However, no Windows-specific solutions will land in dosbox-staging - whatever we'll include needs to run on Linux, Windows, and modern macOS. For most features it's rather easy, but MT32, Fluidsynth and Glide support will need to resolve lots of problems to get there.

Before a feature is merged to master (thus at some point will land in patch series resubmitted for upstream) we need to make sure it not only works and is technically on point, but also code is clean and largely follows the coding style, does not introduce any warnings nor obvious regressions, does not require building other projects manually or patching other projects just for dosbox, builds can be reproduced on CI, the feature is documented for users in README file, man page, or .conf documentation, there are no licensing issues, etc, etc.

Issues like this *will* be raised and considered during the review in PR.

Right now, the problem with MT32 patch is the Munt project itself - it is not packaged as a library by any Linux distribution, vcpkg, MSYS*, nor brew repos. This basically means we'll need to include relevant parts of Munt project with dosbox-staging source code (building it "on the side" is unacceptable) - it's nothing new, we already do it for decoders lib (formerly SDL_sound) and nuked OPL. There are several ways to do it (e.g. dump code, use git submodule, or extract subtree and merge project histories - the proper solution should be considered when it'll be time). Fortunately, Munt authors predicted this usecase and support it (hurray!). Unfortunately, DOSBox uses autoconf, which makes it infeasible - Munt's lib buildsystem and embedding is provided as cmake module only.

So, there are two options: either rewrite DOSBox buildsystem in cmake, or Munt's in autoconf. So far during development of dosbox-staging we wasted so much time working on stupid issues caused by autoconf, that we're completely sick of it - and we're not the only one: DOSBox-X is also tranistioning to cmake (or maybe they already finished, I'm not sure), dosbox retroarch cores also want to use cmake, cmake would make it easier to perform builds on Windows (we could get rid of separate Visual Studio buildsystem, as cmake works in VS), etc, etc.

So MT32 patch needs Munt, Munt needs cmake, using cmake means rewriting buildsystem... and now we arrive at the REAL problem here: if we rewrite the buildsystem, our future patches won't be accepted upstream for sure.

This is annoying because DOSBox maintainers stopped talking to us, do not review our patch series, and it seems like they are not interested in introducing SDL2 to DOSBox at all.

I still have hope that Qbix or other upstream maintainer will reconsider and start reviewing patches I've sent, but it is really small hope at this point.

However, silence from DOSBox maintainers is not a blocker from starting the work I described above - please create new issue on bugtracker so we can start planning to make this work go smoothly. Personally, there are is so much interest in dosbox-staging at the moment, that I have my hands full already - which is a good thing, I guess 😀 All new contributors are welcome.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 188 of 236, by DosFreak

User metadata
Rank l33t++
Rank
l33t++
dreamer_ wrote on 2020-02-08, 10:03:
@Kisai thanks for summary, but discussing implementation details on Vogons is really inconvenient - it's too easy to derail the […]
Show full quote

@Kisai thanks for summary, but discussing implementation details on Vogons is really inconvenient - it's too easy to derail the discussion or lose someone's comment. The most productive way forward will be to open two new topics in dosbox-staging bugtracker (one for MT32, other for Fluid), or maybe even PRs straight away (but both MT-32 patch and Fluidsynth support require so much additional work, that I think an issue will better than PR for now).

Before reading my essay below 😉 : both patches were included in ECE, so if you only want the ability to easily cherry-pick them - they're already there. If you want me to include modifications to these patches on a separate branches (not merged to master), then no problem - just point me to exact patches or to branch in your fork on GitHub. My comments below apply to merging MT-32 into the master branch of dosbox-staging.

Kisai wrote on 2020-02-08, 08:36:

Just to jump back in time here. I consider the MT32 and Fluidsynth patches to be important, but the way I build them is basically windows-specific. (...)

I also consider them important; MT32 more than Fluidsynth (based on brief time I looked at Fluidsynth patch, I think this approach is flawed). However, no Windows-specific solutions will land in dosbox-staging - whatever we'll include needs to run on Linux, Windows, and modern macOS. For most features it's rather easy, but MT32, Fluidsynth and Glide support will need to resolve lots of problems to get there.

Before a feature is merged to master (thus at some point will land in patch series resubmitted for upstream) we need to make sure it not only works and is technically on point, but also code is clean and largely follows the coding style, does not introduce any warnings nor obvious regressions, does not require building other projects manually or patching other projects just for dosbox, builds can be reproduced on CI, the feature is documented for users in README file, man page, or .conf documentation, there are no licensing issues, etc, etc.

Issues like this *will* be raised and considered during the review in PR.

Right now, the problem with MT32 patch is the Munt project itself - it is not packaged as a library by any Linux distribution, vcpkg, MSYS*, nor brew repos. This basically means we'll need to include relevant parts of Munt project with dosbox-staging source code (building it "on the side" is unacceptable) - it's nothing new, we already do it for decoders lib (formerly SDL_sound) and nuked OPL. There are several ways to do it (e.g. dump code, use git submodule, or extract subtree and merge project histories - the proper solution should be considered when it'll be time). Fortunately, Munt authors predicted this usecase and support it (hurray!). Unfortunately, DOSBox uses autoconf, which makes it infeasible - Munt's lib buildsystem and embedding is provided as cmake module only.

So, there are two options: either rewrite DOSBox buildsystem in cmake, or Munt's in autoconf. So far during development of dosbox-staging we wasted so much time working on stupid issues caused by autoconf, that we're completely sick of it - and we're not the only one: DOSBox-X is also tranistioning to cmake (or maybe they already finished, I'm not sure), dosbox retroarch cores also want to use cmake, cmake would make it easier to perform builds on Windows (we could get rid of separate Visual Studio buildsystem, as cmake works in VS), etc, etc.

So MT32 patch needs Munt, Munt needs cmake, using cmake means rewriting buildsystem... and now we arrive at the REAL problem here: if we rewrite the buildsystem, our future patches won't be accepted upstream for sure.

This is annoying because DOSBox maintainers stopped talking to us, do not review our patch series, and it seems like they are not interested in introducing SDL2 to DOSBox at all.

I still have hope that Qbix or other upstream maintainer will reconsider and start reviewing patches I've sent, but it is really small hope at this point.

However, silence from DOSBox maintainers is not a blocker from starting the work I described above - please create new issue on bugtracker so we can start planning to make this work go smoothly. Personally, there are is so much interest in dosbox-staging at the moment, that I have my hands full already - which is a good thing, I guess 😀 All new contributors are welcome.

I will speak plainly and clearly since that is what it seems to be required since it looks like I have to repeat this over and over:

1. PM or email the DOSBox devs. Don't bitch about YOUR issues in a random post in the forum.
2. DOSBox is a hobby. No money is made from it, except in cases where it is. It seems like this is all you are doing and you act like your life depends on it. Good for you I guess.
3. You've made changes in dosbox-staging that don't match with SVN and then complain because the dosbox team does not work on your schedule. It's the other way around.
4. MT32 has been mentioned a million times (I might be exaggeratting there) and why it wasn't integrated. Things may be different nowadays with ScummVM being used commercially without repercussions. I do fail to see the point on integrating something that can't be legally used without the ROM, which most people won't be doing so legally, and which most people won't bother to add the roms and we won't support those people here. Is the MT-32 rom freely distributable? Did anyone every do a clean room version of the ROM?
5. I see no issue with adding FluidSynth as long as it can be disabled on compiling dosbox (For when it inevitably drops support for whichever OS) and it supports at least Windows XP if not <Windows XP as well. IIRC, Fluidsynth still supports XP while FluidSynthLite does not.
6. Autotools vs cmake. DOSBox devs are not keen on doing things just because and no one should. Is there a significant reason to switch to cmake? Can all current DOSBox dependencies compile with CMAKE? When DOSBox switches to SDL2 can all of those dependencies for the SDL2 build be compiled with CMAKE? What are the pros and cons of moving to CMAKE because as with anything there are always cons. It looks like in dosbox-staging you don't bother with compiling the dependencies relying on others. To compile DOSBox anyone should have the option to compile all dependencies.
7. I doubt anyone stopped talking to you. As I stated above this is a hobby so more than likely RL gets in the way and DOSBox isn't worked 24/7 365 days a year (but is actively worked as can be seen in the changelog) on a $100,000 salary. I will say that if it was me with your attitude on this forum I wouldn't take to you either.

I will not engage in a back and forth so this is my last comment on the subject. Talk to the devs. If not then stop with the ignorant bolded comments or go elsewhere.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 189 of 236, by llm

User metadata
Rank Newbie
Rank
Newbie

but it still seems that every extension dreamer and krcroft are talking about are more or less ignored by the main devs - or that is the feeling i get reading the responsens

the main response seems to be:
reject - if it reduces the amount of reachable platforms: Topics: SDL2, C++11, OS/2, Win95
reject - if it does not bring any advantages right from the first use: Topic: C++11
reject - if it is not clear what does it help: git, CMake, ... (most projects out there switched years ago: there is some benefit...)

its clear: its open source, unpayed etc. but even the switch to git was a nearly dead end discussion - nothing will get lost, everything will get better, still no official acceptance

for me the best stragie is still: switch to github/gitlab + the auto builds+analysis tools that dream and krcroft already established (maybe under a offical github account or something)
and let the main devs get used to this infrastructure (without all the C+11, SDL2, Patches, etc.) - slow start - but even this seems to be a no-go, i don't even understand why there is
any discussion needed about using git and CI-systems at all - there is no cost and nearly no invest needed

so what should dreamer, krcroft do? because they want a different source platform/release system and big changes in the sources...

Reply 190 of 236, by dreamer_

User metadata
Rank Member
Rank
Member

Just before anyone else will jump in here and put the flames in discussion. Calm down, people 😀

Just few minutes ago me and krcroft had a friendly chat with Qbix about how to proceed and what kind of changes are acceptable upstream.

From now on, the cooperation between two projects should go a bit smoother - we have a private communication channel to coordinate instead of sending PMs or bugtracker issues past each other. It's a win-win in my opinion:

- Win for DOSBox: we will be sending patches, that we know upfront have a reasonable chance of being accepted - so DOSBox maintainers won't waste time reviewing long queue of patches we initially wanted.
- Win for dosbox-staging: through a better understanding of what patches won't be accepted upstream, dosbox-staging maintainers can now be more accepting towards community contributions.

Basically we can chill out now and when some change is requested in dosbox-staging we can make an informed decision when to say "this change won't make it upstream - but it's ok for dosbox-staging" or "this change can make it upstream, therefore some more attention is needed" or simply "no".

From now on, dosbox-staging is more of a "soft-fork" rather than "patch staging repo".

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 191 of 236, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

Well said dreamer_!

The goal was for staging to be a 100% front runner to help vette, cleanup, and gate new work and patches before coordinating the heavily cleaned-up results with upstream. "staging" in the truest sense - similar to the Linux staging kernel. After this discussion, like dreamer_ said, we have a way forward on a subset of this work, which is huge progress.

Plus there are secondary wins that the modern tooling (mechanized builds, analysis, and soon-to-be actual game regression-tests, on every commit) will benefit upstream, without any commitment or transition needed on their part.

We might have differing opinions as to the magnitude of value of those tools, or which servers or companies host the work (we all draw our lines in the sand differently), but we have common ground, and it's in the overlap where progress will be made. After all.. in 10 years the tooling and best-practices landscape will have massively changed again, but DOSBox, and progress achieved between now and then, will remain.

Thank you Qbix for hosting this.

Reply 192 of 236, by llm

User metadata
Rank Newbie
Rank
Newbie

Just before anyone else will jump in here and put the flames in discussion. Calm down, people

we all very calm here 😀

Just few minutes ago me and krcroft had a friendly chat with Qbix about how to proceed and what kind of changes are acceptable upstream.

great - are you able to give a brief overview what points are getting accepted(or getting discussed later) in short or long term - some sort of (fully) Roadmap of the svn staging intersections
and what the opitions of the main devs are, i would love to see a officialy approved github/dosbox project with status overview - no more dying forks, just branches with different officials acceptance

Topics like: C++11, Win95/98, git, SDL2, MT32,CMake, not support audio playback using physical CDs, Codecs integration, ECE Stuff, more and more comming extra features...

so its clear for everyone what the official/accepted/discuessed opinions for svn/staging are

Last edited by llm on 2020-02-10, 08:12. Edited 1 time in total.

Reply 194 of 236, by Kisai

User metadata
Rank Member
Rank
Member
dreamer_ wrote on 2020-02-08, 10:03:

@Kisai thanks for summary, but discussing implementation details on Vogons is really inconvenient - it's too easy to derail the discussion or lose someone's comment. The most productive way forward will be to open two new topics in dosbox-staging bugtracker (one for MT32, other for Fluid), or maybe even PRs straight away (but both MT-32 patch and Fluidsynth support require so much additional work, that I think an issue will better than PR for now).

I brought it up because those are the two patches that I regularly made efforts to keep working on current versions of dosbox. So the question raised was "are these threaded" and the answer is yes. The way I would like them to be patched in is so that recording the game video records the audio (both mt32 and fluidsynth) , because some people prefer external GM devices or using MUNT/Fluidsynth as a separate process (eg via existing GM midi output) , and you only need one driver to record and push the audio through dosbox, where as multiple drivers are needed/necessary if you want to push the audio/midi through some other thing. The version of FluidSynth I'm using only supports Dosbox or SDL2 (when compiled as SDL2), and none of the other fluidsynth drivers, because I didn't want to import a dozen different libraries I'm not using. When run as SDL2 output, it's in it's own audio context, so dosbox doesn't record it, but I had left it in to make sure the music doesn't change between SDL2 output and dosbox.

One improvement I would like to do at some point, mostly for recording purposes is to split the music channels from the DAC channels in the output file, however this runs into a limitation of the AVI format, which is a crapshoot if it any video editor will know what to do with channel 3-6.

FluidSynth, for whatever reason, removed the autotools configuration in 2.0, along with lots of other stuff, which again is one reason why the 1.1.6+backported stuff I use with it. Though I don't use autotools when I configure things, I've rarely had any Cmake stuff work with visual studio, and that's partly because cmake keeps making projects that dump 32-bit and 64-bit binaries into the same place with the same filenames. So cmake never finds anything. If Dosbox works fine with 2.1.0 fine and cmake, that's fine. It's still a pain to get it to build due to all the other drivers.

MUNT on the other hand I've never had an issue with. As far as legality goes, it's no different from acquiring games. You either have the necessary files, or you do not, and I believe the position of Dosbox not including it has more to do with how many people would come through support channels asking how to make it work, unaware that they need files not provided, and there is no way to obtain them from Roland. Yet, if dosbox kept the support in, EA (who owns Origin), or Activision (who owns Sierra) could in theory just license the files themselves and re-release the game in a "how it was intended to sound" way. Quite frankly, Roland should support Activision or EA adding a "DLC" for these files to those games, since the only other way to hear the original intended audio is to find someone who already ripped the game audio.

ScummVM IMO has a lot of scope creep and one reason why I don't bother with it, is because it's incredibly unusable with video recording software, where as DosBOX pretty much guarantees that the video and audio will line up perfectly (within expectations at least.)

The other thing I would like to see, is that 64-bit support works out-of-the-box on all platforms, but right now (as mentioned with cmake) it's a lot more trouble to compile than necessary. My "windows only" environment is basically I made 32-bit and 64-bit static libraries of everything dosbox needs and then modified the projects to point to the respective directories for linking. Pain to do once, pain to do everytime it's rebased.

Reply 195 of 236, by dreamer_

User metadata
Rank Member
Rank
Member
Kisai wrote on 2020-02-10, 09:00:

I brought it up because those are the two patches that I regularly made efforts to keep working on current versions of dosbox. So the question raised was "are these threaded" and the answer is yes. The way I would like them to be patched in is so that recording the game video records the audio (both mt32 and fluidsynth).

Perfectly valid use-case, IMHO. We can discuss these features in feature requests on GitHub.

Let's leave this topic for dosbox-staging announcements and user queries, not technical details. If you have questions about compiling dosbox-staging on Windows for x86_64, create a GitHub issue and mark it with "question" label.

llm wrote on 2020-02-10, 07:42:

Nobody cares about ArcaOS support in dosbox-staging, so I consider this topic closed.

llm wrote on 2020-02-10, 07:06:

great - are you able to give a brief overview what points are getting accepted (or getting discussed later) in short or long term (…)

I can only comment about specific commits/patches and if they qualify for inclusion in dosbox-staging.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 197 of 236, by dreamer_

User metadata
Rank Member
Rank
Member

To users interested in testing dosbox-staging with shaders introduced in SVN r4319 : report bugs in https://github.com/dreamer/dosbox-staging/pull/168, please.

Last edited by dreamer_ on 2020-02-11, 15:58. Edited 1 time in total.

| ← Ceci n'est pas une pipe
dosbox-staging

Reply 199 of 236, by ripa

User metadata
Rank Oldbie
Rank
Oldbie

"either rewrite DOSBox buildsystem in cmake"
I have been working on porting dosbox build system to cmake in a private repo with both Linux and Windows compatibility, but progress is slow due to work and other stuff.