zokum

Let me quote the Doomwiki so that we clear up any misunderstandings: "Replacing sprites using a PWAD file presents certain problems in the original Doom engine, as all sprites must be in a single continuum between S_START and S_END; and any lump that does not respect the sprite naming convention found between these markers will make Doom abort on startup with an error message. This means that the PWAD must contain all IWAD sprites, even if they are not modified, or they will be invisible. Starting with Boom, source ports started allowing several sprite ranges each between their own S_START (or SS_START) and S_END (or SS_END) markers." https://doomwiki.org/wiki/Sprite By sprites it should be understood that we are talking about sprites that scale and change light levels etc, not resources like the menu graphics, status bar, title picture etc. Weapons unfortunately fall into the restrictive category. A wad that replaces a few weapon sprites, but not the all the others, is not vanilla compatible. You can do it in ports, but not in vanilla. If modding sprites was easy, you would have seen it in a lot more wad files. I'll see if I can't fix the text in the article to be more correct.

The lowest common denominator you can map for is Doom 2 v1.9. If those limits are too strict, the next step up is the Unity port and its raised limits. The unity port gives you a lot more room for complicated architecture. Above this is the MBF21 mentioned. Personally I think aiming for the Unity port is a nice compromise if you want to reach a wide audience. Anything that runs in this port should run fine in most ports. The exceptions being the original dos/unix/mac/win32 executables and chocolate doom and similar modern vanilla-style ports (Fastdoom). I'm biased towards Zokumbsp, but it is probably the best node builder tool around unless you want things like GL Nodes built. Many node builders support various special effects, so if you plan to do that, you need to pick one that supports what you want to do. Mapping for vanilla isn't as hard as people claim it is. All you need to remember is to use only the original linedef types, new textures, flats, hud and fullscreen graphics and to not make too complex scenes. It helps a lot if you know what makes scenes complicated, but as a rule of thumb, as few angles above 180 degrees as possible in order to decrease the visplane count. A two-sided 'wall' of two linedefs with one 45 degree angle would be 45 degrees on one side, but 315 on the other side.

You can't do this out of the box with just a wad file. You need to produce a complete IWAD in some form. In the old days you'd ship a batch and a way to copy the idgame iwad file and add your changes to this copy. You can't distribute (legally) id's sprites and other assets. You could probably fill it with Freedoom content and distribute a complete iwad. That also has its obvious drawbacks, you are supplying 100% new sprite content, not just a few sprite mods.

I don't know which editor people use for this, but a lot of works don't use any of the half blocks. The character set in use has both a horizontally and vertically split block, allowing for much finer resolution. As long as you remember you can't use two foreground colors, you'll do fine. The imagery here doesn't do that apart from the white and bright cyan on the hooves. And that could just stay as it is in my opinion. The biggest problem when doing line drawing style and not using half blocks is that horizontal lines are twice as thick as vertical lines. This is fairly evident on the hooves, face and eye. I'll see if I can't hack together a quick remix of your work when I come home. It's usually better to show work than explain someone how to do it...

This secret was added in version 1.2 of the game. From the top of my head there is a similar wall hiding the secret exit in e2m5, and that one was present in 1.0 if I'm not mistaken. I don't remember all the fake walls in the original trilogy, there might be more of them. The oldest map would be the first occurrence. Most likely people hex-edited grates into fake walls with the 1.0 data to figure out how the game worked.

It's a reference to the cheat code and a game someone suggested id should make. That game might very well exist in the Doom universe... https://doomwiki.org/wiki/SPISPOPD I doubt it would have been in the novel had not id immortalized the phrase with that cheat code.

Probably not. Mapping for vanilla is generally harder and in some cases more frustrating, but I wouldn't call it boring though. For a lot of people the added challenge and the need for inventive solutions is an important aspect. Mapping for a limit-removing port can still give you a fairly old-school look, but be much more forgiving when it comes to occasionally going over the limits. An area might have 134 vis planes in a specific spot, but be be below in all other locations in the map. I've tried to make vanilla-mapping a bit more interesting with zokumbsp, since it will build some of the data structures better. You should be able to build more complex maps compared to most other tools. Knowing how to build complex architecture that is within limits can be quite rewarding, at least it is to me. People often make maps that do not utilize all of what you can do in vanilla to ensure compatibility with ports. That can probably feel a bit restrictive, and maybe boring to some.

I've forked it off to my own 1.7 branch. Ans I plan to clean up a bit and possibly back port some 1.10 changes.

In my opinion any sequel approval should be done by the original authors of a release. A HR3 should be approved by Donner and Niv. HR 2 does change some things from HR, but nothing drastic. A HR 3 that slightly changes things from HR 2 might have too little left of the original HR vision. The original release is 100% identical to the vision, and HR 2 is perhaps 80%. A new HR 3 that is 80% of HR 2 will then maybe be 64% of what HR was about etc. By only looking at the previous entry in a series, one can easily drift away from the essence of the original. New entries in a series can expand and twist, but shouldn't stray too far from the original source. If they do, just give it another name. It's not hard to come up with cool project names. If your project uses a well-known name, it should stay true to that brand. If you are doing an unauthorized fan-inspired take on HR, call it something like Hell Unveiled or Hell Revisited. You can make it obvious what you refer to without resorting to using an establish name to increase interest in a project. Want to make a sequel to Plutonia, then call it Urania (based on the element) or Dis Pateria (based on the roman version of the greek god). A project name is the easiest part. I think you'll get a lot more respect and recognition if a map set has its own brand. That also opens up the possibility for sequels, where you get to decide what is acceptable or not.

I like the dinosaur, but it would need a very specific mod to fit in. The Other one is an awesome ENDOOM. I think your artwork would look better in a more dos-like font, but that's my personal preference. Keep em coming @t.v.!

A boolean can only ever have the value true or false, often represented as 0 or 1. An integer can by any whole number, including 0 and negative numbers, but no fractions, imaginary numbers, irrational numbers etc. Various programming languages allow you to mix and match these different types, while others are quite strict about the type of value in use. Some places have a special 'null' value to indicate no value set, which is different from 0. Think of it as the difference between never having done something or done something an unknown amount of times. Never ever assume one programming language / field of use handles numbers and data types in the same way as another unless you explicitly know this is true. Number handling can also change from version to version of a language or depending on which vendor who made the tools you use. Computers do as they're told, but not what you want or need them to do. Programming is the art of giving the computer the correct instructions. The wrong instructions can give you wrong results, but you might be lucky and it works for your particular case, but not for others.

The way Doom handles custom assets is a bit broken. Scaled sprites like you describe is one of those areas where it's impossible to add and complex to replace. In the 90s projects that replaced sprites would do that on a copy of the main wad file and you would load that one instead. You can't legally distribute the complete file, but some projects do that anyway. I would recommend against it. When it comes to changing the logic/properties of things in game, dehacked was a small tool to patch the executable and many projects would ship with a .deh file and instructions on how to change a copy of the executable. So if you want vanilla compatibility, that is what you need to do. If you aim for Chocolate Doom compatibility, it can easily load deh files since the binary deh patching isn't possible.

I know there are tools that can find out these things, odd balancing like on map02. A few years ago I looked for one, but couldn't find a good one. Maybe it's one of those things one should just make yourself. A web based one would be neat. Just upload a wad to a page and get a report back. ZokumBSP has some very hackish report stuff that I used while developing. Not sure if it even works, but it has some blockmap html generation. That project has a few dead ends of things that aren't maintained or working well. Maybe I'll conjure up something for 10.12.2023? :)

That would have been awesome, but also possibly a bit annoying. You'd need a good way to cancel them in case people make long ones. You can use the blink attribute for a two frame 'animation'. It isn't very impressive though. Animated titlepic and such would probably be a bigger boon to the community. The animated intermission screens in Doom are quite nice, and I wish we could have had more like that at our finger tips in Doom 2. Doom 2 should have had even more hard-coded stuff put into the wad file. Where is this artwork from?

It's a fairly common thing to assume that a port has the exact same implementation as another port. What annoys me is when a port is different and people insist on the other port being the correct implementation and that there is an error in the original executable or in the map. This most commonly happens if you make a vanilla map that works fine in say chocolate doom, but not in a port. Some people will put the blame on the map/mapper. In most cases, the port is the problem. There are of course grey areas, especially when it comes to undefined behavior like using uninitialized memory. doom2.exe does muck up that once in a while.