Reply 220 of 1550, by Ant_222
And I like the new one because it is simpler and less cluttered...
And I like the new one because it is simpler and less cluttered...
Any chance you could document your patch procedure, if any patches interfere, etc?
All hail the Great Capacitor Brand Finder
wrote:Any chance you could document your patch procedure, if any patches interfere, etc?
Almost all patches interfere with each other. Especially in the files dosbox.cpp, sdlmain,cpp, makefiles, etc. So almost all new or changed patches have to be edited by hand (often applying and reversing them again and again) and then applied in the correct order. No real procedure here, sorry. 😀
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
Patch (the utility) can usually work around that, as long as it's not the same hunk being modified. One of these days, I'll get you to send me the list of patches you apply and try it myself.
All hail the Great Capacitor Brand Finder
wrote:Patch (the utility) can usually work around that, as long as it's not the same hunk being modified. One of these days, I'll get you to send me the list of patches you apply and try it myself.
The patch utility can work around wrong line definitions, but as you already said, if the same parts of a file are modified, patches will fail unless manually corrected. Which often is the case.
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
Hello, I am pleased that this new ECE-version is available and I would be even more happy, if it would also support MMX-Instructions and adjustable brightness and gamma (also for voodoo emulation)... maybe it will come true one day, because someone will enhance this ECE-version with this missing features ? 😀
wrote:Almost all patches interfere with each other. Especially in the files dosbox.cpp, sdlmain,cpp, makefiles, etc. So almost all new or changed patches have to be edited by hand (often applying and reversing them again and again) and then applied in the correct order. No real procedure here, sorry. :)
Thanks for the hard work. I am somewhat ashamed to tell you that I have fixed another bug in my patch and released alpha 14...
wrote:Hello, I am pleased that this new ECE-version is available and I would be even more happy, if it would also support MMX-Instructions and adjustable brightness and gamma (also for voodoo emulation)... maybe it will come true one day, because someone will enhance this ECE-version with this missing features ? 😀
ECE only uses a few patches over the official SVN DOSBox purposely. The more patches that are added can lead to instability issues and breaking existing code. The old broken Daum build is a perfect example. If you really want more bells and whistles take a look at the DOSBox-X branch.
wrote:wrote:Almost all patches interfere with each other. Especially in the files dosbox.cpp, sdlmain,cpp, makefiles, etc. So almost all new or changed patches have to be edited by hand (often applying and reversing them again and again) and then applied in the correct order. No real procedure here, sorry. 😀
Thanks for the hard work. I am somewhat ashamed to tell you that I have fixed another bug in my patch and released alpha 14...
No problem, a new build is already out.
I think I have to expand the versioning system again, far too often there are several build using the same revision number for SF...
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
wrote:No problem, a new build is already out.
Thanks. You are very swift.
I think I have to expand the versioning system again, far too often there are several build using the same revision number for SF...
Since any change to the official SVN and to the patches seems to trigger an update, you might express the version as two independent numbers: the official SVN revision and a cumulative patch modification number—a counter that you increment at incorporation of every change in the patches.
It's not true that noone was using the Linux version, I was for one. Though I compiled it from the source, but still used it.
YP80,
fmstrength is now under [pci] section and there is no OPL3 sound at all in ECE 4043.
Hi James-F,
Regarding fmstrength, I would like to ask you a few questions:
1 - A value of fmstrength=150 attenuates the music sound (mixer FM) in comparison to the PCM voice sound (mixer SB), correct?
2 - For comparison purposes, which value of fmstrength would deliver the default values and balance of DOSBox 0.74?
3 - Applying the value fmstrength=150 to DOSBox-ECE would be the same as applying the command "mixer FM 75" to DOSBox 0.74?
4 - Does fmstrength also change the balance between GUS (if chosen inside the game instead of FM) and SB (PCM)?
Thank you!
1. Yes.
2. 200 which is louder than any real SB card.
3. Close, but fmstrength is much more precise and it allows the FM mixer value to remain 100. Default in SVN (non ECE) is now fmstrength=150 but is is not configurable.
4. No, only OPL/Adlib to SB PCM.
wrote:It's not true that noone was using the Linux version, I was for one. Though I compiled it from the source, but still used it.
Oh, ok. One person was using the linux version after all. 😀 Might I ask why you compiled it again for yourself? Did you make any changes before compiling?
wrote:YP80,
fmstrength is now under [pci] section and there is no OPL3 sound at all in ECE 4043.
Thanks for the info, I don't know how this could happen, the patch shouldn't have applied at all at this position. Sorry about that! I adjusted all patches to the latest changes in the source, all should work again. (Hopefully) Fixed builds are online. Could you please check it out again?
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
Yeah fixed.
wrote:wrote:It's not true that noone was using the Linux version, I was for one. Though I compiled it from the source, but still used it.
Oh, ok. One person was using the linux version after all. 😀 Might I ask why you compiled it again for yourself? Did you make any changes before compiling?
I'm using Arch, so I made a pkgbuild to compile and install it. No patches were applied.
Yesterday I tried playing "Screamer" with my XBox 360 Wireless racing wheel, only to be remembered that joystick axis in DOSBox are limited to a maximum of 4 in total. So, using 2 joysticks, in my case my Logitech F710 and the racing wheel, you can use only 2 axis per stick, basically the left analog stick and nothing more. Even if you're using only one Xbox 360 compatible controller, you couldn't use all the axis, which resulted in a useless x axis of the right stick.
This bothered me, so I looked for a walkaround. And lookie here, someone here already made one for exactly this problem: DosBox fully bindable Joystick Patch
After some minor adjustements to the recent source code and after raising the maximum number of axis to 10 (each 360 compatible controller has 5 axis), I applied the patch to DOSBox ECE. Even though I couldn't get my wheel working, which seems to be a genral problem, I managed to get all axis of 2 controllers working, which basically enables players to use 2 Xbox 360 compatible controllers to their full extent now! Another nice feature of this patch is, that the digipad (aka the hat) is now mappable using the internal mapper, regardless of the type of joystick. Before the patch you had to select joysticktype=fcs to make the digipad mappable.
Unless it causes problems, this patch will be integrated in DOSBox ECE from version r4044.2 on. Please let me know if you encounter any trouble!
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
Hi James-F,
1. Yes. 2. 200 which is louder than any real SB card. 3. Close, but fmstrength is much more precise and it allows the FM mixer v […]
1. Yes.
2. 200 which is louder than any real SB card.
3. Close, but fmstrength is much more precise and it allows the FM mixer value to remain 100. Default in SVN (non ECE) is now fmstrength=150 but is is not configurable.
4. No, only OPL/Adlib to SB PCM.
Thank you! I understand it better now.
Although, I believe that the explanation in DOSBox.conf should be improved. The explanation says:
fmstrength: Strength of the FM playback volume in percent, in relation to PCM playback volume. Default is 150.
My understanding, when I first read this explanation, was that fmstrength=150 meant that FM would be 150% louder than PCM. But later, reading your explanations, I came to realize that fmstrength=150 is not making FM louder in comparison to PCM, but au contraire, it is making it quieter.
Regarding a few tests I've been conducting with fmstrength in different games, there are two games in particular where fmstrength does not seem to work. They are Star Wars: Rebel Assault and Star Wars: Rebel Assault II.
Apparently, no matter which value I insert for fmstrength, they sound just the same. It seems that these games have an internal mixer that ignores DOSBox's mixer.
I did one test that seems to corroborate this: I opened a DOSBox window, typed the command "mixer sb 50 fm 50", and then entered the game. No difference in sound whatsoever. After leaving the game, I typed the command "mixer", and it showed SB=100 and FM=100.
My question is: Even with this behavior—namely the game adjusting the mixer—the game should be sounding differently with fmstrength=150, or even fmstrength=1 for that matter, shouldn't it?