Assorted DOS port compiling questions (was dog graphics in mbf)

I want to recompile mbf with prboom-plus's libre dog graphics and sounds, but I don't know where to look. I have the contents of mbfsrc.zip unzipped.

Also, why is mbf so much darker than practically every other source port I've ever played? Is there a setting to fix the lighting. Before you ask, I fiddled with the gamma correction settings, and it only brightens things up. It doesn't fix the overall problem, and just looks ugly at high gamma.

I don't know how to explain this problem any further. Should I post screenshots of boom, mbf and prboom-plus to show what I mean?

edit:I take those last two paragraphs back. I had high gamma in boom as well and didn't realize it.

Unfortunately, the dogs graphics and sounds in MBF are hard-coded as binary arrays, so you cannot simply replace them by other implementations.

The madness can be found in info.c:
https://github.com/fragglet/mbf/blob/master/info.c#L10899

It Killough's way, or the highway!

fabian said:

Unfortunately, the dogs graphics and sounds in MBF are hard-coded as binary arrays, so you cannot simply replace them by other implementations.

The madness can be found in info.c:
https://github.com/fragglet/mbf/blob/master/info.c#L10899

Huh? He wants to recompile MBF. What would stop him from replacing those blobs?

do you have any suggestions as to converting gfx and sounds to binary arrays?

Danfun64 said:

prboom-plus's libre dog graphics and sounds

This sounded cool but it turns out that they're just a modified version of the Freedoom demon sprites. Boo. "A serpent is a Marine's Best Friend" just doesn't have the same ring to it.

Surely there must be someone on Doomworld with a dog who's willing to make their pet famous? :)

Danfun64 said:

do you have any suggestions as to converting gfx and sounds to binary arrays?

As I recall, TNT's Boom utilities included a tool for encoding binary files as C arrays. Check utilsrc.zip (here).

printz said:

Huh? He wants to recompile MBF. What would stop him from replacing those blobs?

Nothing. Any bin2c type of program can be used to do so.

Here's one I wrote once:
https://github.com/team-eternity/eternity/tree/master/tools/qbin2c

one more question. There are some sounds in prboom-plus that don't have libre equivalents. What should I do about them in the mbf source code?

Danfun64 said:

one more question. There are some sounds in prboom-plus that don't have libre equivalents. What should I do about them in the mbf source code?

You could just replace them with empty (zero-length) sounds. Use the Freedoom dummy.wav sound. Or find someone with a dog and record it barking.

Bear in mind that the dogs aren't the only non-libre data in info.c though:

const lumpinfo_t predefined_lumps[]={
  { "M_HORSEN", sizeof m_horsen, m_horsen },
  { "M_VERSEN", sizeof m_versen, m_versen },
  { "M_COMPAT", sizeof m_compat, m_compat },   // killough 10/98
  { "M_GENERL", sizeof m_generl, m_generl },   // killough 10/98

Menu graphics that I believe are in the Doom font. Freedoom's build process generates renderings of these in the Freedoom font, so you could just use those instead. The new Freedoom font is close enough to Doom's font that it probably won't clash too badly.

  { "STKEYS6",  sizeof stkeys6, stkeys6 }, //jff 2/24/98 double key graphics
  { "STKEYS7",  sizeof stkeys7, stkeys7 },
  { "STKEYS8",  sizeof stkeys8, stkeys8 },

Might be derivatives of the Doom key graphics. But they seem different enough that they're probably fine.

  { "BOXUL",    sizeof boxul, boxul }, //jff 2/26/98 background window graphics
  { "BOXUC",    sizeof boxuc, boxuc },
  { "BOXUR",    sizeof boxur, boxur },
  { "BOXCL",    sizeof boxcl, boxcl },
  { "BOXCC",    sizeof boxcc, boxcc },
  { "BOXCR",    sizeof boxcr, boxcr },
  { "BOXLL",    sizeof boxll, boxll },
  { "BOXLC",    sizeof boxlc, boxlc },
  { "BOXLR",    sizeof boxlr, boxlr },

Probably fine but might be somehow derived from Doom textures? I have no idea.

  { "STTMINUS", sizeof sttminus, sttminus }, //jff 2/27/98 -- for v1.2
  { "WIMINUS",  sizeof wiminus,  wiminus},   // killough 4/25/98 -- for v1.1
  { "M_NMARE",  sizeof m_nmare,  m_nmare},   // killough 4/25/98 -- for v1.1
  { "STBAR",    sizeof stbar,    stbar},     // killough 4/25/98 -- for v1.1
  { "DSGETPOW", sizeof dsgetpow, dsgetpow},  // killough 4/25/98 -- for v1.1

Lumps from the Doom IWAD that weren't in older versions of the IWAD, included for compatibility. Can probably just be removed.

#ifdef BETA
  // killough 7/19/98: Pre-Beta BFG fireballs
  {"PLS1A0", sizeof pls1a0, pls1a0},
  {"PLS1B0", sizeof pls1b0, pls1b0},
  {"PLS1C0", sizeof pls1c0, pls1c0},
  {"PLS1D0", sizeof pls1d0, pls1d0},
  {"PLS1E0", sizeof pls1e0, pls1e0},
  {"PLS1F0", sizeof pls1f0, pls1f0},
  {"PLS1G0", sizeof pls1g0, pls1g0},
  {"PLS2A0", sizeof pls2a0, pls2a0},
  {"PLS2B0", sizeof pls2b0, pls2b0},
  {"PLS2C0", sizeof pls2c0, pls2c0},
  {"PLS2D0", sizeof pls2d0, pls2d0},
  {"PLS2E0", sizeof pls2e0, pls2e0},
#endif

Fireball sprites for MBF's beta emulation and the BFG 2704. These come from the beta doom.wad IWAD. Can probably be replaced using some of Freedoom's plasma ball graphics.

  { "M_SETUP" , sizeof m_setup,  m_setup },   // phares 3/24/98 menu item
  { "M_KEYBND", sizeof m_keybnd, m_keybnd},   // phares 3/24/98 menu item
  { "M_AUTO"  , sizeof m_auto,   m_auto  },   // phares 3/30/98 menu item
  { "M_CHAT"  , sizeof m_chat,   m_chat  },   // phares 4/10/98 menu item
  { "M_ENEM",   sizeof m_enem,   m_enem  },   // phares 4/08/98 menu item
  { "M_STAT",   sizeof m_stat,   m_stat  },   // phares 3/29/98 menu item
  { "M_WEAP",   sizeof m_weap,   m_weap  },   // phares 3/28/98 menu item
  { "M_MESS"  , sizeof m_mess,   m_mess  },   // phares 4/08/98 menu item
  { "M_COLORS", sizeof m_colors, m_colors},   // phares 4/01/98 menu item
  { "M_PALNO",  sizeof m_palno,  m_palno},    // phares 4/01/98 menu item

More menu graphics in the Doom font.

  { "STCFN096", sizeof stcfn096, stcfn096},   // jff 4/5/98 missing char

An extra font character, probably derived from one of Id's font characters.

I have no intention of using the beta sounds and gfx.

As for menu graphics, the freedoom iwad already replaces them (I think).

Fair enough. If that's good enough for you, why not just put the libre "dog" sprites into a PWAD? I believe MBF has a configuration option that lets you specify a WAD to always load on startup.

Danfun64 said:

do you have any suggestions as to converting gfx and sounds to binary arrays?

Yet another binary-to-C-array translator is xxd (a program that comes with Vim)

Remember the graphics need to be in doom's internal patch format before being converted to C. Sadly I do not know of a program that will do just this without doing other things you don't want (such as wrapping the output patch in a wad).

I'm using the bin2c converter from boom. It seems to work best.

So I am just able to remove the graphic entries for unused graphics? What about unused sounds?

edit: Tried compiling it


Didn't go well...

Danfun64 said:

edit: Tried compiling it
[...]
Didn't go well...

Try to edit the Makefile and remove the two parameters that GCC complains about from CFLAGS.

MBF is very unlikely to compile with recent versions of DJGPP. You'll need to find the old version of the compiler that was used back in the late '90s to compile it.

A while back (> 10 years ago) I tried to compile MBF under the current version of DJGPP and Allegro and found it didn't work. I succeeded in compiling a bugfixed version after making a bunch of changes but I doubt that still works now.

That's what I am trying to compile, mbf-fixes. Specifically commit a767bcd21e2b65ddef827e6fa283710ce893a3f7 (for reasons found here, though long story short, I am not sure how prboom-plus trunk handles mbf demos with the 3 key door bug fixed. As far as I know, the earlier changes from mbf-fixes don't affect demo compatibility.)

Any advise on what versions of allegro and djgpp to use? Does prboom-plus support demos with the 3 key door bug fixes?

Heh I thought that this was about mbf's graphics being "a real dog" :-p

Maes said:

Heh I thought that this was about mbf's graphics being "a real dog" :-p

Bad news is after looking around extensively, I can't find either the info on the needed version #'s of DJGPP and Allegro to compile Boom and MBF, nor can I find the actual old versions of DJGPP - as complete distributions - for any of the previous versions.

I think this stuff may have bitrotted beyond compilability now and pretty much MUST be modified/updated in order to run in its original environment.

I don't know how we managed to let this happen, TBH. There should have been an archive of the stuff somewhere. There's a chance I still have it in working form on my old Win98 box, but exporting it from there in a fashion that'll work for somebody else to run might be challenging.

Just tried to build the original MBF on my DJGPP installation in DOSBox. Everything works. The installation is approximately 1 year old, I don't have the zips anymore (or at least I can't find them on my HDD), but I've looked into the manifest directory:

bnu27b GNU binutils 2.7 for DJGPP V2
csdpmi4b CWSDPMI binary distribution (release 4)
djdev201 Development Kit and Runtime
gcc2721b GNU GCC 2.7.2.1 for DJGPP V2
mak3761b GNU Make 3.76.1 binaries for DJGPP V2
txi390b GNU texinfo 3.9 for DJGPP V2

The Allegro version is 3.0.

Da Werecat said:

...
djdev201 Development Kit and Runtime
gcc2721b GNU GCC 2.7.2.1 for DJGPP V2
...
The Allegro version is 3.0.

YES! These were the numbers. Had been wracking my brain for a week thinking. I kept thinking 2.02 for DJGPP but I'm pretty sure that "BOOM 2.02" had overwritten it in my memory. (It may build with 2.02, but I'd be surprised because I know that GCC's inline asm changes significantly shortly after 2.01, and breaks a bunch of Killough's register clobbering declarations).

I switched to use all those tools, except for allegro, where 3.12 is mentioned, and csdpmi, where I am using v7. I compiled allegro 3.12, but dosbox crashed in the middle of compilation. I was able to continue compiling where I left off.

After that, I tried to compile mbf, and well...



I think I'm missing something, but not sure what.

edit: Do you want me to upload my allegro and djgpp folders?

Bump.

Does anybody have any advise about my problem?

I am not sure how the gcc tools for DOS (and DOSBOX itself) handle different/mixed types of path separators, but maybe changing that slash (/) to backslash (\) in obj/doomdef.o could help?

Also, you might have to create the obj directory beforehand, if it's not already present. Sometimes compilers can get pretty fussy about such trivia.

Does the "obj" directory exist?

Da Werecat said:

Just tried to build the original MBF on my DJGPP installation in DOSBox. Everything works. The installation is approximately 1 year old, I don't have the zips anymore (or at least I can't find them on my HDD), but I've looked into the manifest directory:

bnu27b GNU binutils 2.7 for DJGPP V2
csdpmi4b CWSDPMI binary distribution (release 4)
djdev201 Development Kit and Runtime
gcc2721b GNU GCC 2.7.2.1 for DJGPP V2
mak3761b GNU Make 3.76.1 binaries for DJGPP V2
txi390b GNU texinfo 3.9 for DJGPP V2

The Allegro version is 3.0.

Thanks for this. If I get time, I'll see if I can build a binary for my mbf-fixes site - it's currently just source code as I don't have a .exe. Or maybe someone else can do it for me.

once you build a binary based on latest commit, can you post it online, along with things like cwsdpmi (version 7 preferably), asetup, ipxboom?

Sorry for necrobump, but I have a new problem:



I created the obj folder, and the objdebug folder for good measure, and then I get this error.

What now?

Sounds like a problem with Allegro. IIRC SAMPLE is one of its types.

I successfully compiled it
http://www.mediafire.com/download/rjiclcybdf4tuoc/MBF.EXE

Hip Hip Hurray, a necrobump! *ratatatatata...*

I wasn't sure whether to create a new thread or not, but considering why I posted the original thread in the first place...

The original reason I wanted to compile the latest mbf-fix is because it lacked the demo desync bug. An idea came to me: Put Crispy Doom's demo fix into Boom. That way I can ignore mbf and use Boom instead, as the only reason I wanted to use mbf in the first place is for multiplayer demo recording. With the source changed, I downloaded what I thought was needed to compile Boom. I was wrong.



Here is my djgpp manifest, minus Allergo 3.0 of course.



edit: I'm an idiot. I missed gcc2721b.zip somehow. Please disregard this post.

edit 2: Please disregard the message telling you to disregard this post. I have achieved success.
http://www.mediafire.com/download/qiiud8iojdvjyl7/boomfix.zip