Quasar

Most of the big names of that era are gone now, yes. Significant turn over both after 2016 wrapped, and then especially after Eternal.

If I'd had any sway or influence you'd get the whole slate of PSX features in there somewhere, including nightmare monsters :)

I have offered hard facts - the impetus for and design of ID24 as a spec does not extend past Nightdive. The onus to explain how adopting the standard will somehow cause a backdraft onto ports in the future is on the people making that assertion.

Given demo compatibility with Doom + Doom II is not a goal, I don't believe there's any expectation that Boom/MBF complevels should get retroactively broken. The unfortunate reality will just be that mods would need to work around the differences if they want to run properly on the official port. Even in the best case scenario I doubt ALL the divergences will get fixed.

I was previously a Source Port forum moderator; the title was set by the old board system. I was also moderator of the Eternity Engine forum.

So what? If you are about to impugn my character I suggest you view my history of involvement with and investment into the community first and consider where you're going.

Weird that you think it was anyone in the community's initial idea. Do you believe Nightdive just developed a new version of Doom on its own volition without a contract in place? NDS was approached by id Software who wanted to do a 30-year-anniversary version of Doom, that's how this project started. Their eye is always on Doom and its community whether you somehow distort that into a bad thing or not, because we made them what they are today. You want to tell me how I should look at id when I'm the one with inside experience having worked with them on Doom 64, Quake, Quake II, and projects you haven't even heard about and will never hear about. The people i've worked with have been good people trying to do some things that will be fun for the community - and yes that was the motivation behind their idea of having a mod uploader. It is a shame that the implementation hasn't had enough time put into it before the QC deadline to avoid the problems that have resulted - Issues were definitely raised by the development team about how some of the things would work but time constraints and inertia prevented them from getting addressed satisfactorily - but that has nothing to do with ID24 at all. It doesn't interact with the standard, it isn't contingent on it, it doesn't even benefit from it since regular vanilla, Boom/MBF, and MBF21 mods work fine as-is and will always be the bulk of material available. Also the mod upload system is a cost sink, not a source of profit. It was began as a "this would be cool" idea by the guys at id. It was then OK'd by Bethesda in the boring business world on the basis that it would make a good promotion for the re-launch and that hopefully that would help recoup development costs by pushing more units. And that's it. The nefarious elements are in peoples' heads. It's a distraction from this thread's topic.

Nobody at Bethesda or Microsoft even had any involvement with the spec, or even basic knowledge of it beyond "we're going to release this technical info, please OK the release". If you were to show its contents to anyone at either company, they wouldn't have a clue what's in it. Because that's not how corporations work except in cartoons and 80's action movies - you don't take every minute technical detail to the top for approval. When you're hired to do a thing, you do it in a way that involves trust to execute your basic competencies. If things worked otherwise, the entirety of every company under the MS/Xbox umbrella would grind to a halt tomorrow waiting on the CEO to tell twenty thousand people exactly what to do. The decision to implement the spec and the details of its implementation were entirely handled within the team at Nightdive, with GooberMan as a contractor, and with our id contact in tow / on-board with it. There is no conspiracy. It is a complete waste of everyone's time and nobody here has even managed to spell out a single possible actual negative thing that could result from adopting ID24 as an extension to the existing standards.

While it's certainly vague, it's believed generally that this is saying you shouldn't be distributing the game's IWAD or executable files, as those are the data acted on by tools. It wasn't their intent to shut down non-commercial mod distribution. They were however known to be upset at the time about things like DeHackEd back when it effectively only generated a modified EXE and people were distributing them whole. Once it transferred to text-format patches that became something less (albeit not "nothing") of a concern.

There really was not that much new in terms of mechanics or monsters shown off, it was more a matter of the scale of the game being more fully revealed. The gameplay reveal portion took the Slayer into a seemingly vast area that just had demons crawling out of every crevice and dotted around the landscape. This was way bigger and more open than anything from 2016 or Eternal. They said more will come soon as far as outlining the monsters that are in the game so I'm looking forward to that.

Yes it's mentioned, follow the genealogy links at the bottom of each page. You seem to be conflating "renderer" with "game engine" by the way. The renderer used in the Kex port is entirely new, written by GooberMan. It uses a multithreaded architecture to paint the screen in multiple horizontal zones in parallel, which is the only way to get acceptable performance at 4K while still maintaining a software renderer. The game code is still 90% the same as the previous Doom Classic based on Unity. The additions to game code since the Unity version are largely to bring in the Boom/MBF compat.

Completely accurate. The Doom code integrated with Kex is the Vicarious Visions / Nerve Software branch which originated from the Linux Doom source, the same one used for all previous builds of Doom Classic and other console builds of Doom.

Heretic II. Cool game. Shame the source was never released, though, because it is rapidly accumulating problems when running on modern systems. To spare anybody else interested in it from searching the web in vain for hours trying to find a solution to one of them, I will document it here. If you start up the program in OpenGL mode on pretty much anything newer than a Voodoo or a Rage Pro, it will crash. The crash is a common idTech 2 issue and results from Carmack's incessant use of sprintf() on fixed-size buffers - it tries to read in the OpenGL extensions string at startup just to show it to the user, but on modern cards this string is way longer than they anticipated. To fix this, open ref_gl.dll in a hex editor of your choice and find the string "GL_EXTENSIONS: %s". Change the %s to "xx" or any two other characters not including a %. This will disable sprintf from accessing the too-large string passed to it. Unfortunately the music also won't loop in Windows 7, which is a ANOTHER bug in the MCI API on that platform. I don't have a solution for this one yet.

Having an id range in the standard is a promise to the community that id will NOT use anything OUTSIDE that range, meaning that community ports are suddenly assured that official content, if any new content as such is ever created (which for some reason is being treated as an inevitability here that leads to a slippery slope of dozens of new mobj types per year apparently, while back in non-5G-gives-you-cooties reality it's happened ONE time in the last 30 years), will not conflict with ports' usual work. Any other interpretation is either willful ignorance or willful malevolence.

If I wanted to test any waters I'd just return to developing Eternity and do so without regard to community standards, like what seems to be the modus operandi of most other ports these days. That would be a far more effective method of being potentially disruptive than a one-time development on the official version would ever be, at least if people actually started using said features. The conspiratorial thinking required to go from the ACTUAL motivation of folks at id Software, which was "we should do a 30-year anniversary version of Doom, here's what it would be cool to have in it: ..." to "they are scheming to take over the modding community and control everything" is dumbfounding.

Earlier id efforts like No Rest for the Living were developed without any eye whatsoever toward interop with community specs or existing ways of doing things. Painting the open release of a compatible standard extension as being somehow dubious seems disingenuous to me. Are we angry that we didn't have to meticulously reverse engineer the new port's binary to figure out how everything was implemented? That was the old-school situation, such as when I had to figure out Nerve's file formats and MAPINFO-like system. There's not a world where the release of LoR wasn't happening, so, to the objectors, how would you rather have had it? What are any specific objections to the way things are implemented? I'd also say feel free to just ignore it if you want. The standard is a suggestion for ports that want to be able to support the new content. Such a thing cannot be imposed on anyone. If you're more interested in community politics or ego contests than running game content, then just tell your users they have to use a different source port to play it. That seems counterproductive in terms of maintaining an audience, to me, though.

It used to be that time to crate was the interesting metric for new releases; now it's time to somebody whining about your mod not working in GZDoom.

Most level values are already extended to unsigned in advanced ports anyways because this is how we support larger levels. You can't have a negative sector or sidedef offset in Eternity in a binary map because those values are treated as unsigned anyways. So the debate over whether to extend or not is moot in those points for most implementations at this point. Otherwise, I'd also argue that you can always also add a sanity check for excessive size, whether or not the values are signed or unsigned. What valid use case do community tools have for negatively sized images for example? Either you're going to do if(w <= 0 || h <= 0) invalid; or you're going to do if(w * h > SANITY_THRESHOLD) invalid; - I see no difference except the latter lets you support reasonably larger images and the former does not.

I think I mentioned this on the forums here a very long time ago but, I've been working on a piece of music off and on for almost 30 years called "Les sons de l'été" (which is French for "The Sounds of Summer"). It's a roughly sonata-form piece for a large, but sub-orchestral, chamber ensemble: Vibraphone soloist Flute soloist Piano Strings SATB chorus + boy soprano Extensive use of percussion (idiophone ensemble, timpani, aux, drum kit, etc) It's finally relatively close to being finished after a huge push I've been doing on it since around 2018, at which time I also started dedicating a lot of time to sharpening up my skills and just getting more proficient at putting down the actual ideas I hear in my head. I've just been absorbing anything and everything to do with compositional theory and practice and I guess it paid off a bit (having MuseScore available helped too). Below is my playlist of "complete" portions (I keep tweaking stuff endlessly due to perfectionism) on YouTube. You can read a bit more about the elaborate story it tells (any plain text you see in the score is meant to be projected or otherwise displayed/described to the audience along with the music) in each video and on the playlist page. I have been updating it regularly and I just refreshed all the videos to the newest score revisions last night.

Updating this to mention that this work is now thematically complete, after 30 years of off-and-on work (yesterday, 6/23, was the precise anniversary of the original inspiration). The parts I added since the last update are: Exhortation of the Goddess of Light and Praises to the Maiden of Gold (Movement I, Theme 2) Hail Now the Light of the One (Movement I, Theme 3) Praises to the Twenty-One Tārās and the Coronation of the Fairest One (Movement III, Theme 1) Fate Meanders (Movement III, Interlude 1) Destiny Loses Its Way (Movement III, Theme 2) Flight of the Fairest One (Movement III, Theme 4) Gone Upon the Surging Tide (Movement III, Interlude 2)

It's a simple equation for me at least. In-game store? No buy.

When I was a teenager I wrote a few experimental pieces of music that I somehow later lost and have never been able to find. One was called "Mind Fantasy" and was just a bunch of highly experimental notation and techniques thrown together. Sounded pretty bad but it had a couple of interesting ideas that moved me a bit further along in discovering what works and what doesn't. The other was a setting of an extremely dark poem I wrote while suffering from clinical depression, called "For Everything I Pay So Dearly". It was completed as a three-movement piano work, though the third movement was actually a drawing made over staff paper of a building with a significant role in my life ablaze in a firestorm. The instructions for the movement were to dump an accelerant on the piano and then light it on fire using a match. Pretty sure performances of that would've been rare. Perhaps some things are better off lost. Worse than that though, I've been unable to locate my original score work for "Les sons de l'ete" for a few years now. I absolutely know I still have it but somehow, every box I look in, it's not there. "Les sons" is alive and well but I'm sad I seem to have misplaced the OG work as it had sentimental value and is some of the only actual evidence that I started it in 1994 (the closest things otherwise are the poems/lyrics I have written on high school notebook paper, and an EZNOTE piano roll file with a timestamp of 1997).

https://doomwiki.org/wiki/The_Doom_Game_Editor

This is an index of all Doom Wiki Month in Review threads in chronological order. Volume 1 - 2018 Issue 1 - April 2018 Issue 2 - May 2018 Issue 3 - June 2018 Issue 4 - July 2018 Issue 5 - August 2018 Issue 6 - September 2018 Issue 7 - October-November (Early half) 2018 Issue 8 - November 2018 (Latter half) Issue 9 - December 2018 Volume 2 - 2019 Issue 10 - January 2019 Issue 11 - February 2019 Issue 12 - March/April 2019 Issue 13 - May/June 2019 Issue 14 - July/August/September 2019 Issue 15 - October-November 2019 Issue 16 - December 2019 Volume 3 - 2020 Issue 17 - January 2020 Issue 18 - February 2020 Issue 19 - March-April 2020 Issue 20 - May 2020 Issue 21 - June 2020 Issue 22 - July 2020 Issue 23 - August 2020 Issue 24 - September 2020 Issue 25 - October 2020 Issue 26 - November 2020 Issue 27 - December 2020 Volume 4 - 2021 Issue 28 - January 2021 Issue 29 - February-March 2021 Issue 30 - April-May 2021 Issue 31 - June-July 2021 Issue 32 - August-September 2021 Issue 33 - October 2021 Issue 34 - November 2021 Issue 35 - December 2021 Volume 5 - 2022 Issue 36 - January 2022 Issue 37 - February 2022 Issue 38 - March 2022 Issue 39 - April-May 2022 Issue 40 - June 2022 Issue 41 - July 2022 Issue 42 - August 2022 Issue 43 - September-October 2022 Issue 44 - November 2022 Issue 45 - December 2022 Volume 6 - 2023 Issue 46 - January/February 2023 Issue 47 - March/April 2023 Issue 48 - May/June 2023 Issue 49 - July/August 2023 Issue 50 - September/October 2023 Issue 51 - November/December 2023 Volume 7 - 2024 Issue 52 - January 2024 Issue 53 - February/March 2024 Issue 54 - April/May 2024 Issue 55 - June/July 2024 Issue 56 - August 2024

Added the newest part to be finished. This was actually one of the earliest parts I started work on back in 1994. I just put the last few touches on it this morning.