Compiling Boom source

[printz]

What application do I use to compile the Boom source code? The ones I have - Visual C++ 5.0 and Visual Studio .NET - lack DOS-specific header files (e.g. graphics.) Do I have to obtain the compatible version (which is Borland C++) or are DOS header files available for free? Do freeware compilers exist?

Also does any DOS based application count as a "console application?"

[CODOR]

printz said:
Do freeware compilers exist?

DJGPP. You'll also need the Allegro library for video and sound.

I seem to remember that DJGPP programs don't run so well under NT/2000/XP; unless you're experimenting on a DOS (or Win9x) system, you might be better off using the sources for PrBoom.

[myk]

You can also get the sources for PrBoom v2.02 (plain Boom Windows port) here and WinMBF v2.03 here.

[Hobbs]

if you want to compile boom for DOS you must use DJGPP. Otherwise just change the necessary info to compile in windows

[Quasar]

You'd also need the exact specific version of Allegro that was used for BOOM. The API has changed significantly since then, and BOOM also includes a number of low-level patches to Allegro that it uses to replace otherwise internal specifics of the library. These aren't compatible with the new versions, either. I've had to maintain the original setup used for BOOM (complete with ancient DJGPP version) to keep EE compilable under DOS.

[CODOR]

Quasar said:
I've had to maintain the original setup used for BOOM (complete with ancient DJGPP version) to keep EE compilable under DOS.

So Eternity Engine is still compilable under DOS? What versions of DJGPP and Allegro are needed to do this?

[printz]

Thanks, I'm more interested in DOS Boom's source at the moment because it seems the closest widely available adaptation of Doom.

As for compiling under commercial Windows compilers, I consider I should group the C's and H's into a Visual C++ project... Should I classify this DOS project as a "Win32 Console Application?"

[Quasar]

You'll need to do a great deal of porting before Visual C++ will compile it, but yes, creating a project is the first step. Then you can try to work out the problems one by one. You'll need to immediately factor out all GNU C extensions, which the BOOM team regrettably used as if they were standard C. This includes the 64-bit long long data type, statement expressions [stuff like this: ({...}) ], use of ?: to determine the lvalue of an expression, void pointer arithmetic, writing into string constants, and also any DOS x86 assembly (used in R_DrawColumn, R_DrawSpan, m_fixed.h, and r_things.c, but all easily replaced with C code that has the same functions).

Oh yeah, there's also a call to fclose(NULL) in the MBF version of the DeHackEd parser, so if you end up using that, beware of that too.

d_deh.h will also throw around 3000 warnings. This is due to Ty Halderman leaving line continuance backslashes at the end of all the commented-out strings in that file. You'll need to do away with all of those first off or you won't even be able to find any of the REAL warnings or errors.

[myk]

printz said:
Thanks, I'm more interested in DOS Boom's source at the moment because it seems the closest widely available adaptation of Doom.

Not sure what you mean by that, but Boom is less close to Doom than the current PrBoom or Eternity in many ways (both which support Boom anyway), and is the same as the Windows version of Boom (PrBoom v2.02), except that it's only for outdated OSs (DOS and Windows 9x) and relies of a clunky sound library. While Allegro might have some better later versions, the one used for Boom was lame (and was always one good reason to use Doom instead of Boom whenever possible back when both were popular).