News
New server plus some odds and ends 2018-02-04 06:58:52
I have finally purchased my own hosting and moved this site off MancuNET. MancuNET has been great for the last 5 years, but between having a full time job and all the sales of S3DNA I figured it was quite silly to be using someone elses resources. Plus I started using Matrix and due to some complexities in regards to SSL certs running things myself just proved to be easier. (For those who aren't aware of Matrix, it's a fully open and federated communication platform. Similar to Discord or Slack in feature set, just 100% open.)
While not really related, I also decided to move ECWolf's repositories over to a Bitbucket team. When I initially move ECWolf from SVN over to Merurial Bitbucket didn't have the teams feature so I had the repo under my name. While I'm still largely the sole contributor to ECWolf I still figured it's better to get the transition out of the way. The big benefit is that all the ECWolf related repos are more discoverable since they won't get buried under any other projects I may be working on. The downside is everyone needs to update their clones to point to the new location.
ECWolf also has a new logo/icon courtesy of NeuralStunner. The hope here is that the new icon still feels related to Wolfenstein while being freely licensable.
Suppose this is as good of time as any to formally talk about my plans for ECWolf 1.4. I think it's clear as day to anyone that I perhaps scoped too much into the 1.4 release. At least these days where I don't have quite as much time to work on hobby programming as I used to. In order to narrow the focus I have decided to drop Mac Wolfenstein support from the 1.4 goals. To be clear this means nothing long term as ECWolf will get Mac Wolf support, but I personally would rather focus on finishing the initial multiplayer code for 1.4.
On the topic of refocusing, I would like to formally say what everyone else has no doubt figured out before me: I no longer have time to actively participate in GZDoom/Zandronum development. I know, real shocker here but making this formal really does lift a lot mentally. I've definitely thought way too much about the shared code in ECWolf since at this point my contribution rate really is that of any other third party contributor. I will of course still be doing the builds that I have been doing so this really is just a statement for my own sake since as far as everyone else is concerned things are continuing as normal.
Now while things have been quite slow, things haven't been exactly dormant over the last year either. A few months ago I had a random epiphany that adding more Z height support would actually be quite easy to do, so now ECWolf can render things at varying heights. Admittedly it's not especially useful right now, but its a step in the right direction and it makes for more interesting screen shots than the feature actually is.
Sorry for the lack of content here in 2017. Last year has been the year of projects that get stopped just before their complete for one reason or another. I wanted to write about the video capture card I bought, but then I discovered my computer was bottlenecking its capabilities so it wouldn't be fair to the reader to speculate. I had hoped to write about my over the top retro computing build, but that still has a lot of small details to finish out. I finally purchased a new primary computer and the fun story I planned to write in regards to that got delayed by early adopter issues. For those wondering I'm now running a Threadripper 1950X. Quite an amazing system for development and brings my ECWolf compile times down to 2 seconds. Not that they were particularly long before, but even everything else I work on now has negligible compile times compared to the Lynnfield/Nehalem system I had before. So glad to finally be beyond quad core processors!
Oh and I also now own ecwolf.org which redirects to any page in the ecwolf section of this site. Don't have any immediate plans to host the site under the domain.
A thought on Intel Kaby Lake 2017-01-14 01:40:32
One of the weird things I do to pass time is study the entire range of x86 CPUs available for purchase. Often when I hear people talking about processors I only ever hear about the the Intel Core i5 or i7 with the occasional budget build using the Core i3. There was of course the unlocked Pentium G3258 while that was current, and that was interesting to me for a reason that I don't think I've ever heard anyone talk about.
Specifically what interests me most about Intel's low end (Celeron, Pentium, and Core i3 although only Haswell and Skylake there) is that it has traditionally had ECC memory support, which is normally only associated with the Xeon processors. My best guess as to why is that the SKUs are low enough volume for server use that it doesn't make sense to separate them, but I could be completely off there. This fact turned out to be convenient for my brother who upgraded to a Celeron G1850 (Haswell) for a little while until I was able to help him acquire a Xeon E3 1285Lv4 (sometimes you just need a CPU you can't just buy on Newegg). The latter being a very interesting SKU since it has a lower TDP than the normal 1285 and benchmarks the same if not slightly better for some reason. (My guess here is that the normal 1285 would benchmark faster in cases where both the Iris GPU and the CPU cores are utilized at the same time.) It has a slightly higher stock clock than the Broadwell i7 and according to Intel Ark has a faster memory controller although probably due to the obscurity no motherboard I can find supports the faster memory clock and ASRock Rack apparently had no interest in talking to me about it. Of course overclocking could close this gap, but the i7 doesn't have ECC. For those that may be wondering, the Celeron offered a better experience than the unfortunately water damaged (but still working thanks to ECC) dual Opteron 285 workstation that he had before. Don't have hard numbers on that transition, but games were noticeably smoother on the Celeron, and the Xeon was a vast improvement over that.
But this post wasn't about Broadwell, with Kaby Lake we see an unlocked i3 being released. At first I was pretty excited about this since based on Skylake this would have had ECC support and overclocking (like the Pentium G3258 apparently does). Alas though it appears that Intel has decided that ECC on the low end should be no more. At least if Ark is to be believed. Quite disappointing, but of course it doesn't matter much since I don't think any ECC supporting board allowed overclocking (since it would have required using the server C series chipsets).
What we also see this generation is that the Pentium is now shipping with hyperthreading enabled. This would seem at first to really blur the line between the Pentium and i3 seeing as for whatever reason Intel drops the cache down to 3MB on the i3-7100. Many people will probably forget to mention, or at least not notice, that the i3 does have one feature over the Pentium/Celeron lines and that is AVX instruction support. This won't make a whole lot of difference in the near term since I think the only place users are likely to encounter AVX at the moment is with compression, but I suppose in the future it could become a problem as I'm hearing some people are having trouble today with their Phenom IIs not having SSSE3 instructions. I'm guessing those buying a Pentium or Celeron don't plan on hanging onto the machine as long though.
Not that I have any plans to buy a Kaby Lake system, just felt like writing about some things I found amusing. Personally I'm hoping that AMD's Ryzen lives up to their claims and more specifically that Naples (Q2) is everything that we think it is. Definitely think I'm ready to move on from quad core CPUs.
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.