Blzut3's Weblog

Weblog ECWolf ECWolf Wiki

ZDoom ceases development 2017-01-08 09:23:03

Randi has announced the end of ZDoom development, in a move that is somehow expected and unexpected at the same time. I do wish that Randi was more open, as I would love to know what all led up to the decision instead of speculating. In the end though this does ultimately mean a lot of good for ZDoom, or perhaps more correctly its children, even if it's not the outcome we wanted to hear.

There is no doubt at all that ZDoom has played a very large role in my life. Not just because I've been a user for more of my life than I have not, but it was the reason I transitioned into writing C++ code, and the first established open source project I've contributed to. More than anything it gave me the experience that I needed in order to be far ahead during college, which in turn led to many great experiences working with Dr. Andrew Sutton. I do not think it is a stretch to say that ZDoom is a large part of the reason that I've been able to participate in the ISO C++ committee meeting in 2014 and landing the job that I have now. Given how long the project has been around, I'm sure I'm not the only person in the community that can say something to this effect. It is kind of funny to think how what might appear on the surface to be just a silly hobby project can turn out to have a real positive impact on the lives of people.

One thing that always impressed me when reflecting on ZDoom is how well it has thrived considering its lack of structured leadership. Even when I became a proper developer for the project, there was no formal communication channel between contributors. Randi, Graf, and I pretty much added whatever we felt like adding and somehow even in this anarchistic environment some fairly unified grand vision of what ZDoom was came through. I make that sound more glorious than it actually is, but when you think of a bunch of people doing whatever they want a stable product doesn't usually come to mind and yet that is what ZDoom usually was. You definitely don't think of a project where people ask for other projects with the same philosophy for other games. A discussion forum for developers and other key members of the community was opened later as inevitably as things grow more communication is necessary, and grow ZDoom did.

One thing that people often don't realize when it comes to open source software is that being open source doesn't mean that people will contribute to a project. That is to say, if you expect that you can start a project on GitHub and you'll eventually start getting people sending in code submission then you'll be quite disappointed. Popularity obviously has something to do with this, but popularity doesn't necessarily imply more contributors. Most projects only have one developer so having two or three would be considered a very successful project. ZDoom did more than that though, after we switched to DVCS the floodgates opened and ZDoom reached a point where it could feasibly became entirely community maintained (with those with write access just pushing code around). It wouldn't be pretty, but it could have been done and that is an outstanding achievement for an open source project.

ZDoom had been growing so well that ultimately the persistent problem became to be a lack of commenting on important issues from the only person that can actually make the arbitrary decisions. Unlike Skulltag which had a problem of a desire of too much control by an otherwise disengaged leader, with ZDoom we would constantly be left with unanswered questions. Most importantly in my opinion was no guidance on releases which really required nothing more than dropping by every few months to take a snapshot. Something needed to be done about this and Randi apparently chose to just let it go. Given how much time my back burner project occupy my mind I can't imagine this was an easy decision to make, but it needed to be done.

Effectively this makes Graf Zahl and GZDoom the new supreme leader, which kind of alienates me a tiny bit. One of the things I derive fun from is toying with old hardware and to that end my development stack consists of a retro PowerMac G4 and Pentium 3 running Windows 98. Even currently trying to build a dual Tualatin for running NT 4.0 on hardware. I know that Graf finds targeting these systems to be entirely pointless, and previously I had agreed that GZDoom targetting these platforms was pointless. With it being the root I'm left wondering what this means. Currently there's not much stopping unofficial builds of GZDoom running the software renderer on legacy systems, but if the philosophy stops being "if it doesn't hold anything back, go for it" then it could be problematic. Removing the DirectDraw code might seem worthwhile for example even though I don't think its a big deal keeping around.

It is perhaps not unreasonable to consider that this may be the excuse I need to make my exit from coding for Doom. Since I got a full time job I haven't had time for everything that I want to work on. This is a good problem in my mind since I'm never bored, but I can imagine in recent times I'm gaining a reputation for promising the world and delivering on nothing. Having less on the mind would certainly alleviate the issue, but I don't know. I wouldn't ever truly be gone since I still have the auto builds and the code sharing with ECWolf. That's really what makes it harder than anything else, if ECWolf is using (G)ZDoom components then I potentially put myself at the mercy of unfavorable decisions on those components if not directly involved to some extent. (Again going back to platform support I can only support in ECWolf a subset of what the libraries support.)

In any case though I'm excited to see how things unfold with the artificial barriers lifted. The previous key features of GZDoom and QZDoom didn't interest me since in my opinion the only way to play Doom is with the Carmack renderer, but as long as that remains an option GZDoom (the future merged GZDoom/QZDoom version) will likely remain my port of choice.

WDC 1.17.388 with ECWolf support 2016-11-01 04:31:08

Adam Biser announced WDC 1.17.388 today which has the ability to export to a WAD/PK3/PK7 for ECWolf. This is an export only feature but it should help bridge the gap in knowledge between vanilla Wolf editing and ECWolf editing.

ECWolf 1.3.3 Released 2016-10-01 18:47:47

After a lot of unnecessary hesitation and delay, I'm announcing the availability of ECWolf 1.3.3. Please note that this is just a patch release, but it includes a lot of critical fixes that I really should have made available months ago. I only have myself to blame for the delay though as it has gotten to the point where I don't really even recall why I've been delaying. (I guess I'll find out soon enough though!) I do expect that this will be the last patch release for the 1.3 series unless something critical requires an immediate fix.

As the font system upgrade would suggest, I was planning on improving translation support for this release, but time constraints are putting a damper on that for this round. So "Hyeron" if you're reading this update, I haven't forgotten about your translation submission and am still planning on integrating that.

Discuss on the forum

The road to modern C++ 2016-02-29 02:08:12

A few weeks ago ZDoom 2.8 was released. The release was prompted by both the desire to merge Randi's scripting work, the wall portals submission, as well as general interest in making linked portals work. In other words the code base is going through major changes going forward so it made sense to cut a release. With it we have finally decided that it was time to move onto using C++11/14.

Both ZDoom and ECWolf have been using Visual Studio 2005 as the primary compiler for Windows. There were a few reasons for this but much of it was because newer versions of Visual Studio dropped support for newer operating systems. So far, throughout the life of the ZDoom project, the only platforms that we have dropped was Windows 95 and DOS (DOS support went away fairly early on). Even though VS2005 doesn't officially support targeting 95, ZDoom had a hack for awhile to make it work, but support broke for unrelated reasons that went unnoticed for a long time. Some people have been pretty critical of the fact that Windows 9x was still a supported platform, but, besides offering a better user experience, one of the advantage of rolling our own platform abstraction layer with native back ends is that there was never really any pressing reason to drop support for the old platforms. The DirectDraw code works just as well now as it did back then with little maintenance needed, so for the most part the only difference supporting 9x makes is that a few more Windows API calls need to be made optional by resolving the symbols at run time. A task which thanks to C++ templates can be made fairly unobtrusive and with C++11 can be made nearly transparent. (Vista also expanded the Win32 API significantly enough that we have a few cases where this needs to be done for XP as well.)

Times do eventually change though for even the most stubborn people. FMOD Ex unintentionally dropped compatibility for pre-XP systems (asked about it in an email and Firelight wasn't really aware that they dropped the platforms when they switched to using the VS2010 compilers) and it has been deprecated in favor of FMOD Studio. Even though ZDoom does have the ability to be compiled with OpenAL now, FMOD remains the only first class sound back end so our days of being able to use the preferred middleware and continue to run on the older operating systems is drawing to a close. To put it another way, it is only know that supporting old operating system is actually becoming a problem for us.

The question that I'm trying to answer here is "what does this mean for ECWolf?" Obviously I want to continue to share code with ZDoom so this does mean that ECWolf will need to make the jump as well. Windows 98 machines are more common in the Wolf3D community due to compatibility with DOS mods, but it is clear that keeping 9x as a first class citizen is going to be a problem going forward. Thus ECWolf 1.4.x will be the last series to do so and starting with 1.5 a C++11/14 compiler will be required.

Of course this doesn't spell the end of either ECWolf nor ZDoom on these older platforms. It is possible to compile C++14 programs for them using MinGW (vanilla MinGW as mingw-w64 requires XP or later as well), and so I will at least be providing a version of ECWolf for legacy systems until further notice. This actually is something I was debating doing regardless for awhile now as 32-bit users could benefit from SDL2 regardless, but this makes the decision easier. There are multiple factors on if ZDoom will as well that I can't predict right now, but it will possible for some time to roll 9x compatible binaries with a properly configured compiler. One thing is for sure though, due to some quirks with MinGW these binaries will not be able to provide nearly the same experience as the VS ones (delay loaded libraries and exception interoperability being notable missing features).

For the two people still using PowerPC Macs, I don't believe there's anything to worry about. GCC 5.3 seems to work just fine on them so I believe I can still provide binaries. There are some quirks with using a new compiler such as structures getting extra padding on the ends which breaks some file IO code that utilizes commonly exploited undefined behavior as well as a bug with C++ exceptions in Objective-C++ code (it's in the GCC bug tracker, but don't have a link on hand). These are fairly trivial issues to work around though. For ZDoom, however, providing binaries will depend on how long FMOD Ex is supported in ZDoom. Once that is dropped then PowerPC ZDoom binaries will only be available through unofficial channels thanks to OpenAL. (On a related note to pre-XP being dropped in FMOD Ex, I think G3 processor support got dropped accidentally in the 4.24 series as the fact that Apple's gcc-4.2 forces targeting the G4 or later is not well documented. Of course compiling your own GCC allows you to target the G3.)

« 1 2 3 4 5 6 720 21 »


© 2004-2018 Braden "Blzut3" Obrzut