Gez

Abolish capitalism. Nah but seriously, though. Have you seen just how many people work on a game nowadays? Between coders, concept artists, texture artists, 3D modelers, level designers, composers and sound designers, you can have hundreds of people, even thousands once you add in all the testers and other QA people. Game development takes time, about three years for an AAA title. So hundreds of wages multiplied by three years, plus of course the other functioning costs just to have a working office space for them, including taxes, utility bills, software licenses, hardware purchases, etc. That's really a lot of money. Money that they've got to recoup somehow. Since funding a studio to develop a game represents such a large investment, the investors will apply pressure to reduce risk, and that does mean less originality overall. Same reason, same result as to why Hollywood blockbusters are so formulaic and stale. So the way to avoid that would be, what, to fund studios to develop stuff regardless of expected market returns? That's possible if you happen to be a billionaire and you want to be a patron of the videoludical arts, but I doubt anyone around here fits that profile.

Yeah, Quake II was nearly called WOR, of all things.

Honestly, more than Heretic, this doomhell+tech+medfan mix reminds me of Hell-Forged.

Doom episode 1 secret level exits back to E1M4; Doom II's secret level exits back to MAP16. Which MAPxx slot should be used to have E1M4 be in slot MAP16? There's really nothing about map sizes being hardcoded to map slots. The only thing I can think of that has a mechanism like you describe in vanilla is map names, and more generally string replacement, because those strings are baked in the exe, and so using DEHACKED will overwrite those in the exe, which means you can't have "E1M1: Ode to a Small Lump of Green Putty I Found in My Armpit One Midsummer Morning" to replace "E1M1: Hangar". The map themselves? You can go nuts with them. There are plenty of vanilla projects with map sizes much larger than the id software levels; just compare Shadow Port to Entryway.

The OG method is using the thing's angle. If you've ever wondered why Hexen polyobjects use those instead of TID, it's because it's a leftover from an early implementation before they changed the map format...

And you can see it's also reflecting part of the plume of smoke.

I have on an old harddrive a partial collection of the PYDT thread. I suppose I could try to look into it if you're looking for some specific files, I might have them. That said, a quick disclaimer, it was just a bulk save of the files without any attempt at sorting things nicely by theme or by author.

I don't believe this will work. The hard-coding is not on the sounds themselves, it's on the mobj_t. You got code like this: if (actor->type==MT_SPIDER || actor->type == MT_CYBORG) { // full volume S_StartSound (NULL, sound); } else S_StartSound (actor, sound); Not like that: if (sound == sfx_cybsit || sound == sfx_spisit) { // full volume S_StartSound (NULL, sound); } else S_StartSound (actor, sound); The latter would be hardcoding on the sounds, but the former is what is actually used.

Gunther Herman is dismayed. They finally made a skul gun, but they got the idea backwards.

You need ACS_NamedExecuteAlways if you want to have several instances of the same script running simultaneously. Alternatively, ACS_NamedExecuteWithResult will also work.

Yes of course it's possible. For a start, any action special can be called from anything -- DECORATE, ACS, ZScript... even FraggleScript! And one of them is ACS_ExecuteAlways. Secondly, action functions can be called from DECORATE or ZScript, and one of them is CallACS.

Doomguy with a fur cape? Doom is now officially Skyrim With Guns.

This is incredibly suggestive and fuzzy. Pretty much any of the existing addition can be said not to be staying true to the limitations and style of the original. After all, the only way to stay true to the limitations and style of the original is to not do any change at all. Why wouldn't 3D floors and slopes fit with this idea? I'm pretty sure that if they happen (and I'm not saying they will), they'd be immediately embraced. Just like the sort of complex multi-stage enemy behavior that used to require DECORATE mods back in the ZDoom days are now possible in MBF21+DSDHacked and I haven't seen anyone complaining about it. Just for reference, 3D floors in Doom first appeared, I believe, way back in 1999 in good old DOSDoom, even before it got renamed to EDGE. The following year, they appeared in Doom Legacy. So we're talking about last century stuff. We're talking about this happening in the first 20% of the Doom history. Other games of the era had 3D floors, too; they existed in Ultima Underworld (1992); they existed in Elder Scrolls Arena (1994).

Shub-Niggurath says that, in hindsight, it's actually a bad idea.

You've probably heard the adage, "if it ain't broke, don't fix it"? Optimizing the screen transition code makes sense iff there is a problem with screen transitions. Any profiling analysis done to show that there's an unacceptable performance loss during screen melt? What is the desired end result of this optimization? What's the cost/benefit analysis? If you were talking about optimizing line-of-sight computation, for example, then yes, there would be an actual benefit to this, as this is typically a very expensive operation, to the point that the id guys brought in a "cheat" in the form of the REJECTS lump that is there just to allow to skip some of them. But again, screen transitions only happen when entering or exiting a level, so they don't overlap with actual gameplay. (Oh, and also for the finale, where it's even less relevant.) Here's the RunFrame function from Chocolate Doom: // // D_RunFrame // void D_RunFrame() { int nowtime; int tics; static int wipestart; static boolean wipe; if (wipe) { do { nowtime = I_GetTime (); tics = nowtime - wipestart; I_Sleep(1); } while (tics <= 0); wipestart = nowtime; wipe = !wipe_ScreenWipe(wipe_Melt , 0, 0, SCREENWIDTH, SCREENHEIGHT, tics); I_UpdateNoBlit (); M_Drawer (); // menu is drawn even on top of wipes I_FinishUpdate (); // page flip or blit buffer return; } // frame syncronous IO operations I_StartFrame (); TryRunTics (); // will run at least one tic S_UpdateSounds (players[consoleplayer].mo);// move positional sounds // Update display, next frame, with current state if no profiling is on if (screenvisible && !nodrawers) { if ((wipe = D_Display ())) { // start wipe on this frame wipe_EndScreen(0, 0, SCREENWIDTH, SCREENHEIGHT); wipestart = I_GetTime () - 1; } else { // normal update I_FinishUpdate (); // page flip or blit buffer } } } So you can see that if there's a wipe going on, it hits a return, meaning it will not do the rest of the function outside of the "if (wipe)" block, meaning it will never get to TryRunTics(), meaning there is zero gameplay going on. No thinkers are processed. Game time is fully paused for as long as it takes for the melt to proceed. When I liken removing or improving the melt code to an irrelevant micro-optimization, that's because, in my opinion, it is. Even if you could find a way to make all the screen melt computation happen instantly, this would have no noticeable impact, especially on a modern machine. Look again at the function above, I'm pretty sure the large majority of the time is spent waiting on the I_Sleep() call, not on waiting on wipe_ScreenWipe() one... Now if you want to do things like running Doom on a 286 or even a 8088, why not, then perhaps you will need to find ways to optimize this effect, or remove it altogether; but that's going to be a drop in the bucket compared to the work needed everywhere else to achieve this goal. But if the desired end result is "faster performances on a computer from the 2020s", then even if you succeed, it's not going to have a noticeable effect.

Wrong example; FastDoom is meant to be run on old hardware, so something that was done to "play nicely with 486 cachelines" is still perfectly relevant to it. Again, the screen melt function is not relevant to the gameplay loop, since it's only used for screen transitions. That means that if you yank it out, you get a bonus of exactly +0 FPS during gameplay. If you want irrelevant micro-optimizations, then you can also remove the function that displays the TITLEPIC lump. That way you don't have to load it and cache it; you can just display a black screen instead. This will save you one hundredth of a microsecond while launching the game, so it's a healthy reevaluation of a function which does not make more sense in modern time.

What would be the point? Remember that this effect is only active during screen transitions, and only overlaps with gameplay during the first fraction of a second when entering a level. And you can already get tens of thousands of FPS on the vanilla levels anyway.

Encoding should be 8-bit unsigned PCM, not 16-bit signed PCM. Rest looks okay.

To complement what was already said, a few useful links: Nash's Standalone Game Template DEFBINDS DEFCVARS IWADINFO License

Door_Raise is Door Open Wait Close.

No, the problem isn't so much a question of the lore's writing quality; the problem is that Doom is a game that does better without lore. I think I've said it before, but basically, Doom lore is always going to be stupid. And that's fine! It's not inherently a problem to have stupid lore in a video game. I mean, some of the most beloved games have a lore that is basically that a pot-bellied plumber keeps having to rescue a mushroom princess that keeps getting captured by an evil turtle. That's incredibly stupid, and that's okay, that's actually part of the charm. The problem is not in the stupidity of the lore, it's in having a try-hard, in-your-face approach to cramming some stupid lore down your throat. The best part of Doom 2016's lore was when it relied purely on environmental storytelling. The worst part were when it locked you with a monologuing robot that you couldn't even shoot. Doom is a game where environmental storytelling should basically be the only storytelling. Because, let's be honest, the story is stupid (and again, that's not a bad thing in itself) so it should remain in the background. While the story is stupid, the setting is cool. There's a lot of potential to have very moody set pieces, be they some some decaying brutalist industrial complex, some gothic hell temple or some surreal voidscape. Where Doom excels is at ambience and vista. Desperate, frantic fights for survival, alternating with foreboding exploration of sinister places, no one cares about the story anymore when what matters is what you feel while playing. Doom should make you feel anguish before a fight, stress during, and exhilaration of having survived it after, then repeat. So that's where the narrative focus should be, IMO, not in writing some fan-fiction about how the Night Sentinels went forth to Taras Nabad in Argent D'nur by Shor Ethra Regalion, to the house of Samur-Maykr-Betheul-Bazda, he who brought the butter dish to Maligog and the tent peg to the house of Deag Ranak, and there slew they the imps, yea, and placed they the bits in little pots. No, it should be on having simple pretexts for visiting impressive environments and tense situations.

Result should be predictable, actually, GZDoom will favor wall textures for walls and flat textures for floors and ceilings when there is a name overlap like this. Yeah, but you can delete that PNAMES lump now, it's useless when using TEXTURES.

Yeah, pretty much. My interest in whatever Doom Year Dark: The Zero Age is nearly nonexistent, existing only as "hey this is tangentially related to that other thing and we're probably gonna see a lot of discussion about it around here and eventually on the wiki"; but I'm not expecting it to be a game I'll want to play.

I guess he got the okay to distribute older versions of freeware games. Yeah, but the author's site is still online, so you can get it from there. That's where the link on the ZDoom wiki goes.

Yeah, because it was a promotional thing so the only way to get it (back then) was to buy the cereal box which contained the disc. I'm sure this was how a lot of kids saw it at the time, especially if they preferred other cereal brands... but this one had the game. Thing is, everything is automatically copyrighted. Did Digital Café or General Mills officially release Chex Quest 1 with a free redistribution license? As far as I'm aware, no. That makes any download of CQ1 the dreaded crime of copyright infringement, better known as 𝓢𝒪𝔉𝖂𝓐𝕽𝓔 𝓟𝕴ℜ𝒜𝕮𝓨, ahoy matey, yarr! For more on this topic, see Abandonware and also why it's stupid to have copyright terms lasting for a century especially for software when the associated hardware lasts for maybe a decade, but things are not as I would like them to be, they just are as they are. Which is usually suboptimal and disappointing, I know. On the other hand, CQ3 was freely downloadable from Chuck Jacobi's website, and obviously General Mills was okay with it since they did, as you mentioned, acknowledge it on their website and didn't sue anyone about it. So as far as the ZDoom wiki is concerned, CQ3 is legit freeware, CQ1 is genuine abandonware which is to say, nobody's gonna care if you download it from wherever but it's still, technically, illegal because sometimes the laws are stupid. And as official documentation for a project that is increasingly used for commercial purposes by various people, we're just going to keep playing it safe, and put Chex Quest in the categories of games that used to be bought (in the grocery aisle of the local mall) but is no longer sold.