Maes

Though to be honest, making a bunch of levels isn't the first thing that comes to mind when someone mentions "selling games using the Doom engine". I was thinking more about something like Heretic or Strife, with extensive engine modifications.

Then again, the tables may one day be turned ;-)

Still, I cannot put my finger exactly on what kind of error this is. I guess this is yet another job for @Linguica? Edit: nm, I just saw the nodes response. What's interesting is that VS claims to have rebuilt the map too...So no nodes were rebuilt in his case, or they ended up borked again?

This being Doomworld, we're lucky it didn't go the way of gun control or something. Which is linked to authority, if you think about it...

More like being immune from being banned and calling the shots themselves, if I have to spell it out. Same reason many want to be cops, really. Even though in real life, a cop and other authority figures will be -for the most part- answerable to a superintendent of sorts. Internet forums OTOH tend to be run more like many little independent dictatorships, benevolent or otherwise.

And yet, AFAIK, nobody has done so in years, at least on the desktop. The last known time a commercial Doom-engine game appeared was in the 1990s, when a regular license from id was still required (this does not include official source ports such as the XBLA version). The only commercial exploitation of the Doom engine appears to be a few (and far between) mobile ports of Doom, but that's not what the OP had in mind.

TBQH I'm not aware of any game using one of id software's (formerly) commercial engines without a license of sorts, at least when the engines were in their heyday, and by the time the engines themselves were open sourced (including Doom and all iterations of the Quake engine), the interest in using them for a commercial game had all but waned. Of course, there's a difference between "using the Doom engine as-is", "making your own modified version of the Doom engine", "using a specific existing source port of the Doom engine" and "using Doom's resources".

Well, that's why most people want to be forum admins when they grow up. Those guys can do whatever they want....right?

Well, I was curious and tried this in ChocoRenderLimits: no drawseg overflow, however there's quite some bleeding from the second area. That's technically not the same thing as either the long wall error or a drawseg overflow. Is that what you saw in Vanilla doom?

Funnily enough, that's one of the things that was easier to do in oldschool DEU, along with automatic staircases.

So basically getting at the player through Doom's equivalent of persistence hunting -only that this time it's the monsters and by extension the game that are persistent and tireless, without individual encounters necessarily being hard. A very old example of that is the infamous HORDES.WAD (not on current idgames, unfortunately (?)). Can you imagine taking on nearly 50 identical rooms with a bunch of imps, zombies, pinkies and the occasional Baron thrown in, all with standard Doom I weaponry, and no saves? That too is "difficult", in the sense that very few players would actually finish it.

But doesn't Motion Blur require extra inter-frame processing and hence GPU and/or CPU time to accomplish? If anything, I thought that having it was a privilege for hardware powerful/advanced enough to support it. Unless it can be done with little penalty "on top" of the actual rendering of distinct frames, it doesn't really sound like a very good "mask" at all.

Well... at first glance it wouldn't make much sense, as it's basically just 3 long walls plus one broken by a door, but it's the only mechanism I know that can negate the rendering of walls. Then again I am not sure if there's a limit to any individual drawseg's length, which would force breaking it up in more than the engine can handle. Only a port with real-time rendering metrics could shed some light into the mystery. Also, the OP didn't say which version of vanilla Doom engine they're using: if it's v1.666, the static drawseg limit is much lower (128 in v1.666, but was lower still before, e.g. 64 in v1.1). While 256 may seem a fair amount, 128 could start struggling.

Drawsegs overflow. Even if the wall might appear as one piece on the automap, for rendering purposes it's actually partitioned into many smaller pieces due to the BSP, and so portions of it may not be rendered if the static drawsegs limit is exceeded.

I'm not sure what you mean by Doom being "non-deterministic", but the precisely predictable and repeatable nature of its RNG is what makes demo playback possible, and its knowledge and manipulation to the player's advantage is what makes TAS speedruns possible.