Try to Compile Doom Legacy for DOS

Well, if Borland is compiling to RealMode, I won't have much use for it.   Pity, as that was the one compiler that I actually bought as a Boxed Set, with manuals and everything.

The manuals were of some use over the years.

I think it was legacy.dat already and changed to legacy.wad almost immediately around SVN 544.  The patches at SVN 594 are the important ones.  But I cannot think of any reason those would affect a DOS compile differently.  The SVN 595 patch just fixed the table lookups so they did not read outside the array bounds.

That was around the time we started switching to using uint32_t and the like from stdint.

Specifically, make sure that uintptr_t is being translated to a reasonable type for the compiler and machine that you are using, so check your stdint header.

The uintptr_t is compiler and machine dependent.  It was first used in SVN 593.

The whole stdint.h is machine and compiler dependent, so you cannot just use any stdint header.

Good Morning, Sir.

Yes, at some point there will come a time when these old things are obsolete. Ironically, even when programming for an "old" system. :). Take it easy, I also have complete booxed sets for Amiga (complete assembler packs). :)

Yes, the stdint.h under DJGPP looks good. I guess that's my fault. I didn't have an Arch type in the makefile and I still had the specs file from DJGPP. At some point I changed the arch type because the commando of gcc regarding the Cpu type had changed. I deleted the specs file and set the -march = type to i468 in combination with -mtune = i586.

I let Doom run for a few hours earlier and also played a few maps myself. No freeze.

I'm at commit r682. Had to change the Colourmaps and Transmap at tmap.nas and compiled. Furthermore the #include <stdlib.h> in m_fixed.h - For DOS must be included, not only for Linux. Otherwise gives implicite abs warning.

As I said, I'm a noob in things but can now play wonderfully. :)

O o ... Im now at Commit 700. damn it. With the commit from 700 you have apparently completely removed the support for buttons and joystick under DJGPP/DOS because SDL . Will that be corrected in the upcoming commits?

Edit: Ok, i see .. ui ..  at commit 1065 it has been changed ..

The Commit 714 "Backported SDL joystick code from Legacy2" make me crazy. 

https://sourceforge.net/p/doomlegacy/svn/714/tree/

From here on all joystick types and other definitions for DOS have been removed. E.g. cv_usejoystick.value and other definitions still exist in the latest version for DOS, which were removed at the time. What would be the better approach if I want to compile the commit 714 but don't want to leave the commit path because the m_menu.c and other main sources are constantly being touched and changed?

Those are patches, SVN 699 to SVN 714, are by Smite-meister.

As legacy2 only supports SDL, the backported joystick code did not have provisions for DOS selections.

About the time that I joined, the team had somewhat decided to only support SDL officially (due to the difficulty of supporting so many ports with so few people).

However the other port code was still around.

I have tried to fix the other ports to match the SDL port.

The SDL port is still the main port, and other ports have to be adapted to work with the interface that it uses.

There are so very few users of the other source ports now, that support for the other ports is secondary.

I suggest you put back into your copy whatever you need for DOS, and put conditionals around it.

#ifdef SMIF_PC_DOS
// DOS code

#endif

You can take the code directly from the SVN 714 patch.

When you paste a line from a patch, delete the first character (usually a + or -, but sometimes a space).

Use a diff utility to make a patch from your fixes to 714 vrs the SVN code, and then apply your patch to all later versions that you intend to compile, to carry forward your fixes.

If you keep working your way up the history tree like that, you are going to accumulate a large number of patches, so you might as well automate applying them.

As there are over a thousand of those SVN revisions, you may want to take larger steps.

Later when I get your patch file, I can try to incorporate that into the latest version.

I will of course, change it entirely to fit with our current code organization and interfaces at that time, so it is not necessary to figure that out yourself.

I am sorta hoping an up to date Legacy 2 binary can be provided. The ones that ExL compiled are from 2007, it could be interesting to have one that contains the most up to date code.

That per pixel lighting is just too fancy to not show off.

I have not worked on legacy2.  It is C++, uses oxygen, and gcc indentation style.

The oxygen is annoying, the gcc indentation style does not agree with me, and C++ applied to a C program

is like art-work with the clash of styles.  The total reorganization makes it difficult to check code with PrBoom.

I cannot find anything in that code.

Legacy1 has accumulated over 1000 patches, many fixes and new capabilities, that have not been applied to legacy2.

Legacy2 has Hexen, which I may copy over into Legacy1.

Legacy2 needs a volunteer who is compatible with it.  I am getting backlogged on so many projects now that I cannot see how that ever will be me.