VOGONS


First post, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

Not sure whether to put this here or in DOSBox forums. Figured here is safer. I'm really wanting to control aspects of the munt driver or emulated HW itself, and not DOSBox values. Already asked about adding MIDI to the mixer settings (a long time ago,) and was educated at the difficulty with all the different standards that are incompatible with that 🙁 Not to mention that Windows 7 has completely removed any access to MIDI controls. I have to use hacks just to access my cards on-board synth, and even then I can't get any sort of volume control to work 🙁 #$^@! Microshaft and all their "it's for your own good because you cannot be trusted to control or adjust anything" attitude!

I primarily use munt to play MT-32 games in DOSbox without having to do a massive patch adjust. I already have an extensive collection of .diff files that I have to manually enter because some were designed for older versions (and not the SVN,) and putting one in will invalidate the values of all the rest (not always but in many cases.) It's just easer to install munt (awesome work on that BTW,) and set the device to MT-32 (midiconfig set to value given by mixer /listmidi.)

The problem I'm facing is that just about every game plays the music & fx at different volumes. If I set the system volume for munt for one game, the next game will either be inaudible or will burst my ear drums. The MT-32 device panel shows a volume control, and I've watched games adjust this value. I've also seen that the "output gain" slider under properties doesn't seem to be adjusted as well. Finally, in some cases the FX (which are usually only assigned to 1 or 2 channels depending on the game - or so it seems,) will sometimes be very hard to hear compared to the music.

Taking all that into consideration, I went searching for DOS programs that would let me set some of these values at least. I'm Thinking that the "output gain" property may not be normally controllable from DOS (emulating a volume dial on an external device maybe?) Hoping to find something that could "lock" the volume, and maybe even change the volume on specific channels (channel 2 & 3 in Ultima 7 raised just a little above the others, channel 1 lowered a bit for example.) Only, I couldn't find anything. I found a utility to turn "off" a device (mute it,) so that someone with a wavetable and an external device could use just 1 of them. But nothing for setting the volume(s) much less locking them. Being an amateur programmer, I thought I'd just write something. Only, I cannot seem to find instructions for this that I can decipher.

What I'm asking then, is there something that will do this? Is there an interface that would allow me to send such commands to the MT-32? Preferably inside the DOS emulation via the MPU-401. However, a command executed by a script prior to starting DOSBox, adjusting the munt drivers (and not the emulated HW,) would work just as well. Automating the process so I don't have to remember to open windows 7's volume mixer and adjust the volume for "Munt MT-32 Emulator," making sure I know precisely where to put it for that specific game. That gets to be a hassle after a while 🙁 It's also getting rather difficult to get it right. One game, I have to lower my speaker volume to 50% (I keep it at 100% so that when I watch a movie and have to raise the volume, it doesn't increase everything else as well,) and then lower the munt volume to 1%. Even then things are a little loud, but I don't really want to raise with DOSBox's other volume settings any higher to allow me to lower speaker volume below 50. I'm already tripling DOSBox's normal values, and raising the Windows 7 DOSBox volume up to the max (matching the speaker's 50.)

Feeding Dragon

Reply 1 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Hmm, I'm definitely not an expert on this but I doubt you can do this yet. On OS X you can use the Munt qt-GUI that functions as a real MT32 so you can set the volume back to your likings after the game starts playing music. Perhaps the munt people will add some tool so you can set the volume permanently. This will all be outside of DOS(Box) as I really doubt you can control the mt32 volume alongside a game playing midi

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 2 of 18, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

I was hoping that there was a command to turn "off" certain aspects of the control codes (the ones the game uses to adjust the volume.) In my researches in the past I came across a command that would disable certain command sets but I don't remember the web site or details now. I do remember that I didn't completely understand it, of course I wasn't trying at the time. I've also come across midi files that when "played" didn't produce any sounds but would configure certain aspects of certain devices. One which would turn "off" a SCB-55 for example, so that you could use an external device instead. I was hoping there was a way (even to playing a midi file if necessary,) to set and "lock" the volume. Ultima 7 (to use a previous example) sets the volume to 70, while Ultima Underworld sets it to 100 (or resets it and doesn't change it.) It would be nice to either play a midi or just issue a command that would set it to 70, and then lock it so that even a reset won't change it. Don't know if a real MT-32 could even do that. My research hasn't turned up anything one way or the other really.

Failing that, an alternative would be a script command that could set the properties. This would be placed into a script file (.bat or more likely AutoIt,) and would require re-shortcutting my MT-32 games, but that isn't a big deal. An example command to set the "Gain" levels to -3db might be: "muntset /gain -3" Which would be the same as turning the volume dial on an external unit down. Maybe have to include some sort of driver ID. So, since my munt device is MIDI device 3, it might be "muntset /D:3 /Gain -3". That would allow people with multiple drivers installed to specify which one. Can you install multiple drivers? Seems like a nice option, have a driver for each ROM set you've ripped, so you can pick the driver for what the game was designed for 😀 Sorry, getting off topic (lack of sleep.) Then I could reduce the gain in the properties which would have the same effect as adjusting the volume, but would be in the properties area. There isn't anything under properties to distinguish between channels, (there isn't on the emulation volume control either that I could see,) so I would have to give up on that idea. Could also control such things as MIDI delay mode, DAC emulation, reverb, etc... Looking at the properties box, may have to specify the input process as well (dosbox.exe in my case.) So... "muntset /D:3 /Gain:-3 /Reverb:on /Mode:2 /time:15 /Level:20 /RGain:1 /reverse:on /P dosbox.exe" would be a full command line to lower the overall volume by -3db, force Reverb on in plate mode (2) with a time of 50 level 20 an amplification of 1db with reverse stereo on MIDI device 3 for the process dosbox.exe. Though I imagine this is getting into feature requests. Much easier just to have a command that would load a specific profile, then I just have to save a profile for every game.

If nothing like that already exists, guess my only option is to go to the munt site and file a feature request if they have that option open (not all projects allow it.)

Feeding Dragon

Reply 3 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

I'll try to get sergm's attention on irc, maybe he has more insight/ideas...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 4 of 18, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Hey, All!

Dominus:
I rarely visited IRC recently but the Summer comes, and I hope I'll have more free time since now to spend on munt.

FeedingDragon:
Welcome to the mess of munt 😉

Weird, I had a feeling that most inhabitants here wish to use the emulation included directly into DOSBox for convenience...
Well, at least, my point is also to use an external emulator instead as it significantly simplifies development. But for gaming, it still seems to me that having mt32emu-patched DOSBox (especially if the emulation support was "official") is easier in day-to-day use. Most of the "vital" options can be directly set and monitored right from DOSBox's command line/.bat script, so it should be very easy to setup the emulated synth just prior to staring a game. If you haven't got it yet, you should find MT-32 and/or LAPC-I sysex description. There are dozens of sites to download. Having that, you will be able to program and tune either a real synth or the emulation to taste (well, within certain limits). Most unpleasant thing for you is that some games reset the synth at first when they are loaded, so you cannot actually do something without an external synth (though, maybe you can use a TSR to inject a sysex afterwards 😉 ).

Still, I don't actually get the issue with audio volumes. It is looking ridiculously easy to set a volume of any audio source in DOSBox using its mixer (you can either lower FX volume or _increase_ mt32emu output or whatever). But I'm unaware of the possibility to fix the volume of individual channel. All we can control at channel level is standard volume/panpot which is constantly changed by most tunes. I think that should never be done unless we want the tune to play really weird. As for inconsistent volume of FX channels, I guess something is wrong with the emulation (game settings) in this case. Note, some games do NOT reset the synth, so if you load such a game after another in the same DOSBox session, you can get _very_ wrong sounding. Very good practice is to load a game in a dedicated DOSBox session. Alternatively, you should play the "reset sysex" before new game loading (along with issuing other tuning commands like reversing stereo and setting up mixer). So, I really doubt this feature will be appreciated...

OK, if you're still unconvinced with the points above and prefer to use an external emulation, let's discuss the current state and features closely. You've found it right, we can setup several synth profiles. Each profile refers to its ROM set and a few emulation settings, including those mentioned output gains. The output gain cannot be controlled via sysexes (by a game) and is essentially an emulation of analogue amplifier gain (though, we divided the non-reverb and reverb output, but the actual hardware obviously uses single amplifier for each of left and right channels). Thus, setting the output gain you effectively do the same thing as with the DOSBox's mixer. And yes, different profiles may set different output gain values. All you have to do is to change the profile when switching games. This obviously may be automated. But I don't think it's worth creating a new command-line tool. It looks like it would be fine to just add a command line argument (like "profile") to the UI app. In a hacky way, you can load the default synth profile setting to the registry (and even all the emulation settings) and do this before starting DOSBox, for example. But the "profile" argument looks nicer, of course. 😀

Another important point. Whatever number of windows MIDI drivers you install, mt32emu driver is intended to be installed only once. Besides the limit in the installer, the driver loads settings from the same registry path, so you won't gain anything setting up another driver instance manually. When we added the UI synth app, we had in mind making a router for several independent multi-source synths. So, when the driver "sees" the UI app running, it doesn't use internal synth engine but directly communicates with the UI app instead (it actually creates a "MIDI session"). And if there is no UI app running, the driver engages its internal synth and loads _default_ synth profile. This means you can still control the driver synth engine, though in a somewhat limited way.

Reply 5 of 18, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

Actually, using an emulator that's been included with DOSBox would be much easier. Once it's actually in place. The problem is, I'm already implementing a large number of patches. Some I've picked up from others and some I've written myself. This leads very quickly to the problem that the .diff files quickly become invalidated. I've toyed with the idea of combining them all together into one large file. The only reason I haven't is I've never been able to get the automated patch to work. I put them all in manually. Some time in the future, I'll probably put a bit of work into getting that set up better, but for now....

Having a second driver installed, and adjusting the individual channels were actually just errant thoughts that popped up while considering the issue. Really, just having a command line switch that will load a specific profile, or set a specific profile value (such as gain,) is all that I was originally thinking of (everything else was thoughts on alternative that sort of grew.) Using sysex commands won't work. The games I play that are the worst (where volume is concerned, being either way too quiet or way too loud,) all "reset" the device on a regular basis (which got rather frustrating, let me tell you.) Start game, in a hurry, so I just turn the volume down and go back to full screen. Load my game, create a character, change rooms (it all depends on the game,) and suddenly the volume is back where I didn't want it 🙁 Right now, as a temporary fix, I have the problem games set to load in windowed mode with a pause before the game starts. This reminds me to set the gain before the music starts.

I probably will incorporate the MT-32 patch into my DOSBox build eventually. But I still think a command line to load a specific profile or set specific profile values is a good idea 😀 Though, I tend to have the console load on boot so I can access it with WinAmp and such. Though I've discovered (quite by accident,) that you can have multiple consoles loaded (they use the same driver though.) So, unless that's just a bug with my system, I would have to remember to "unload" the console before executing the command that would activate the profile changes.

I never realize how much of a difference a real MT-32 (even a mostly real one,) made 🙁 I've used MT-32 Synth maps, and even MT-32 sound fonts, and they are worlds apart from the emulation, can't wait to find out what a real one will sound like. Nothing personal, but usually a real unit will be better than an emulation, not "always" the cause, but usually. Even though I'm going to have to run it through my sound card until I replace my equalizer. Using all 4 inputs right now. Been seriously considering getting another one anyways (that would allow surround sound output, with adjustable up-sampling.) If I'm getting another one anyways, might as well get one with more input channels.

Feeding Dragon

Reply 6 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Kind of off topic, but through "svn diff" command you can have a merged diff file after you apllied all patches...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 7 of 18, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Dominus has just expressed a definitely good point. Nowadays, there are loads of version control systems to deal with multiple patches properly and safely. Though, I personally, prefer distributed SCMs like Git and Mercurial. Besides, applying our latest mt32emu patch should be quite easy: only a couple of rows are changed, the MIDI handler is independent and live in its own files.

Well, I'm still not sure what's problem with volumes. Let me tell you a secret. Using default output gain setting, mt32emu engine produces nearly bit-accurate wave which differs from the digital captures we took by +-2 in terms of amplitude. This ensures no distortion is added compared to the hardware, and the distortion added by the hardware is reproduced. Actually, most games really do take care of the master volume exclusively to prevent the real hardware from creating distortion which was a real pain in those times. So, to be fair, increasing the output gain isn't always a good idea if you don't want to degrade the audio quality. Though, there are cases when composers set the master volume really too low, and we can safely add more amplification. The said above should make it obvious, that making master volume fixed isn't a good option and it doesn't actually give you more control vs. using output gain. You can even consider the output gain as a "fixed master volume"... 😀

Anyway, I plan to implement at least synth profile setting as a command line argument for the UI app. BTW, you're right about a little sense of starting several UI app instances on windows. I actually thought about to prevent a second instance to start but I've found no easy cross-platform way to do so, and on other platforms you can really take advantage of having multiple instances running (though, this isn't essential as the UI app can have multiple synths which are _independent_).

Reply 8 of 18, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

About to pack my computer, so can't do it now, but I'll take a look at the mt32emu patch after I get back up and running. My last patch added direct3d and it was a real pain to add in. After all my patches not one line (except the "new" files of course,) matched up.

Dominus: Is it possible you could point me to some "good" instructions on building/using .diff files. That's the one thing I've always planned to do. Build a merged patch (instead of having all the separate one.) That would make it ease, Build a .diff file between my code and the code a new patch is based on, merge (if it's possible,) the new .diff file with the one I created, then apply that to the source. But when I did web searches for applying .diff files, I ended up with programs that either didn't work or required other programs that I didn't have. Of course, I didn't do an "extensive" search, only about 2 hours worth. I didn't come across a program called svn what is it part of?

Feeding Dragon

Reply 9 of 18, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie

Ok, got my system back up and running (for a couple of days now.) Spent the entire day searching and patching. Finally got the munt patch for DOSBox to work. Do NOT follow the instructions, leave the midi_mt32.h files in the sub-directories (asynch, synch, etc...) alone. They all break the patch (will look into that further in the future.) You have to stick with the one the diff file (marked for revision 3858,) creates. Finally got a patch/diff pair working for me. Still cannot find a tool that will merge all my .diff files together. I can make the merged file by using diff.exe on my source compared with the 3858 source. Still means I have to manually enter the diff file the first time around. Found plenty of references to "combinediff" as a Unix file, but couldn't find a Win version of it, and gave up trying to get it to compile. I'm fairly sure I'm finished with my patching though, just have to be prepared to update my diff when new revisions come out.

As for munt in DOSBox, it works like a charm. If I had another set of ROMs, I could put them in separate directories and then chose the ROM set with the MT32.romdir= line. Mixer can set the MT32 volume, so that's nice (extremely so for those games that set the volume through the roof.) I still wish there was some sort of properties switch on the qt.exe to load a specific set, or change specific settings (for other apps,) along with a "just change things, don't actually load" switch (I'd end up with 20 of them in my systray.) The only issue with DOSBox, even when I set thread to on, if the cycles are just a little too high munt stutters and slows down considerably. Long before digital sound starts giving me problems. On my system, digital sound plays just fine up to 150k cycles. Munt starts choking at 75k. Not much of an issue, don't have many games (ok, can't think of any,) that needs more than 25-30k cycles. Yes, I tend to benchmark things when I create a new build.

Feeding Dragon

Reply 10 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

If you grab Dosbox' SVN via commandline SVN (or if however you gravb SVN has also SVN command line tools) it's as simple as "svn diff > merged.diff" after you applied your many patches

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 11 of 18, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Well, it would be a bit easier for you to deal with DOSBox patch if you read README. It clearly indicates the purpose of each file included, so you'd not waste your time trying to apply patches for incompatible DOSBox version (I assume you work with SVN head).

In order to work with multiple patches easily, it seems a better idea is importing your patches to a version control system and merge them with the DOSBox sources. Easiest way is using SVN as DOSBox sources reside in a SVN repository, but there is a possibility to convert it to others version control systems which you may find more convenient to use. Anyway, the crucial thing to do merging is a good third way merge tool. Unfortunately, it isn't possible to perform merges automatically in many cases, so, most likely, you'll need to merge manually. Such a merge tool allows you to view original source file (at a specific revision you want to apply a patch) along with changes on both branches (in your case the subsequent DOSBox SVN revision and the changes in the patch to be applied) and decide which change should actually take place and in which order. You can also do a manual change if needed. Then, when you did a merge and all works fine, you can export the resulting cumulative patch or better just use the version control system further. 😀

Reply 12 of 18, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote:

Well, it would be a bit easier for you to deal with DOSBox patch if you read README. It clearly indicates the purpose of each file included, so you'd not waste your time trying to apply patches for incompatible DOSBox version (I assume you work with SVN head).

I did read the README... To quote:

README file wrote:
Patch for official DOSBox release v.0.74 to add mt32emu MIDI device […]
Show full quote

Patch for official DOSBox release v.0.74 to add mt32emu MIDI device

dosbox-0.74-mt32-patch.diff - diff file to be applied to DOSBox's source distribution.

singleThread/midi_mt32.h - straightforward version of the synth engine.
Simple, accurate and robust rendering.
Lacks the support for additional CPU / cores.

syncThread/midi_mt32.h - version of the synth engine with synchronous rendering in a separate thread
Utilizes power of another CPU / core.
Adds latency about 1 ms and consumes more CPU time.

asyncThread/midi_mt32.h - version of the synth engine with asynchronous rendering in a separate thread
Compared to the sync version, consumes significantly less CPU time.
Adds latency about 128 ms.

===========================================================================================================

dosbox-SVN-r3858-mt32-patch.diff - diff file to be applied to DOSBox's source distribution.
It uses a bit different and clear approach introduced since SVN r3836.

Where does it say that the various midi_mt32.h files are completely incompatible with DOSBox builds? It seems to me that it is fairly straight forward. For SVN 3858, use "dosbox-SVN-r3858-mt32-patch.diff" then use the midi_mt32.h most compatible with the system/build you are creating. I have a multi-core (4) CPU, DOSBox only ever uses 1 core, so lets put the mt32emu in another core... Logical? I think so, so that's what I did. Only, if you replace the midi_mt32.h file created by the .diff file, it will not build. After a lot of searching to see what others did, I tried it without replacing the header, and it built just fine. I then tried the other specialized headers, just to see, and they all failed.

As for version control systems, I've never much liked them 🙁 They seem a little monolithic to me. I installed one once, years ago, to try and work with another package. Don't remember which system it was, but after fighting with it for a week, I just removed it and downloaded the source manually. This was before I started working with patches built by other people... I just altered the code and built my own versions. From my reading, SVN wouldn't offer me much more than I'm getting from diff.exe and patch.exe, just a graphics interface and access to the current SVN code online. I did look at one SVN client, TortoiseSVN I believe. It didn't offer a combinediff type command which is what I was looking for. The other client I looked at wanted $50 in order to do more than just "look" at the files (don't remember the name of that one.) There were others, but I think I'm pretty much patched out for now. Not much more I'm looking for in DOSBox. I'd sort of like to put the 3dfx patch in, so I can use one DOSBox for all my games, but since the only game I have that needs it is Tomb Raider (and Unfinished Business,) It's not that high a priority.

Feeding Dragon

Reply 13 of 18, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

So, you didn't notice all those header files belong to the first patch for official 0.74 release? Sorry, then...

Who am I to convince you in using version control systems? If you find it better to apply patches by hands - have fun 😀

Reply 14 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

SVN would give you the ability to do a combined patch. You asked, we told you how to do it, entirely up to you to follow that.
http://sourceforge.net/projects/win32svn/ seems to be the real deal, command line SVN (not the gui wrappers you seem to have tried).

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 15 of 18, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

SVN would give you the ability to do a combined patch. You asked, we told you how to do it, entirely up to you to follow that.
http://sourceforge.net/projects/win32svn/ seems to be the real deal, command line SVN (not the gui wrappers you seem to have tried).

Thanks, I'll try that one. I actually tried several GUI based DIFF programs, some SVN based, some based on other engines, some didn't seem to be "online aware at all." WinDIFF stick out because it crashed every time I had it write to a file. It would finish that file, true, but if I'm patching more than one file at a time, it became a hassle. None of the others stick out so clearly. I'd really like a GUI 😀 Yes, I'm used to using command prompt for a lot of things, but GUIs are nice too.
I guess what it boils down too, what I want in a GUI:

  • Will work with local files only if I ask it too (if it's designed for online access.)
    Can take multiple diff files (2 at a time works,) and combines them. Only really needed if the diff files patch the same file.
    Will examine 2 directories and build a diff file from those (One I got would only do 1 source file at a time.)
    Will take a diff file and apply it to source, marking the ones it couldn't apply, and the reason.
    Ideally, if it failed because the original source lines (--- part) didn't match, it would pop what it was looking for, and open the file at that location, allowing me to scroll to see if it's just been moved a bit.

Grrr... Accidently hit "submit" instead of "preview"... Oh well, editing.....

I don't really think that is too much to ask for. All told, I tried..... (don't have installer logging turned on, counting now...) 10 different GUI applications found in searches that included variations of the search terms: SVN, DIFF, Windows, Merge, Combine, Create, Make, Patch, & Source. I found diffutils (diff.exe,) and Patch early on and there were some GUI applications I skipped because I sort of remembered trying them before.

Feeding Dragon

Reply 16 of 18, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote:

So, you didn't notice all those header files belong to the first patch for official 0.74 release? Sorry, then...

Who am I to convince you in using version control systems? If you find it better to apply patches by hands - have fun 😀

I guess that's what the "=======" line represents. When I first read it, I sort of went with it representing an addendum. Sort of, everything above this is what I wrote originally, now I'm adding this extra bit since I added a new file. Never looked at the 0.74 diff file to see if it even created a midi_mt32.h file in the first place. FYI - it creates one as well, so that wouldn't have been an indicator. The 3858 code puts the multi-core option as a config file entry instead, so nothing lost there.

It's not so much that I find it better to apply by hand. It's more that I can't find a GUI I'm happy with. Ok, I'm picky. But the only GUI I tried that covered most of my criteria, crashed every time it wrote to a file. Write a file, crash.... Write the next file, crash.... I uninstalled it and moved on. If it's going to cost money (and some do,) I'll only be paying for it if it does everything I want. The rest I tried didn't even come close to what I'm looking for. One wouldn't work offline, one would only work on a file by file basis, one would compare multiple files but would only create diffs for one file at a time, and one would not allow any sort of view area re-sizing. My monitor is fixed 1366x768, when I brought up a text view of the file, it was literally off the bottom of my screen, and I couldn't drag it far enough to read more than 2 lines. I changed my resolution to 1080, and it resized itself to do the same thing (even though the font stayed the same - teeny tiny and hard to read at that resolution.)

Feeding Dragon

Reply 17 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

One last time, what I recommend is grabbing Dosbox source via SVN, then apply your patches in whatever way you need to, most likely it will be manually. After you've done this you can command svn to make one big patch/diff file with the changes you did to the source. With plain command line SVN that's just the command "svn diff > pathandnameofthepatchfileyouwanttocreate".
After doing this you can probably apply this big patch to upcoming revisions automatically via whatever patch/diff program you can use on Windows.
That's the simple solution.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 18 of 18, by FeedingDragon

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

One last time, what I recommend is grabbing Dosbox source via SVN, then apply your patches in whatever way you need to, most likely it will be manually. After you've done this you can command svn to make one big patch/diff file with the changes you did to the source. With plain command line SVN that's just the command "svn diff > pathandnameofthepatchfileyouwanttocreate".
After doing this you can probably apply this big patch to upcoming revisions automatically via whatever patch/diff program you can use on Windows.
That's the simple solution.

DiffUtils does that too, though I have to supply the original source in a separate directory (have it set up as 3858 and Dragon.) Patch applied the created diff file to the source without issue, though the diff file is based on that exact same source, so that isn't much of a surprise. The challenge will come with the next committed revision. That is when some sort of graphical means of tracking the changes would really come in handy, but it would have to has some really smart coding. It would have to recognize code that has been moved and re-written, so that it could point to where a patch would go, then give me a chance to examine the re-written code to see if the patch is even necessary, or if it needs changing, etc... I don't think anything like that exists. The tools I've been testing are not much better than what I'm already doing. ?WinDIFF? really promised to be something, if only it didn't crash all the time (going to look into that eventually.) It's not WinDIFF it seems, re-doing a search to find the one I like but kept crashing 🙁

Feeding Dragon