Help,I failed to build the Zdoom/GZdoom source code.

[Delyon]

If this is the case,then have a quick look at my latest illustrated guide on how to build the source code for Zdoom and GZdoom on VC++ 2005 Express Edition. I promise folks ,this is going to be the last one!
http://www.moddb.com/games/doom/tutorials
Merry Christmas.
Au revoir for now!
A.Delyon.

[Csonicgo]

WHat I would like help for is for those who updated their directX libraries. Zdoom is so behind it won't even compile if you have the latest everything.

[Graf Zahl]

Sorry, but there's no help.

Microsoft decided to remove DirectDraw from its SDK but ZDoom still references it. End result: You can't compile. Knowing part of this community's resistance to use modern computers removing this functionality is not an option.

[HavoX]

Graf Zahl said:

Microsoft decided to remove DirectDraw from its SDK but ZDoom still references it. End result: You can't compile. Knowing part of this community's resistance to use modern computers removing this functionality is not an option.

So quite frankly, unless references of DirectDraw and its SDK are removed from the code that is to be compiled, this makes the tutorial irrelevant?

I'm not good at programming, but if I were to compile GZDoom, I'd take OpenGL over DirectX anyday.

[Delyon]

"...this makes the tutorial irrelevant?"
Thank you very much sir!
Que Sera Sera...

[Quasar]

Can't the offending portions of the source be placed inside #ifdef's at least, so that they can be conditionally disabled?

EE can be compiled without OpenGL, for example, by neglecting to define EE_FEATURE_OPENGL in the build script/project file in use.

[Gez]

A long while ago, I mentioned the issue to Randy (private dev forum link).

He mentioned it was apparently still available in some the Windows Platform SDK.

[Delyon]

I simultaneously posted this same thread on the ZDoom forum and so far the response for it has been minimal.
This proves the point about how little interest there is for source coding in the community.
Maybe we should quit source code modding and stick to DECORATE.
Old Confucious once said:"If you cannot beat the DECORATErs at their own game,then get back your paint brush and join them".

[Graf Zahl]

Seriously, who would want to make their project depend on a custom engine? Nearly each time it happened, problems resulted that rendered the mod unplayable in the future.

[Delyon]

Mr.Zahl,Please don't get me wrong about my comments regarding DECORATE, clearly I was just joking.DECORATE is an ingenious way for interfacing the modder to the game C++ codebase. It helped thousands of non- C coders make mods for zdoom with ease whilst isolating them from the complexities of the engine mechanics.The downside is that it ties you to ZDoom and its "siblings".You cannot use it to mod for Risen3d,Doomsday..etc.In addition some modders cannot bear to expose their "brilliant" work to others.Besides source code gives you more freedom and flexibility.However,admittedly the vast majority do not want to mess with classes ,pointers and compilers when they can build excellent mods like Psychophobia with just DECORATE and Notepad.

[Gez]

The thing is that a tutorial for compiling various source ports and modifying them is still a good idea anyway. But, not with the aim of creating a proliferation of forks -- rather, with the aim of helping people fix bugs and implement features so as to later suggest them as patches for the main program.

Like I and many other people did for ZDoom.

[HavoX]

Now that you've mentioned it...

I remember X-Doom making a modified version of ZDoom (ZXDoom) that was made specifically for his mod. I haven't heard from him since like, 2004, which is a damn shame, because I thought it would've been a really cool mod. :(

[Graf Zahl]

And worse, he never released any of his code if I'm not mistaken, so all his work is a total loss now.

[Quasar]

Delyon said:

In addition some modders cannot bear to expose their "brilliant" work to others.

You would probably find that this community is not very friendly to that sentiment at all, considering all extant ports other than Skulltag and ZDaemon are completely open source, with Skulltag playing in that direction, and the vast majority thereof, excluding only ZDoom and its kin, are in addition under the GPL, a license that does not allow closed-source releases. The vast number of problems caused by a closed-source release for a one-time mod are definitely not worth it around here.

[natt]

Quasar said:

You would probably find that this community is not very friendly to that sentiment at all

It's funny that you say that, because a lot of (not Doom) modding communities are the polar opposite. Person writes two and a half lines of trivial code and it's all ORIGINAL DO NOT STEAL

[Quasar]

natt said:

It's funny that you say that, because a lot of (not Doom) modding communities are the polar opposite. Person writes two and a half lines of trivial code and it's all ORIGINAL DO NOT STEAL

Yes I've run into this a few times. It's largely a lot of gorilla-style chest thumping and immature egos at play.

[chungy]

Graf Zahl said:

Microsoft decided to remove DirectDraw from its SDK but ZDoom still references it. End result: You can't compile. Knowing part of this community's resistance to use modern computers removing this functionality is not an option.

How large is that part of the community? IIRC, myk on these forums still uses Windows 98, but that's all that I can think of at the moment. It may be in the best interest of the ZDoom developers to just weigh how important support for such ancient systems is compared to the burden it puts on development, building, and testing... if it's just one or two, I would certainly call it safe to just let it go and require the Windows version to run on only Windows XP or newer. From what it sounds like, depending on DirectDraw is basically creating a barrier from new potential Windows developers from actually compiling the engine. If DirectDraw support only exists for the favor of Windows 98, I certainly wouldn't shed any tears for Win98.

If Windows 98 support is that important, it may be beneficial for some bold developer to make ZDoom buildable under Cygwin+MinGW with all their associated Windows headers, since they do support DirectDraw (and aren't arbitrarily removing it from the SDK); MinGW also doesn't force a dependency on a DLL that can only work on recent versions of Windows. So, just as an example, you can build Chocolate Doom with MinGW and it'll run perfectly well all the way back to Windows 95 and NT 3.51 (it doesn't need any APIs introduced after those versions).

[Csonicgo]

chungy said:

How large is that part of the community? IIRC, myk on these forums still uses Windows 98, but that's all that I can think of at the moment. It may be in the best interest of the ZDoom developers to just weigh how important support for such ancient systems is compared to the burden it puts on development, building, and testing... if it's just one or two, I would certainly call it safe to just let it go and require the Windows version to run on only Windows XP or newer. From what it sounds like, depending on DirectDraw is basically creating a barrier from new potential Windows developers from actually compiling the engine. If DirectDraw support only exists for the favor of Windows 98, I certainly wouldn't shed any tears for Win98.

If Windows 98 support is that important, it may be beneficial for some bold developer to make ZDoom buildable under Cygwin+MinGW with all their associated Windows headers, since they do support DirectDraw (and aren't arbitrarily removing it from the SDK); MinGW also doesn't force a dependency on a DLL that can only work on recent versions of Windows. So, just as an example, you can build Chocolate Doom with MinGW and it'll run perfectly well all the way back to Windows 95 and NT 3.51 (it doesn't need any APIs introduced after those versions).

I would love a Cygwin/mingw32 compile of Zdoom. I still use win95c on my retro box, and would love to throw a more-recent zdoom on there.

[Graf Zahl]

chungy said:

If Windows 98 support is that important, it may be beneficial for some bold developer to make ZDoom buildable under Cygwin+MinGW with all their associated Windows headers, since they do support DirectDraw (and aren't arbitrarily removing it from the SDK); MinGW also doesn't force a dependency on a DLL that can only work on recent versions of Windows.

ZDoom builds perfectly fine with MinGW, no Cygwin nonsense needed.


The official ZDoom should even work with Win95, but no sound. That's because FModEx is incompatible with such old systems.

[Maes]

Heh, and I got complains that building Mocha Doom was hard...yeah, it's really hard running javac against the file with the main() method and letting it do the rest without worrying about any external libraries or path dependencies. As in "GTFO if you can't stand the heat" kind of hard.

[chungy]

Graf Zahl said:

ZDoom builds perfectly fine with MinGW, no Cygwin nonsense needed.

What I said was misleading; I didn't mean to build ZDoom as a Cygwin program specifically, but just to use Cygwin as a build environment (MSYS is quite old and deficient in comparison) for the MinGW version of GCC et al. However you end up building it with MinGW though, it is good news that ZDoom works with it.

BTW, do you know if FmodEx works with Windows 98 or Me? It is a shame it won't work with Windows 95, but for such an ancient system it's not outside the realm of reason. (I've still got Windows Me installed on my Pentium II; it works quite well for games from the era)

[Graf Zahl]

chungy said:

What I said was misleading; I didn't mean to build ZDoom as a Cygwin program specifically, but just to use Cygwin as a build environment (MSYS is quite old and deficient in comparison) for the MinGW version of GCC et al. However you end up building it with MinGW though, it is good news that ZDoom works with it.

I don't use either. The MinGW version I use doesn't require either. I once used CMake to create the makefiles and now it just works - although the executable is 1.5 times as large as a MSVC version.

[chungy]

Did you run strip on the executable?

[Graf Zahl]

Yes, of course. Extensive use of C++ features with GCC seems to create somewhat bloated binaries