Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
doombringa

Building Doom Legacy with VC6

Recommended Posts

Hello everybody,

I tried to build the Doom Legacy 1.42 sources with Visual Studio C++ 6.0, but I'm having some probs. I'm not yet familiar with Visual Studio as I've only used MinGW so far, so I guess I'm just missing something simple here. This is what I do:


-when I select "Open Workspace" and choose wLegacy.dsw, nothing happens
-when I open the wLegacy.dsp file directly, I get the following message in which I click "yes"



-after that I get this one, I continue with "ok"



-now it prompts me to save a wLegacy1.dsp file, which I do
-the workspace opens up and I choose "Export Makefile"

-but then nothing happens, Visual Studio doesn't seem to create the .mak file (at least not in the folder where the .dsp file resides)


Btw these are the two dsp files I'm talking about :
http://www.filedump.net/dumped/wlegacy1266005826.txt
http://www.filedump.net/dumped/wlegacy11266005884.txt


Does anyone know where the problem lies?

Share this post


Link to post

If you read the wLegacy.dsp I linked it says:

CFG=DoomLegacy - Win32 Debug
!MESSAGE This is not a valid makefile. To build this project using NMAKE,
!MESSAGE use the Export Makefile command and run
!MESSAGE 
!MESSAGE NMAKE /f "wLegacy.mak".
!MESSAGE 
!MESSAGE You can specify a configuration when running NMAKE
!MESSAGE by defining the macro CFG on the command line. For example:
!MESSAGE 
!MESSAGE NMAKE /f "wLegacy.mak" CFG="DoomLegacy - Win32 Debug"
!MESSAGE 
!MESSAGE Possible choices for configuration are:
!MESSAGE 
!MESSAGE "DoomLegacy - Win32 Release" (based on "Win32 (x86) Application")
!MESSAGE "DoomLegacy - Win32 Debug" (based on "Win32 (x86) Application")
!MESSAGE 
And when I click build I get this error:
--------------------Configuration: wLegacy1 - Win32 Debug--------------------
Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
NMAKE : fatal error U1052: file 'wLegacy.mak' not found
Stop.
Error executing NMAKE.

wLegacy1.exe - 1 error(s), 0 warning(s)

Share this post


Link to post

AFAIK Legacy cannot be built with MSVC. Many years ago the (long gone) developers of the port at that time decided that in order to protest Windows XP's registration they a) would not officially support this OS and b) would not support MS's compiler anymore.

The project file that comes with 1.42 is not usable. I was never able to build the executable with it, let alone load it with any MSVC version from 6.0 up.

And the more recent 2.0 code does not even bother anymore with an MSVC project. It's MinGW only.

Why would you even want to? Legacy 1.42 is 6 years old and horrendously obsolete. Of all exising source ports it's probably the one people should not bother using anymore for anything.

Share this post


Link to post

@Graf Zahl:
So it is not meant to be build it on Windows even though they included a VC6 project file? This is really weird, because the remood project file looks similar, and that almost compiles with VC6 (gives hundreds of warnings and only a few errors). I guess I would have to build the Windows version on Linux then, or does Doom Legacy compile with MinGW?

Graf Zahl said:
Why would you even want to? Legacy 1.42 is 6 years old and horrendously obsolete. Of all exising source ports it's probably the one people should not bother using anymore for anything. [/B]

I wanted to write a hack for Doom and I figured it might be best to get a basic understanding of the source code first. So I started with modifying Chocolate Doom, because that is probably the most "uncluttered" engine and damn easy to build (only needs SDL). After looking at the source and taking notes, I was able to get a protoype running in a few hours, sadly it didn't work that well.

At this point it might be a good idea to briefly explain what kind of hack it is. I always wanted to know what it would be like to play an FPS with a lightgun, and Doom seems to be the perfect candidate to try that out. So I deactivated mouse centering and movement, grabbed the mouse position, and changed a few functions to allow shooting at the direction you're pointing at. It wasn't perfect (I have problems calculating the correct bullet slope, maybe due to the software renderers nonexistent perspective correction), but good enough to hook up my Lightgun and try. Sad thing is, it doesn't work in fullscreen mode and it's not much fun in a 320x200 pixel sized window. So now I'm trying to compile other engines and see if I have more luck.

Doom Legacy seemed like a logical next step, because Doom Wiki lists OpenGL in addition to a software renderer, and I could just port my hack over quickly, as the source ocde is pretty similar to that of Chocolate Doom (it looks like the original Doom C sources with only a few additions here and there). But now that it's giving me so much trouble, I may skip it and try GLBoom+, Vavoom or GZDoom. (Which I think you are the writer of? Nice job.) GZDoom isn't higher up on my list, because it seems to be a complete rewrite in C++ with tons of added features, which could make understanding the source harder. I also didn't find a tutorial on how to compile under Windows, but I guess I could use the one on the ZDoom Wiki as a guidance.


@Gez:
Yes that is a good idea, but as said remood is giving me errors (probably nothing that couldn't be fixed), the music either doesn't play at all (08a) or too fast (1027), and according to Doom Wiki it seems to have dropped the OpenGL renderer?

Share this post


Link to post

If you want to do GL tests, PrBoom (GLBoom) is clearly the best option. It comes with a MSVC project file and of all GL renderers is by far the most simple one. Legacy by comparison is quite messy (as is the whole port...)

I'd recommend using GlBoom+ though. It's probably the best mixture of simple GL renderer and usable code for your purposes.

Share this post


Link to post
doombringa said:

I also didn't find a tutorial on how to compile under Windows, but I guess I could use the one on the ZDoom Wiki as a guidance.

There is only one difference between compiling ZDoom and compiling GZDoom, and that difference is making sure your compiler can find a couple of OpenGL headers. The wiki does explain all that.

However, the project files are for VC++2005, which is 8.0; not VC6. Granted, it might work anyway if you just edit the project files to change the version. I know it has worked so far for me with all VC9 project files I've encountered.

Share this post


Link to post

Sorry, but that won't work for 2 reasons:

First, the project files are incompatible. VC 7.0 (2003) changed the format.
And second, VC++ 6.0 severely lacks C++ standard compliance. The compiler simply cannot handle ZDoom's code anymore.

But considering that MSVC 2008 can be downloaded for free as Express edtition that really shouldn't be a problem.

Share this post


Link to post
Graf Zahl said:

But considering that MSVC 2008 can be downloaded for free as Express edtition that really shouldn't be a problem.

I don't like MSVC 2008 since you have to register for MS Live to use it. MSVC 2005 doesn't do that.

Share this post


Link to post
Graf Zahl said:

Good luck finding MSVC 2005 anywhere (and registering it...)


There's no need to register the express edition; contrarily to MSVC 2008. Also, while they pulled out the online installer, the ISO for it can still be downloaded from microsoft.com.

Share this post


Link to post

Well, I would've tried to follow the ZDoom instructions on how to compile with MinGW, or is that not a possibility with GZDoom?

Share this post


Link to post
doombringa said:

Well, I would've tried to follow the ZDoom instructions on how to compile with MinGW, or is that not a possibility with GZDoom?

Same thing: so long as the glext.h and wglext.h headers are somewhere where the compiler will find them, it should work.

However, the MinGW part of compiling ZDoom on Windows is quite not exactly well maintained... I'm not sure getting old DirectX 8 headers, instead of a recent Direct X SDK, is a good idea, for example.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×