Things about Doom you just found out

[Cacockcansukmycok]

Hellbent said:

A cacodemon can directly kill itself: https://www.youtube.com/watch?v=_slF2ne_drQ

works Only with a PATCH Hacker Lmao.

[Gez]

Works only with an old version of the engine, more exactly. They added a protection against self-infight at some point.

[ETTiNGRiNDER]

Gez said:

Works only with an old version of the engine, more exactly. They added a protection against self-infight at some point.

Some point after the Raven codebase split, since this can happen in vanilla Hexen under the right circumstances (a monster with a fire-based attack incinerating a tree/bush in front of it and taking the splash damage. IIRC freaky attack targets can also happen in the Chantry level of Deathkings where there's that trap near the start which blows up the trees, and the monster seems to get angry at... the map spot that spawns the fireballs I guess? Not totally sure without trying to get it to happen again.)

[Crunchynut44]

antares031 said:

I didn't know the original doom had this texture until now:

http://puu.sh/rIBny/a72739d657.png

It's only used in the caco cage on E2M3.

Though wants it meant to be exactly?

[Linguica]

38_ViTa_38 said:

If you touch blockmap block's border (with .000000 coordinate), you can preserve your momentum without 14.5 cap, even north or east. An example of this is doom2.wad MAP20 linedef 438.

Can you maybe explain this a little more?

[Doomkid]

In Doom, animated sprites tend to 'dance' on the spot. For example, run Chocolate Doom (with doom2) and warp to map23. When you stand a few meters away from the flaming barrel, you can notice the whole can sort of twitching in place, which obviously looks kind of crappy.

I've finally figured out what causes this after years of headscratching - Each individual frame needs to have the exact same dimensions, merely matching each frame of animation up on the x/y axis isn't good enough to prevent the sprite from 'dancing'. For example, the first frame of the flaming barrel (FCANA0) is a 37x53 image. The next frame however is a 34x53 image, with the 3rd and final frame being 36x51. If we expand each frame's border to be a uniform 37x53 and then line them up accordingly, the sprite 'dancing' is fixed!

I'm wondering if this is documented elsewhere? Surely it must be, but for me, this is a new discovery!

[Da Werecat]

I think it should only be noticeable in very low resolutions.

[kb1]

Doomkid said:

In Doom, animated sprites tend to 'dance' on the spot. For example, run Chocolate Doom (with doom2) and warp to map23. When you stand a few meters away from the flaming barrel, you can notice the whole can sort of twitching in place, which obviously looks kind of crappy.

I've finally figured out what causes this after years of headscratching - Each individual frame needs to have the exact same dimensions, merely matching each frame of animation up on the x/y axis isn't good enough to prevent the sprite from 'dancing'. For example, the first frame of the flaming barrel (FCANA0) is a 37x53 image. The next frame however is a 34x53 image, with the 3rd and final frame being 36x51. If we expand each frame's border to be a uniform 37x53 and then line them up accordingly, the sprite 'dancing' is fixed!

I'm wondering if this is documented elsewhere? Surely it must be, but for me, this is a new discovery!

That sprite commits the sin of mixmatching even and odd dimensions. In other words, the 34 and 36 would be ok, but the 37 needs to be expanded to 38. I *think* the combination of that, and proper offsets will fix it. Think of it in terms of trying to find the middle of the sprite. For odd dimensions, the middle can fall in the middle of a pixel, but for even dimensions, the middle is on the edge of 2 pixels, which cannot be reconciled, without aliasing occurring. But, honestly, I am not sure if that fixes it in every single case, cause Doom, with its fixed-point madness, is a strange beast. It's worth a test.

[vita]

Linguica said:

Can you maybe explain this a little more?

Another example is doom2 MAP03, where you start near the wall. The blockmap looks like this:


And you get this in XDRE (instead of losing Y momentum if it's less than -14.5):

[Doomkid]

kb1 said:

That sprite commits the sin of mixmatching even and odd dimensions. In other words, the 34 and 36 would be ok, but the 37 needs to be expanded to 38. I *think* the combination of that, and proper offsets will fix it. Think of it in terms of trying to find the middle of the sprite. For odd dimensions, the middle can fall in the middle of a pixel, but for even dimensions, the middle is on the edge of 2 pixels, which cannot be reconciled, without aliasing occurring. But, honestly, I am not sure if that fixes it in every single case, cause Doom, with its fixed-point madness, is a strange beast. It's worth a test.

So that's what it is, the odd numbers in the dimensions, not necessarily the dimensions of each individual frame being different - Very interesting, thanks for clarifying that!

[Avoozl]

Crunchynut44 said:

It's only used in the caco cage on E2M3.

Though wants it meant to be exactly?

Well, it looks like two pipe valves to me, or maybe it's some kind of door mechanism.

[Pedro VC]

Stimpack means stimulation pack.

[Gez]

Stimulants, more probably.

[scifista42]

antares031 said:

http://puu.sh/rIBny/a72739d657.png

Avoozl said:

Well, it looks like two pipe valves to me, or maybe it's some kind of door mechanism.

The rectangle in the middle-left of the texture, bordered by those black seams, looks like a (small) door, so I'm inclined to think it's a door mechanism with the wheels as locks, too. The door possibly leads into a barely-human-sized shaft / pipe, or just into a small locker room with minor tech props. It could even lead into a small locker room with some small pipes inside it, and the wheels aren't meant to open the door, but to directly control the flow of some liquid in those small pipes.

[vita]

I just noticed the borders near the first door in doom2 MAP18 are different:

[damerell]

Doomkid said:

In Doom, animated sprites tend to 'dance' on the spot. For example, run Chocolate Doom (with doom2) and warp to map23. When you stand a few meters away from the flaming barrel, you can notice the whole can sort of twitching in place, which obviously looks kind of crappy.

https://www.doomworld.com/vb/wads-mods/62403-doom-2-minor-sprite-fixing-project-v1-7-release-updated-7-28-16/ fixes most of these. If they haven't addressed the flaming barrel yet I daresay they would be happy to.

[Havoc Crow]

I've only just taken note of the big, prominent numbers on the crate textures. All brown crates are marked with a "3", large/wide gray crates are "2" and medium gray crates (from the CRATELIT texture) are marked with "1". (The CRATINY has no discernable number.)

[Revenant100]

Doomkid said:

In Doom, animated sprites tend to 'dance' on the spot. For example, run Chocolate Doom (with doom2) and warp to map23. When you stand a few meters away from the flaming barrel, you can notice the whole can sort of twitching in place, which obviously looks kind of crappy.

Do you have an example player position and specific barrel where this issue is consistently reproducible? I'd like to investigate this matter myself, but even in Chocolate Doom, I could not find a spot in MAP23 that caused any of the flaming barrels to appear to jitter in place.

[Koko Ricky]

antares031 said:

I didn't know the original doom had this texture until now:

http://puu.sh/rIBny/a72739d657.png

I was thinking about this recently. Is it used anywhere in the original Doom??

[Use]

GoatLord said:

I was thinking about this recently. Is it used anywhere in the original Doom??

E2M3 comes to mind, in the slime filled cacodemon cage.

[Doomkid]

Revenant100 said:

Do you have an example player position and specific barrel where this issue is consistently reproducible? I'd like to investigate this matter myself, but even in Chocolate Doom, I could not find a spot in MAP23 that caused any of the flaming barrels to appear to jitter in place.

This is so strange, I must have been getting it mixed up with something else - Perhaps I was playing in a port with a different resolution? I'm so certain I've seen plenty of sprites jitter in place while animating even in vanilla/chocolate Doom.. I'll investigate this further and let you know what I find. I swear this is a real thing even though I can't find it now.

EDIT: Okay, maybe it has something to do with resolution? I play in 800x600 in Zandronum (ZDoom) and that's where I see it, though I'm sure I've seen it even in other source ports.



Look closely at the 1st and 3rd firesticks. It's affected by turning your view left and right as well. I haven't checked if using a sprite with even dimensions for each frame fixes it in ZDoom, I'm really curious what causes this. Just Doom's pixel drawing logic I guess?

[Maes]

Well, even by slowly creeping towards certain sprites, one can notice that the scaling is not always perfectly symmetrical, and the drawing is not homogeneous. E.g. one column of the sprite may "pop" or "grow" before the others to a greater pixel width, and it may be on one side of the sprite, giving it the appearance of "breathing" or "smearing".

Animated sprites just make it more obvious in some situations. Resolution does play a role, in the sense that the object must be at just the right distance to see the column "popping", and with lower resolutions, the object can be closer before it happens.

[scifista42]

^ Yeah, but it's expectably unavoidable (therefore easily acceptable) that sprites might slightly jitter as the size of their pixels changes while you're moving around. It's the fact that the sprites jitter while you are standing perfectly still and while the size of their pixels should remain the same that's strikingly odd and feels wrong.

[Maes]

Well, by animating they instantly change one of the parameters that's responsible for the precise distance at which this kind of "popping"/"jittering" occurs: their dimensions and drawing offsets. Even if you had a sprite "animate" by simply shifting the offsets of one fixed picture, you'd still see a distortion as it moved left-right during its animation cycle.

So, some frames may look OK, and others will not, for the "same" sprite. Non-animated ones have only the regular scaling "popping" to worry about, animated ones with changing sizes also have to face jarring differences between their frames.

Doom's rendering view is not homogeneous either, but the view is distorted through a horizonal "fisheye" effect, so even if you looked dead-center at e.g. a bunch of identical wall textures, sprites etc. all sitting on the same line, with the player's view perfectly perpendicular to the line, they would scale slightly differently depending of where they'd be on the screen's x coordinate, even the ones closest to the center, where the distortion would be minimal. Moving perfectly parallel to said line would result in a kind of fluid distortion in the rendered columns, as they crossed specific points on the screen.

Animated sprites just subtly play with the tolerances of the renderer and fixed point arithmetic without the player even moving or facing such constructed scenarios.

[Revenant100]

Doomkid said:

EDIT: Okay, maybe it has something to do with resolution? I play in 800x600 in Zandronum (ZDoom) and that's where I see it, though I'm sure I've seen it even in other source ports.

http://www.doomshack.org/~doomkid/stor/jitter.gif

Look closely at the 1st and 3rd firesticks. It's affected by turning your view left and right as well. I haven't checked if using a sprite with even dimensions for each frame fixes it in ZDoom, I'm really curious what causes this. Just Doom's pixel drawing logic I guess?

After some preliminary testing, I believe this issue is inherent to ZDoom and its derivative engines. However, it doesn't heavily manifest in GZDoom, and the minor jittering visual artifacts there are possibly unrelated, so it's probably something solely to do with ZDoom's software renderer.

While slight jittering while the sprites are rescaling based on the player's position is to be expected, I was not able to reproduce anything as extreme as jittering even while standing still in Chocolate Doom, Crispy Doom, or PrBoom+ (testing different resolutions). Hence, this problem looks to be ZDoom-only. I believe this is a reasonable assertion to make since, as far as I know, ZDoom's software renderer is indeed significantly modified versus other source ports.

Just out of curiosity, I downloaded and tested the old ZDoom versions 1.22 and 1.23, and I found that the "jittering while standing still" problem does not occur there. I think this safely narrows the problem down specifically to only ZDoom and its derivatives that was introduced at least somewhere after 1.23.

I'd report this bug on the ZDoom forums, but it seems fairly nebulous in scope.

To illustrate this issue, here's a comparison between ZDoom 1.23 and 2.8.1 while standing from the exact same position and recorded in the same resolution (800x600):

[Doomkid]

Very interesting, nice detective work man! I've been wondering about that one for quite some time now.

[kb1]

I have seen ZDoom's renderer add an extra sliver of wall in much older versions. It is definitely an aliasing issue. It's almost like there are more than one set of code determining how to calculate sprite offsets vs. drawing them. One set of code thinks the stick is one pixel wide, and the drawing code thinks it's 2 wide. Maybe floating point in one, fixed point in another. I'm not sure - I haven't looked at ZDoom's renderer for years. But, that is definitely a bug that can be fixed - no doubt about it. Might be slower though.

[Bauul]

Today I discovered that even if you spend days and days double, triple and quadruple checking your about-to-be-released map, the version you upload to ModDB and promptly get 1,500 downloads will have a level-breaking bug in it.

God damnit!

[kb1]

Bauul said:

Today I discovered that even if you spend days and days double, triple and quadruple checking your about-to-be-released map, the version you upload to ModDB and promptly get 1,500 downloads will have a level-breaking bug in it.

God damnit!

It's called Murphy's Law, and it's a bitch!

[MTF Sergeant]

That the megasphere greatly improves both armor and health.