If you could add one thing to Vanilla Doom

Ragdoll

reki107 said:

Ragdoll

Ahhh... hmmm.

I have more.

I'd like to give Carmack the hashtable fix from the Boom source, which apparently gives up to a 200x efficiency increase. Doom could have run even better on even worse hardware at the time.

Voxels would also have been rad. The preference of voxels over 3D models probably would have changed gaming history, though I imagine it was beyond 1994-level (and even Quake's 1996-level) hardware.

Forget voxels - how about sphere-based graphics rendering? That's definitely the right look for Doom.

(There really was at least one game that used spheres as a graphical basis, instead of polygons, sprites, rays or voxels - unfortunately I can't find it right now.)

More variety in monsters.

You see, in the original Doom (the first one), the monsters you fight are either zombies, which are weak but their attack is pretty much unavoidable, which makes it frustrating, Demons/Spectres and Lost Souls, that have a easily avoidable melee attack, and "fireball" enemies (Imp, Cacodemon and Baron of Hell), which are pretty much a joke, since you can just move a bit to one side to avoid their attacks. The only enemy which requires a bit of skill by itself is the Cyberdemon, and that is even questionable unless the terrain benefits the boss. The Spider Mastermind is a joke of a boss so I won't comment.

Now comparing to the new enemies, there is a stronger zombie, the chaingunner, who actually makes it a worthy opponent, and IMO requires more skill to fight than the Sergeant, who apparently shoots faster than the chaingunner, who takes some time until he starts blasting in your face. Then the "fireball" enemies, except the Hell Knight, all have some gimmick which makes their attacks harder to avoid. Either the Revenants, with their chasing missiles, the Mancubus with his spreaded attack, and the Arachnotron, that forces you to focus fire on it unless you want to receive insane amounts of damage. And then there is the Archvile which is one of the most original monsters ever made. The Pain elemental is a pain of a monster though.

Now what would be great is some monsters that require skill, that forces you to do something if you don't want to get hit, without being it almost impossible (chaingunners) or too easy (imps). That's what I like with some bestiary monsters, specially the Soul Harvester.

Creaphis said:

Forget voxels - how about sphere-based graphics rendering? That's definitely the right look for Doom.

(There really was at least one game that used spheres as a graphical basis, instead of polygons, sprites, rays or voxels - unfortunately I can't find it right now.)

You're thinking of Ecstatica and its' sequel. You seem to have forgotten your <sarcasm> tags there. Looking at screenshots, Doomguy's conveniently-exposed abs would have worked out great in an ellipsoid renderer :P

I remember thinking about the mechanics of doom and what I would have done if I had been making the game. A lot of these are very minor but I think if they were here they would be nice

1. I would have worked more on the camera. Like make it shake when you fire and take damage and such (I think quake has this). Also the weapon bobbing is kinda lame and I would have made that look a little more like the doomguy was running instead of slow-dancing.

2. Liquid splashes. I think someone in this thread already said that. Yeah I agree the liquids in Doom suck.

3. More destructable scenery.

4. Pistol should either shoot faster, or shoot in quick bursts, so that it is not quite as good as the shotgun but not useless (particularly for deathmatches)

5. Add a couple extra frames to the weapon animations. Especially the shotgun and chaingun. And those ejecting cases that were supposed to be in there too.

6. Keep the graphics for old lost soul and used it for a new monster.

7. Colored lighting (if it was used sparingly, not like PSX Doom)

8. Give all the monsters seperate hurt sounds. Or at least just the boss monsters.

9. Give monsters alternate death sequences, or a 50/50 chance of the death animation being mirrored so dead bodies don't look too uniform. (Since doom can already mirror the display of a sprite's rotations, I doubt adding this wouldn't have been hard)

I'm pretty sure there are some other things I wanted to mention but I can't remember them now.

Funny how many of them ended up in actual games later on. Heretic had water splashes (and deep water handling?), Duke3D had lots of destructible scenery, a fast pistol with reload pause, and I think colored lighting too.

I really like Ken Silverman's Build Engine, it had good advanced features (mirrors, swinging doors, inventory, flight) and still ran really fast. If Doom is 2.5D then build is like 2.75D :P

It also had that delicious 3D-view editor, which is something Doom was lacking for waaaay too long. I could make Duke maps as a pimply teenager, I still have no idea how people made such amazing Doom maps with the old map-layout-only DOS and Windows editors. Thank god for CodeImp.

Fix MEDIKIT YOU REALLY NEED and ouch face bugs.

Proper gib animation frames for all monsters...

Super Jamie said:

Heretic had water splashes (and deep water handling?)

(No.)

Wow really, I remember the big pool in E1M1 certainly feeling that way.

Ability to import custom sprites without IWAD merging or inclusion of ALL sprite entries in PWADs.

IWAD merging was always painful and tedious, especially in 1993 where you couldn't just keep multiple copies of a 10-20 MB file without a space premium.

The other method, including all sprite entries, either meant including many null/invalid entries and dummy graphics (so that it was effectively unusable but for total sprite replacements, that replaced every single item and monster), or, as certain not-so-legal PWADs did, just including the original Doom sprites too along with the rest. Worked just with a -file parameter, but the legality was dubious. Plus, it was only introduced in Doom v1.9

There were some replacements that allowed you to merge sprites ripped from your IWADs into the PWAD so you had a complete, legal set of sprites...but ah, what are we talking about, all of these methods were bullshit. I never quite got why sprites got treated that differently compared to textures, flats, maps and sounds (perhaps some memory optimization required them to be read and mapped flat out to memory?).

In any case, that's what I'd change.

Maes said:

Plus, it was only introduced in Doom v1.9

What was? Certainly not the ability to use sprites in PWADs.

Many of you should start thinking about 1993's capabilities. This thread, as usual degenerates into ridiculousness because people look at it from today's perspective. As such any such posts are of little interest.

I think the proper question should have been 'Given the capabilities of 1993's computers, if you could have added one thing to Doom, what would it have been?'

Also, think small not huge! I'm sure that'd be much more interesting.

Super Jamie said:

Wow really, I remember the big pool in E1M1 certainly feeling that way.

I think maybe it used one of those bleeding sector tricks for that? I think I remember sinking into the water a little bit too. Definitely not true deep water though.

It's a property of the water flats in Heretic. That would've been a nice effect to have in Doom, as simple as it was.

I don't think I'd have changed anything cosmetically. Again, making loading custom PWADS easier would be a start. Not as many people appreciate this with the advent of source ports that already do this, but it is worth nothing that we used to have to merge our custom wad with the iWAD in some cases, to get things to work.

Nomad said:

I think maybe it used one of those bleeding sector tricks for that? I think I remember sinking into the water a little bit too. Definitely not true deep water though.

No. Heretic have water splashes and (knee) deep water handling. Though it's only knee deep and it doesn't really effect the physics more than your sprite is clipped by the surface of the water and the view is slightly lower. It's strictly cosmetical. It's not a trick though. It's a hard coded feature of Heretic.

kristus said:

What was? Certainly not the ability to use sprites in PWADs.

The ability to use sprites and flats "directly" in external PWADs without permanently merging with the IWAD using e.g. DEUSF was not introduced until v1.9, and even then there were limitations: PWADs had to include replacement entries for ALL sprites and flats present in the IWAD in order for this to work.

As I said, this was not a problem for TOTAL conversions that replaced literally everything, or for modifications that were supposed to be played stand-alone, but partial modifications were troublesome: DEUSF was still needed to "rip" the missing flats and sprites from your IWAD to merge them into the so-called "external" data files.

I am not aware of a 100% legal PWAD (not IWAD) that has replacements for all sprites and flats, however there's the illegal WPDOOM, which actually contains all Ultimate Doom sprites and flats, in addition to its hmm..."new" ones.

Graf Zahl said:

I think the proper question should have been 'Given the capabilities of 1993's computers, if you could have added one thing to Doom, what would it have been?'

I think my proposal falls fully within those stricter boundaries. Unlike hardcoded SSEGS etc. limits which probably meant using more statically allocated RAM, the sprite limitation appears unjustified, and even the "fix" that didn't come until v1.9 is still a half-assed solution (with all due respect), unless someone can provide a technically valid explanation for the need to have ALL sprites and flats "en bloc" in the IWAD or later, in the PWAD, while sounds, music, maps and textures can be replaced randomly.

Maes said:

The ability to use sprites and flats "directly" in external PWADs without permanently merging with the IWAD using e.g. DEUSF was not introduced until v1.9,

Complete and utter baloney. I really can't recall this ever being the case, but I may be wrong and it is possible the support was added later. However I doubt it. But I can with a lot of confidence say that it was certainly available previous to 1.9.

There was this TC called Aliens TC that was released around the time of Doom2's release (v1.666) and it used DEUSF. It's also mentioned in the documents of AliensTC...

Olivier Montanuy said in ALIENTC.TXT:- DeuSF has built-in support for DOOM 1.2 1.666 and DOOM2 :-)[/B]

To point it out. DEUSF was released in -94, Doom v 1.9 was released in February 1, 1995.

On top of that. It doesn't merge with the IWAD. DeuSF just lifted the necessary sprites and flats from the IWAD to the PWAD to make the PWAD able to load in Doom. And yeah, it made it troublesome for mods. But TCs as well. Even if it didn't make the process feel as redundant in those cases.

kristus said:

Complete and utter baloney.

Since flaming you would be kinda out of my league, I suggest that you duke it out with Grazza on this one, mod 2 mod :-p

In any case, what Grazza and I stated still holds true (I was wrong on that old post BTW) and is one of the reasons I didn't release my cacodemon sprite with vanilla compatibility: I'd either have to include the whole DEUSF merry-go-round and associated scripts, or include ALL Doom sprites into the PLASCACO.WAD if I wanted it to work with vanilla "as is" (but then the archiver would pwn me).

I actually tried it and...no, it doesn't work as inteded without merging sprites from the IWAD (not to the IWAD). Unless I'd like to try the WPDOOM method ;-)

Source ports OTOH can import and use partial sprite files, but vanilla Doom just barfs on such partial mods. It need ALL sprites defines, on none, in PWADs.

It was a time when HD space was not at a premium either. it's one of the reason I didn't have many WADS left on many of my HDs- my laptop was the only one that still had some wads that to this day are NOT on the archive: ABYSS.WAD, BHS_DM2.WAD, and some of the alphas of DERELICT.WAD.

Here's the problem I have with the old mods like taht: it makes them unplayable today. I remember a pac-man mod I downloaded but instead of pac-man I got a shitload of folders with PCX graphics and a batch file with DeuSF or whatever. I still have no idea how to run that shit.

Heh I can hear you there. There was this weird mod based off a canadian university that had sprites in custom format files (not WAD), and which banged directly on the IWAD. No other way to play it but with DOS to at least run the customized merging tools.

In any case, sprite support (or lack thereof) was a big WTF. I'm still waiting for a technically valid reason to have it so crippled and half-assed throughout vanilla Doom's life.

Maes said:

Since flaming you would be kinda out of my league, [...]

Source ports OTOH can import and use partial sprite files, but vanilla Doom just barfs on such partial mods. It need ALL sprites defines, on none, in PWADs.

You could flame me. But I don't see why you should.

I've never said that Vanilla Doom can handle wads without the DEUSF route. What I contested was simply your absurd claim that the DEUSF route was something that was added in 1.9

It's interesting that you got that from Grazza. But reading his post I think your misinterpreted it a bit. Or that he worded it poorly.

Anyway. There is no beneficial to modders change in PWADS and Sprites handling between v1.9 and the versions preceding it.

Maes said:

In any case, sprite support (or lack thereof) was a big WTF. I'm still waiting for a technically valid reason to have it so crippled and half-assed throughout vanilla Doom's life.

I concur. But it should come as no surprise as I already mentioned that in my first post in this thread.

kristus said:

I've never said that Vanilla Doom can handle wads without the DEUSF route. What I contested was simply your absurd claim that the DEUSF route was something that was added in 1.9

Where did I ever say that? DEUSF was needed both post- and pre- v1.9, but for different reasons (and not DEUSF necessarily, but anything that could perform the same job, as some mods unfortunately did, destroying what little standardization there was). The only thing v1.9 added was the ability to use sprites in a PWAD directly under certain conditions which I described to the death already, and which were fairly restrictive to be of real benefit to anyone.

What I actually wrote was (with corrections in italic brackets for clarity)

Maes said:

The other method [AKA: not modifying the IWAD] , [which involved] including all sprite entries, either meant including many null/invalid entries and dummy graphics ... blah blah blah.... Plus, it was only introduced in Doom v1.9 [<-referring to the "other method" I've been talking about for all this paragraph]

The wording was poor, admittedly, but I would never ever think it could be TL;DR'ed to "DEUSF could only be used in Doom v1.9, NOT before, period".

kristus said:

Anyway. There is no beneficial to modders change in PWADS and Sprites handling between v1.9 and the versions preceding it.

Yup, in the end it boiled down to that :-( I'm sure there's some brilliant explanation out there somewhere, but none came forward with it yet.

I am really trying to make heads and tails of what you are talking about.

Point in case.
Do you or do you not claim that prior to v1.9 of Doom you had to modify the IWAD to use custom sprites?

I've not TL;DRed anything you've written in this thread. I had to read it multiple times just trying to make it clear what it is you're claiming exactly. (including what you claim you have explained. Because honestly. I don't see you explaining anything to any discernible degree)

Maes said:

I'm still waiting for a technically valid reason to have it so crippled and half-assed throughout vanilla Doom's life.

Fraggle explained it in a thread somewhat recently.

The short of it is that Doom loads all wads in sequence, starting with the iwad. Then when it searches for something, it looks backward to it from the very end. (Which means it actually starts at the *_END lump, for those things that are between matched *_START/*_END markers.)

Now sprites have to respect a specific format: four letters for the name, then frame identifier, rotation number, and optionally mirrored frame identifier and number. So, just for an example, E1M1 is not a valid sprite name.

Let's analyze what happens when the game looks for an unmodified sprite in a few distinct cases:
PWAD with S_START/S_END markers: reaches S_START, didn't find it, sprite is reported as missing.
PWAD with S_END but not S_START: reaches non-sprite lumps, result in an error.
PWAD without S_END: overlooks replaced sprites.
PWAD with S_END, S_START, and a copy of all original sprites: no problems.

Twice as fast weapon switching in DM.

kristus said:

Do you or do you not claim that prior to v1.9 of Doom you had to modify the IWAD to use custom sprites?

I do. Before v1.9 you had to modify the IWAD, and the tool to do it was DEUSF. Its name was DEUSF, and DEUSF was the name under which it was known.

At v1.9, you could not modify the IWAD if you included ALL sprites in a PWAD.

The tricky part is the DEUSF was used also in the second case (v1.9) to avoid distributing PWADs with ripped id sprites in order to have a "complete" set.

If I wanted to make my PLASCACO.WAD thing stand-alone in vanilla, I'd have to distribute a 5-so MB file with all the non-modified sprites too, or provide the user with tools to patch PLASCACO.WAD with resources from his IWAD.

So, pre v1.9:

PWAD + IWAD >---[DEUSF does its magic....}---> Modified IWAD -> launch Doom ----> have fun cleaning up afterwards.

va1.9:

Modified PWAD <---[DEUSF does its magic...}---< IWAD ---> just launch Doom with -file

or

PWAD with ALL sprite entries included ---> just launch Doom with -file. Look ma', no DEUSF ;-) (again, very few TCs were "total" to that point)