Dark Pulse

Doom-in-Hexen Format. Basically, you utulize the standards of Hexen (i.e; it has a BEHAVIOR lump and so on), but it is a Doom map. Then again, you've also got TEXTMAP which is definitely UDMF, so you probably just needed the graphics to be between the right markers. But TX_START/TX_END has some issues - namely, if there is a graphic with the same name that is both a wall texture AND a flat, one will overwrite the other. It's generally good practice to have textures intended to be flats to be between F_START and F_END, and to keep only the wall textures between TX_START and TX_END (although technically a texture that is in that can be used as a flat as well).

Slopes were never a part of vanilla Doom, so no. That's why there's different map formats - different formats have different capabilities. For example, vanilla Doom didn't have ACS, either. Hexen introduced that, so if you want your map to have ACS, it must be in Doom-in-Hexen format, or some other format that supports ACS (i.e; UDMF).

Well, for one technology was rapidly advancing. Don't forget it started on the Quake engine, and got pretty much completely scrapped and restarted from scratch on the Quake II engine. The sidekick system was also notoriously undercooked - it took until engines like Unreal and Quake III to really have heavy pathnoding support, which might've helped them navigate the levels a lot better. And of course, what you could actually render on screen was still heavily limited due to it being an era where hardware acceleration was still in its infancy - go up a few years and virtually every card has support for hardware transform and lighting, allowing for the rendering of high-detailed, high-poly meshes with minimal speed hit as opposed to it still being brush-based CSG. A more modular engine never hurts, too, and engines were starting to become more general-purpose in that direction during the early 2000s.

As others have suggested, probably the best way to go would be a cradle/dock that would let you plug a regular internal SATA hard drive into something that could be hooked up via USB to a different PC. If the drive won't spin up or register, the drive itself is dead and at that point you'd be looking at a data recovery service to see if you could get the data off it, but if it does, then it's just a matter of searching the drive for the files.

I don't use that port, but zooming in and out and marks should be possible. Lead-you-by-the-nose navigation, though, no. That would need to be some kind of mod, and for all I know that might be impossible. You'd have to have some sort of way of constructing what the level space is, take heights into account, and so on to even begin to have a navigation system like that.

Probably. Also didn't help a bit that he was, in some ways, a few years ahead of his time. Daikatana was hell to make during the late 90s, but move forward even five or so years and suddenly it becomes a lot more plausible. There is also the fact that without someone like a Carmack to instill discipline and keep feature creep down, he really could go hog wild with scope, and I believe that in retrospect he himself has admitted as much. It's often been said that one was the yin to the other's yang, and indeed without Romero, id's games kind of fell into a "technically nice but lacking life" sort of feeling, while Romero of course had grand ideas but they were so extensive that it became impossible to sanely produce.

He isn't claiming ID was abandoned, he's claiming the RD6 codebase was abandoned. IIRC, ID had a lot of its code rewritten for 7.0.

Hindsight is always 20/20.

Only if you also include "Maximum Doom." Then not only will they be you, they'll come out looking like your avatar.

This is when I blow your mind and tell you the DOS version is, itself, a source port of the original code. :P

Play Doom how you want to. I use freelook. I'm pretty sure Doomkid does as well. And a lot of the other people in the community that I've had the privilege of having a deathmatch with or being a part of their video with tend to do that as well. There is no wrong way to play Doom so much as you're having fun. Whether that means absolutely strict accuracy or a completely modded experience, just have fun, man. That's something that should unite all Doomers.

Nice to see Lilith.pk3 is supported!

As others have said, you don't, at least not in vanilla. Other formats (Hexen map format, Boom, etc.) have tricks you can use, but with Vanilla, everything is strictly aligned to the grid.

It should be noted that ROM can degrade as well. It's perhaps somewhat less susceptible, but well, it's a physical format - anything physical can be destroyed over time.

https://zdoom.org/wiki/MAPINFO It literally goes into every possible option. There is also a priority order: If ZMAPINFO is found, it will use that. MAPINFO will not be parsed. UMAPINFO is more flexible, because it is intended to be a "universal" standard that multiple ports could use (instead of rolling the old way of their own individual MAPINFO definitions). However, in GZDoom's case, it only supports up to 1.4 of the spec (the current latest is 2.2). If neither of those are found, look for a MAPINFO and use that if it finds it.

Correct. IIRC, the closest Sega got to the idea was that of having the SVP chip as a sort of "base" cartridge, and games that used the chip being sold in a cheaper form because they could plug into it (like a Game Genie or Sonic & Knuckles), but that never took off for pretty much the exact reasons you mentioned.

IIRC, no. Hitscan shots have a fixed length of 2048 units if my memory serves. There's a few exceptions (BFG tracers are 1024 for example, and demons before 1.5 had a weird short-ranged hitscan that in 1.5 was changed to be consistent with how other monsters do melee checks), but that's about it.

I think the problem is more simple: You are using custom sprite names. You CANNOT do that for something that is intended to be vanilla-compatible, IIRC, unless you do some DeHackEd editing in order to change the strings the EXE is looking for. All replacement lumps in a WAD should have the exact same name as the original lump they are replacing. For example, if you are replacing the Zombieman's forward-facing sprite, the replacement sprite MUST be named POSSA1. You basically need to do two things: Move TITLEPIC out of the SS area (it's a title graphic, not a sprite), so either put it above SS_START or below SS_END. Rename your pistol graphics to the original graphic lump names, PISG (and PISF for the flash). Alternatively, if you are intending to use a DeHackEd patch for it, I think you need to make sure that all of the sprite names are properly replaced, not just the first instance. But I also remember it being a bit weird about replacing sprite graphics and that there was some quirks involved with that.

https://www.chocolate-doom.org/wiki/index.php/Chocolate_Doom

That's not quite the same thing the OP is asking for. What ZokumBSP does is "merge" linedefs in a sense that if one starts where the other ends, they have the exact same orientation, and many similar properties, it will tell the BSP tree that they are basically one line even though they are not for blockmap purposes, which is about reducing the blockmap. OP is looking to reduce the actual Sectors, which wouldn't be affected by a trick like this at all. Also, most Doom maps rarely have this sort of thing. If one's at, say, a 90 degree angle, and the other is at a 75 degree angle, it will not do this trick. It's also potentially going to cause problems if the BSP is ever rebuilt but does not use ZokumBSP, since basically, the "new" line is done in the Blockmap for collision, and the original lines are marked only for rendering. TL;DR: That's a niche trick to reduce the blockmap by a handful of bytes every time it can be applied, but it won't do jack for rendering speed, which is more what the OP is after.

The game isn't just using BSP for collision detection. Again, it is literally how it renders things. If you have no BSP tree, you have no idea what lines are in front of what other lines, what does and does not need to be rendered in any given scene, and so on. There's a reason I said what I said, and the simple fact of the matter is that to BSP, it dies not care if it's a line you will never step on or cross, or if it's the same lighting or textures (that matters for Visplanes, not BSP). If it's there, it must deal with rendering it and all the other things related to it. And that will mean the count you want to go down, goes up.

That would literally fly in the face of how BSP works, so no. It doesn't matter to the node builder that it's decoration - it's still a line, its visibility must be tested and accounted for, splits may need to happen because of it, and so on. So basically, you'd need a completely different rendering method to make it work.

Are you trying to run this in vanilla, or something like Chocolate Doom, or something else? The vanilla engine actually can't handle new sprites normally. Back in the day there was a utility called DeUSF which would merge the new graphical assets into the original IWAD (creating a modified IWAD in the process). If you're trying to play under Vanilla, this is still pretty much the only option. If you're using something like Chocolate Doom, that's a little more flexible - but instead of using -file to load your WAD with the graphics lumps, you'd use -merge instead, which will act like the addon WAD is as if DeUSF had merged the graphics into the IWAD, without actually doing so. If you're using something else, then the problem is more on your sprites than anything.

That's exactly the price I am quoting, yes. And keep in mind this is in mid-90s money, which was worth a lot more. This cartridge would've been about half of the price of the hardware, perhaps even two-thirds.