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.
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.
- Windows build is now built with Visual Studio 2015 fixing issue with the 64-bit builds crashing on some Haswell systems.
- 32-bit Windows build is now done with SDL 2.0. Windows 98/Me/NT4/2000 support is now relegated to a special build for legacy systems. Until ECWolf 1.5 these will remain first class supported operating systems.
- The GOG versions of Wolf3D and Spear are now detected automatically if installed.
- Font system updated from ZDoom to support graceful handling of accent marks.
- Implemented missing secret god mode cheat (TAB+G+F10 for Spear and JIM for Noah)
- Removed console window on Windows since it was blocking Steam broadcasting (use --console to get it back for mod debugging)
- Removed F12 to release mouse capture since it got in the way with default Steam binding. Use scroll lock instead.
- Elevators force close their doors to prevent them from being jammed by corpses rendering levels unbeatable.
- Redefining an intermission sequence (such as the demo loop) now properly replaces the old one instead of appending.
- ECWolf now handles the special case of ChaosEdit reusing plane 2 for plane 3's data if the map doesn't use plane 3.
- Fixed hint on question 62 in S3DNA.
- Fixed wrong ceiling color in floor 8 of Spear.
- Fixed wrong par time on E6L8 of Wolf3D.
- Fixed timing errors in S3DNA hand feeding and small feed launcher.
- Fixed missing death sound on some enemies in the Spear of Destiny mission pack secret levels.
- Fixed issue with animated textures pausing if menus were entered for a significant amount of time.
- Fixed missing sounds at the destination point of an elevator.
- Fixed loss of inventory on level transition after loading a saved game.
- Fixed dropped data when loading embedded data files in zips.
- Fixed crash with saves with active elevators.
- Fixed immediate crash on Android.
- Fixed various other crashes.
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.