Dark Pulse

Precisely. The lump name of your new sound should be identical to the lump name it is replacing. Basically, if Doom loads two WADs with the same lump names, the one loaded last takes precedence. The game will load the IWAD's lumps first (hence, DSBOSCUB will be active from that), and then it will see your PWAD replaces it and refer to your replacement instead.

Depends on what you're doing. If it's vanilla-compatible, you will want a file with the exact same lump name in your PWAD, and make sure that the audio is 8-bit unsigned mono at 11025 Hz (some sounds are 22050 Hz though, but not this one). Save it as a WAV, import it via something like SLADE, then right click the file and convert it to Doom's sound format. If it's a source port, what sound files you can use depends on the source port. WAV is pretty universally supported, but so is stuff like Ogg. It should still be the same lump name as the sound it's replacing though.

Old, but absolutely false. It's the other way around - SNES Doom is rendered completely on the SuperFX, and then the final frames are sent to the SNES to display. The SNES wouldn't have a prayer of rendering it on the CPU.

Solar System Explorer?

Some tracks are CD audio (title screen, menu, intermission, Club Doom once you enter the club, etc.) but most tracks in the game are very much sequenced music similar to MIDI or tracker modules.

No, it was in the PS1 version as well.

Long story short, OP, your GPU in that laptop does not support Vulkan (which is generally the ideal renderer to use nowadays), but it does support OpenGL 4.4 (and DirectX 11.2), and so GZDoom should run fine with the OpenGL renderer. Though from what I've heard, the intention is to sunset the OpenGL renderer sometime in the relatively near future, so while you're good for now, eventually that will be the next real limitation, and the only real solution to that is "obtain a newer laptop." Based on the date of that GPU, it's already almost 12 years old.

IIRC, 3DO is only partial. Columns and spans are accelerated, but all the ceilings and floors are still done entirely in software (and are a large chunk of why the performance is so abysmal, since the 3DO's CPU was pretty weak for it). We're talking an ARM60 (ARMv3) running at a mere 12.5 MHz. No cache, no MMU (though it did have a custom math coprocessor). Not even 1 MIPS/MHz (a 12 MHz chip got about 10 MIPS). Fucking yikes.

Most consoles of the era did not really have any sort of perspective correction. PS1, in particular, had none, so even though it could've been "hardware" rendered, it would've still had the affine texture swim. Basically, texture perspective correction would've always been something you'd have to do in software since the graphics hardware of the time could not do this, and the systems of the time simply did not have the grunt to do that. (Notable exception: The N64 was fully capable of perspective correction in hardware.) As you said, a lot of games of the era got around texture swim by subdividing larger surfaces into smaller triangles, since the warping would've then been on a per-triangle basis, considerably reducing the effect (but it was still completely possible to occur). PS1 Doom predated these approaches, probably because it was such an early game for the console, but it came up with a more-or-less similar idea: Subdividing the rendered view into pixel-wide polygonal strips. The warping would thus be pretty much eliminated, but the cost of this was that it pushed an insane number of polygons per frame, and that's a large reason of why the framerate can occasionally be brutal on maps where there's a lot of distant drawing and so on. In theory though, sure, the renderer could be rewritten in order to do it more like later PS1 games did. Whether or not somebody wants to do that is a whole other question entirely.

Shouldn't even really be necessary. If GZDoom finds a ZMAPINFO, it will read that, and ignore any other MAPINFO-type lumps. Basically, ZMAPINFO will be read by GZDoom, and the UMAPINFO will thus be ignored. Other ports, meanwhile, will have no idea what to do with ZMAPINFO, and will thus read the UMAPINFO. So it should "simply work."

Then my guess is that you're missing some kind of prerequisite it expects, or your system configuration is somehow not able to run it. Maybe your GPU drivers are out of date? Alternatively, it could be the path name is too long and stuff is screwing up that way. Try moving it to somewhere with a shorter path (like in a folder directly under the root of C:.)

It means that Eternity gave Micrsoft C++ a fabulous makeover, and it's now exceptional. Okay, a non-shitpost answer: It's admittedly hard to tell exactly what. There's very little other information, and that error code seems to be a super-generic one. Is there anything in the log before the exception?

To the community? Important as hell. In a technical sense? Not very, compared to the original's breakthroughs.

If there's a version of GZDoom that will run on the Switch, that's certainly possible, but I'm genuinely not sure if there is or not. It certainly isn't possible in any official manner, for obvious reasons.

Well yeah, I get that much. I'd certainly agree. Still, "What format are you mapping for?" is one of those gotchas that many novice mappers don't even really know about. :P

It should be noted that this is UDMF, and yeah, this is easy enough to do there. If he's mapping for Vanilla, this is a whole other ballgame. :P

It's basically as you said. Once you do one or the other, you can't do the other one in its stead. Per the wiki on the Lower/Raise types: While it does not say that specifically for the linedef-triggered one, presumably at that point, it's finding the lowest floor as the floor that it's on, and the highest floor as... well, the floor that it's on. So it doesn't move. There are ways around this, but I think you would basically need to use a map format that is compatible with ACS scripting (i.e; Doom-in-Hexen, UDMF, etc.) and write a script to do the actions you want. Vanilla-compatible actions are very "fixed" and you can't easily do stuff outside of their limitations.

"Just walk through it," they said. "It'll be fun," they said.

Yeah, I'd say that usertitle checks out.

Level names are basically two different parts: The intermission graphic, and a string in the executable. The intermission graphic is easy enough to change, but the executable string (since you're mentioning WhackEd, I'm presuming you're making something vanilla-compatible) must be the same length or shorter than the originals, and it's in a separate section - the Strings section. If you're doing Ultimate Doom, they begin on Entry 655; if it's Non-Ultimate Doom 1.9 (i.e; Doom II, etc.), they begin on 649. The Doom/Ultimate Doom level names will come first, followed by the Doom II ones. If you're doing something for a limit-removing source port, on the other hand, there's much easier ways to do this (i.e; UMAPINFO) that would have none of the limitations.

Everyone who likes snow, get shoveling. This is what's outside my window right now. That gray thing you can barely see outside the window is a bush that's about 50 feet away.

Transparency depends on how you're doing it - via PNG or the format that Doom uses for sprites. If the former, you'll set the cyan to be transparent in some sort of image editor (i.e; Photoshop, GIMP, etc.) If the latter, you can set that in SLADE. As for cutting it up, basically cut them broadly into sprites, then trim down the sprites (most image editors will have a tool that will strip away unnecessary extra space on the edges). Either way, you'd need to align the sprites in something like SLADE for it to look good.

I don't like snow. You like it? Here's a shovel. Get to work, I'm getting my ass inside to warm up.

Doom fonts are graphic characters, so you'd have to gather all the characters, turn them into vector art (i.e; SVGs), then use the SVGs and a font making program (i.e; Calligraphr, FontForge, etc.) to create a font. It's basically a fair bit of work.

Probably because most people aren't on ultrawide monitors. Fixing it would be up to the individual ports.