zokum

From a relative standpoint it is obvious that Plutonia is a hard game compared to Doom (2). Compared to other FPSes of the time, I would say it is a fairly hard an unforgiving game. The main competition is probably DN, DF and Quake + the other doom engine games. The main problem I have with Plutonia and TNT is that it was a full-price game that reused a LOT of content from to other full-price games. TNT feels like an average megawad, which is essentially what it is. If you view it as a stand-alone game, it isn't too bad, but I think buying Doom 2 would be a better choice. As a sequel and compared with the other games at the same time, it's sorely lacking. It was a cheap cash-grab-release from id. Plutonia is the better of the two since it brought something 'new' to the franchise and player base. 32 hard levels with an overall good design, with good continuity. Plutonia doesn't feel like 32 random maps. The traps and difficulty make sense to me as a design choice. If it wasn't a harder map set, it would have been a fairly pointless release. So I'd say that as a standalone 'game', it's too hard, but as a mission pack sequel to Doom 2 and TNT, it works very well. Had it been released today, it would have been a cheap DLC. I'd say the best thing about Plutonia is the difficulty. They had a clear vision and they delivered just that. It's a very well overall megawad design, unlike TNT, which is all over the place.

The blockmap overflow problems is basically caused by there being too many / too long linedefs in the map. Every linedef in a 128x128 block adds 2 bytes, before the compression. The overflow is the result of the total size, header + blocks + lists. Most of the time, the lists will be the majority of this data. This is something I plan to address in my guide. I've already started writing it a few days ago.

There might be some decent gains with that buffering technique when using flat shaded sky/flats etc. Higher chance for the same color in the new frame. I wonder what the game would look like if you used a 'sloppy' redraw algorithm. Redraw walls and sprites on every frames, but floor on every other frame. Would lead to some odd artifacts, but it could increase the framerate a bit. Another approach would be to only redraw the pixels if they are more than '1 position' away in the palette index. Basically not updating small color changes, in order to get a higher framerate. You'd have to hack in some logic for the end of the ranges, but it could be doable.

If I'm not mistaken, it happens randomly, but it might take a while before you notice it since the probability is fairly low.

There are some things you can do to speed up the doom2.exe load times. Building all the textures is where some of the time is spent, I think @Linguica tested out a wad with every texture instead remade as a one-patch texture. This sped the loading times up a bit. Fastdoom is nice and fast, maybe there's some nice optimizations that can be done in the loading and saving routines found in the game? Back in the day, the building of the map and the load times slowed down the mapping process quite a lot - not so much of a problem these days though. Maybe premaking machine code to 'render' the static sprites (hud) could speed up things in-game? For demo playback and collision detection, compressing the blockmap and optionally remove the 0000 header if it exists and have that done algorithmically could speed up things. In 99.9% of maps, if sector A is not visible from sector B, the oposite is also true. So an algorithm for making that table triangular instead of square could reduce memory requirements, and hopefully increase the speed slightly. I think ncurses and other similar text mode libraries use an internal buffer and only issue the differences when you tell it to update the screen (no overdraw). Doom probably does not have enough similar pixels in order for this approach to help much, but this might be viable for low color and text modes where there might not be that many changes. For ncurses the benefit comes from an algorithm doing this optimization is a magnitude faster for the end-user than sending unneeded data over a network link, and Doom is perhaps not quite like that. :) Just a few suggestions, maybe it gives you a good idea or two?

A few of the Doom textures can easily be created in Doom 2 since the patches are already there. These days it might be 'ok' to distribute Doom textures in a wad, with Romero's dump and all. It would probably be fairly safe to include only patches from the shareware version. In theory you could distribute your project with a script/tool that rips the textures from an unmodified doom.wad from the shareware and put them into your pwad. Distributing the shareware unmodified is ok.

Not a musician. If you use adlib for sound output, you could make your own custom 'instruments' that might be able to do some more non-midi effects by making variations of those instruments as extra instruments. Doom supports loading custom instrument definitions from wad files if I'm not mistaken. You can use Opl 2 stuff and a limited subset of Opl 3 functionality. It might not be what you are looking for, but there's room for creativity here in ways you might not have thought about. With ~128 instruments, you could make an interesting tune or two. Dune 2 has a MT32 soundtrack that uses the 32kb of ram on that synth to great effect by making several cool custom instruments, synth leads etc. These are used in more or less all the tunes, giving it a unified sound. Something like that could perhaps be done in Adlib as well.

One of the things I have been working slightly on is a guide to making large vanilla maps. I was thinking of adding it to my doom site and add a doomwiki page with short explanation and a link to my file. I like the doomwiki, but for a document that mostly I will update, it's not quite the right tool for this. Blockmap is one of those things I will write a section about as it tends to be the limit most mappers reach first.

Libraries change, operating systems change, new bugs that we didn't know of are found, emulation isn't 100% correct, there's always minor things that can be improved. I'd say making it more portable is probably the place where there is the biggest opportunity for patches. There's also emulation of obscure versions of the game, their bugs and quirks.

E1m6 has a lot of not all that bright indoor locations. The outside areas are bright. The 'maze' area has similar brightness levels to the outside area and a high ceiling. If you don't see the ceiling, which is full of lights, it would be reasonable to assume it was sky. The map also has a areas with bright sky and nukage outside, and this area contains nukage. I sort of remember them as outside areas as well.

E1m1 has barrels though. And if you meant map01, it has a rocket launcher even on single player. In Doom 2 you get a surprising amount of weapons quite early in the game compared to the original game. The first map gives you a shotgun, a chainsaw and a rocket launcher. In all honesty, the rocket launcher could have been omitted on single player. By the time you get it, there's not much left of the map, there's about one situation where it can be handy, the outside imp pack. I think it's a bit too much firepower this early in the game.

Map29 has a few other curiosities. It has a box of rocket ammo, but no rocket launcher. It think it is also the only map in Doom and Doom 2 that has a Cyberdemon, but no rocket launcher. Rockets VS rockets is an iconic fight, but Romero skipped that trope on this map. No idea about TNT or Plutonia, don't know them well enough.

People have really different ideas about what is a good level or not. I've never had any problems with e3m7. It has a strong and consistent theme, and it has plenty of room for dodging monsters if you are low on ammo until you find more ammo. I understand that a lot of people have problems finding out where to go. This is one of those maps where memory plays an important role. As long as you manage to find all the teleporters, you at most need to visit them twice. It is a type of map some players excel at, while others find it extremely frustrating. What Sandy could and probably should have done was to mark it destination of a teleporter with a specific object, colored torch, evil eye and so on. And then mark the teleporter 'buildings' in a similar manner. Then you could have gone and looked for the teleporter with the correct thing that shows you where you end up, without having to go into it. That would also make it easier to remember, since the order might be: green torch, red torch, blue torch, evil eye, beating heart on pedestal for the correct order to take them in. Doom needed to have maps that do things slightly differently, that try to do new things. If everything looked and played like episode 1, but with different texture themes, the game would be fairly boring, even if the individual levels are better, on their own. That's why I'm not that big of a fan of episode 2. It often feels like this is something we have seen before. Episode 3 is a much bolder design. A good example would be e3m6. Nothing else in the game is even remotely close to this map, design-wise. Doom has 4-6 maps I would think of as outdoor maps. E3m6, e3m2, e3m8, e2m8 and to some extent e3m1/e3m9. The boss maps are a special case, as they are more of an arena, and not a complex outside environment. Secret maps in Doom were a treat to find, and felt like they fitted into the game. In Doom 2 the secret maps are more like easter eggs and jokes. Map32 is especially weak, since it reuses the idea, and adds even more wtfery with the dead Keens. The Doom palette could easily have incorporated the nazi officers and the dogs in a reasonable manner. That would have made the maps better. The current version just seems a bit lazy. Id probably had a plan where they wanted to replicate them better, the sliding doors etc, but it seems they gave up and just made the bare minimum.

Judging by the falls Doomguy survives and his run speed, I'd say there is a hefty element of power fantasy in this game. The guy can run effortlessly over lava and bubbling nuclear waste. His capacity to carry ammo and weaponry is also more or less god like. 100 rockets? A ton of weapons including a BFG, rocket launcher, chaingun (gatling) and even a chain saw - no problem. The way the berserk pack boosts his muscle power so much that he can literally beat monsters into giblets. The original Doom game is in many ways a clear power fantasy, but not the same one as in Eternal and 2016.

Yeah, I ought to get that fixed. So much work and moving stuff. I have a copy of the latest version on my personal web page, but no one knows where that is really.

I can write some in-depth technical bsp/rendering stuff if it's wanted. I might even throw in some 'unreleased' stuff.

The maps I dislike in Doom 2 are map21, map12, to some extent map18 and map25. 21 is by far the worst map in Doom 2. A bunch of simple disjointed room connected with odd hallways or teleporters. Map12 is just terribly bland. It doesn't offer much interesting and some of the areas like the BFG area and the teleport trap are especially bad. Map12 is a bit better on coop. The addition of the Spider Mastermind makes it a bit more scary and difficult. The outside is a lot more unsafe and the mix of the big spider in the open area and the small baby ones up top works for me. Map18 has a lot of random wtfness. The main area of the map works ok, but most of the side areas are fairly meh. The opening area has some really screwed up sky rendering bugs. With better texturing and a bit better design on the side areas, this map could have been something much cooler. Map25 has an illogical progression with cheap teleporters. It's also underdetailed and fairly nonsensical. A cavern full of torches is very dark. Secrets without items on higher difficulties. This one feels like an early layout draft. This map received a few updates from 1.666 to 1.9, but more should have been done. I'm not too fond of map13 either. The idea is good, but some of the buildings aren't good enough. There's some decent game play here, but it is hidden amongst all the shite.

You're moving the goal post here. It's still a reliable and easy to implement strategy, if you need it or want it. The percentage of players using it actively isn't relevant at all. The original statement was: "I'd say it would be more interesting to make the blockmap bug a reliable gameplay mechanic somehow, rather than a whoopsie." And my point is that it is a reliable gameplay mechanic, but not all that useful in most cases. For some corner cases like nightmare speed running it can be quite helpful. Since monsters tend to move around quite randomly, it isn't all that useful to check out where it affects them, but in corner cases like narrow passages it can be quite important. For players, it can be used fairly easily, if you need it. From what I can remember when testing code related to this, it can make the maps harder if they have a lot of hitscan enemies. You normally have a reduced chance of taking damage in about 25% of the map. It goes from next to no reduction to half the size of the hit box. There are other complications at play here as well, like your hit box being square, making it harder to hit things depending on the angle of the shot. What I like about this is the tradeoff aspect. By positioning more carefully, you spend slightly more time, but gain survivability.

As far as techniques go, it is easy to do it, but there's not that much to gain from them in casual play. It's a bit like SR50 and wall running. Rather easy to do, but not something most players use or need. Knowing where the boundaries are could also help in high-end deathmatch. All you do is go from A to B, along a straight line, axis-aligned. The nice thing about this is that the reduction is gradual. If your player has a 32 pixel wide hit box, you can "remove" about 16 pixels of that if you're doing it perfectly. However if you're 8 pixels off the line, then your hit box is reduced by 8 pixels. It works on both sides, so you basically have strips of 32 pixels, where the effect is highest in the middle. So out of every 128 pixels of floor texture, 32 of those have reduced hit box to some degree. So even if you weave back and forth across the lines, you can still get some effect. Since a lot of textures are axis aligned and this effect is axis aligned, you generally only have to know that in a room on every other repetition of the floor texture, that is where the perfect line is. Hard to do on 'grass' but fairly easy to do on tiles-style flats. If you used a port that had support for 128x128 floor textures, you could change the flats to one that displays this as a color coded area. Then it wouldn't be hard to plan routes or learn where to run. You could also use idmypos if you knew the blockmap data block offset in order to compute if you are in a good position. Doom has loads of things that are easy to do, but can improve your game in marginal situations. Since the two first shots from a chain gun are always dead center, shooting in bursts of two shots to avoid the spread can be a way to increase accuracy when doing long range shooting. Strafe running is another popular technique. Makes it harder to navigate, but you do get a higher effective top speed.

That's where you're wrong. It's fairly easy to use this as a player. I asked one of the best compet-n players about this a while ago, and he confirmed that they did plan their routes to cross areas in certain locations in order to increase survivability. The exact term he used isn't easy to translate correctly into English, but it can be translated as 'using and finding good lines'. Finding good lines to run is a combination of line of sight and hit box reductions. It might be something as simple as running at the right side down a tunnel will make you take less damage than running at the left side. What the people I talk about here didn't do was to find the sweet spots (areas really) by looking it up and then planning the route based on that. By reducing the trial and error aspect, one could perhaps increase the odds of beating maps without taking excess damage. Another player told me about a sweet spot on Dwango 5 map01 where you could 'camp' and still be quite hard to hit. An ideal spot would be a location where the vulnerable part of the hit box would be mostly hidden by a column. Shots would either hit the column or pass right through. In essence the player becomes only a few pixels wide. In this case it was explained that it was very hard to hit the player with bfg tracers and ssg shots. On the other hand this didn't affect that player's opportunities to shoot opponents. Thus it was a good camping spot. I did add the ability to set different offsets, and therefor manipulate this, in ZokumBSP. I could probably cook up a map to show how this can be used.

It is reliable. It will happen in the exact same areas in a map every time you play it. The Doomwiki unfortunately doesn't explains it very well, especially on a per map basis. I've tried to correct it, but my edits got reverted. Some of the listings are fairly non-sensical, plain wrong and they are almost all too inaccurate to be of any help. From the article https://doomwiki.org/wiki/E1M6:_Central_Processing_(Doom) The following actions can trigger the blockmap bug: * Firing eastward or westward at the north edge of the slime walkway in the first room. * Entering the first room from the south (via secret #2). * After leaving the first maze room to the east, turning right to face the first imp (ITYTD and HNTR) or the first two imps (HMP, UV, and NM). * Leaving the dark computer room by the west door, passing the column at the top of the stairs, then firing eastward. All of this is more or less pointless and confusing. Especially the second point makes little sense. It's mostly just people writing down random locations they noticed the bug. A map like e1m6 has hundreds, if not thousands, of 'areas' where you can be affected by this bug. In nightmare it most likely benefits you more than it hinders you. Monsters that fire instant weapons are often the most lethal since their damage cannot be dodged. By running 'on' or near block boundaries you lower the incoming damage. A simplified explanation would be: In certain areas, for every 128 pixels in both directions, the boundary box of objects become smaller. It is at it's smallest (half the size) at 0, 128, 256, 384 etc. When not quite a these magic values the hit box gets gradually bigger. The blockmap bug is when projectiles should hit, but are instead passing through that area where the boundary box is cut short. The bug happening to a single bullet is something binary, it happens or it doesn't. The change in size of the hit box is gradual. The name is also fairly bad, as there are several known bugs in the blockmap code in Doom 2. Blockmap (block) boundary bug would be more precise.

If you used the half-height characters, you could double the resolution and probably fit him into an Endoom screen. It would look better. There are a few areas with bright green and white that could be problematic.

@LexiMax That layout is most likely Tom Hall's work. Many of the maps credited to SP are TH maps that were polished and finalized. TH maps typically fit inside some geometrial figure, one from the work in progress Doom map / Doom bible. E2m6 is Sandy's first map if I'm not mistaken. Also rather interconnected, but not quite as much. Not nearly as compact, although some of SP's maps are compact, but so are some of JR's as well.

By all accounts the space base textures were made early. Hell and rocks came later. I wouldn't be surprised if they were retextured near the end. People forget that when they were developing Doom and Doom 2 they didn't have all the assets. Some maps have texture choices that are less than optimal. It could very well be that at the time of the making of the map, that was the best choice. It's not easy to play test and refine maps when the monsters don't behave like they will in the final version. Lost souls being the best known example of this.

I honestly think you should readd the network support. Coop is an important part of the game, and is needed to play back coop demos, which a lot of projects have. Not only that, FastDoom with multiple views, -left and -right and possibly -back would be great to have in the game. You could use another pc and monitor as a permanent automap. That way the multi-monitor stuff could be used by people without rare hardware. Doom supported IPX, modem/dwango and null-modem out of the box. People quickly added parallel port, various serial enhancements and other standards. It would be cool to support more methods out of the box in Fastdoom. Token Ring, ARCNet, tcp/udp and midi springs to mind as well as support for all of these in a bridged configuration. I used to play Quake with a PS/2 mouse, two serial cable connected machines and one connected via parallel cable that emulated IPX. Four players with nothing more than simple cables you could make yourself. We had one we made serial cable ourselves from two busted serial mice and a candy label sticker. Doesn't get more home made than that one. Fastdoom has become more of a retro hardware Doom, and to me, multiplayer support is an essential part of the experience. Maybe it could be added as something that only was supported if you set #define MULTIPLAYER when building Fastdoom? The code used for changing player colors, it could be used for barons/hell knights to save memory. It would also be neat if a blue and white player was added to the game :)