Da Werecat

I like it.

Must be something with the voodoo closets. If you only need to modify objects, it might be a good idea to do that without recompiling the nodes. I don't know if any editor allows to do that easily, but it could be done manually by combining lumps from the saved map and the unmodified map.

Technically, it should be better, especially with Doom's asinine palette. But simple environments can benefit from some visual noise to make them appear less artificial. It's a trade-off.

I don't understand what people see in hardware rendering with no features to actually make it look good (think GZDoom), but it's probably too late to force it out.

"Hello, you absolute legends. Doom 2 is officially dead."

Is stream-sniping a real issue around here?

Is it meaningful to kill the arch before the IoS?

That's just how Doom ports work, unfortunately. You can never fully control something as a mod author. I doubt there's an easy way to fix this after so many years of accumulating features.

I think it's too fat to fit onto the ledge leading away from the door. Wasn't there a speedrunning trick to hop onto the platform and bypass the door?

Both screen and weapon bobbing should change with speed, but they're pretty much already maximized when "walking". The system might've been tuned when the game was supposed to have slower characters. I usually reduce the value a bit in ZDoom-derived ports to feel the difference between slow and fast movement.

I don't really know what settings Valiant was tested with, so I can't help with that, unfortunately. The safest way is probably to reset all settings. It can be done by deleting the *.cfg files.

Have you tinkered with any compatibility options in the menu? MBF allows for some variation in behavior based on those. Demos include options info, so their playback is not affected.

This is a pronounced issue when sprite filtering is enabled (whichever setting affects first-person weapon sprites). First time I'm seeing it on an unfiltered sprite though.

Whoa, there's a cylindrical sky mode now? I missed that.

It involves a colormap hack. GL doesn't care about the colormap in this port. This effect is easy to detect though, so hardware emulation should be possible.

But... they already have it. As Chocolate Doom.

It's been a while since I looked at vanilla state table, but there could be enough unused states to implement the fix. However, it would break demos. Since the function also detects the attack button, choppy idle animation makes the chainsaw less responsive than other weapons. Something to keep in mind.

Swaying works by calling a function that repositions the sprite (among other things). For most weapons, this function is being called every tic when the weapon is idle. This is achieved by having one idle state that loops on itself, and its duration is 1 tic. However, chainsaw is unique in that it has an animated idle sequence. That animation is choppy, and you can't call any functions between states, thus bobbing is choppy as well. It's possible to fix this in DEHACKED, but it requires additional states and some care. Engine-side solution would require overriding vanilla logic for bobbing and making it independent from the aforementioned function. It sort of already is, since there's an option to always sway the weapon, even when it's firing, but I just checked and it doesn't affect the chainsaw idle sequence.

It works for barons, but not so much for knights, IMO.

https://drive.google.com/file/d/1Fsr47v977bJYPYJdnuQqdv7uezZV9ihK/view?usp=sharing Whacked together some translation tables. The current green blood is very bright, often brighter than fireballs if the room isn't too dark. Also, both green and blue gibs have pink spots due to the font tables being tuned to a very specific set of graphics. Darkening the former comes at a price of introducing color loss, since the range is shrinking, so a compromise between tone and quality had to be found. I don't mind the result though. Pink spots were replaced by less saturated greens, mirroring how POL5A0 always looked in red. Caco gibs were kinda interesting though, so not a whole lot was changed other than the primary color affecting the entire palette. In the wad, the tables are named the same as the font tables for testing purposes, and the interface graphics survive reasonably well from what little I saw. Still, not the best idea to use this as a permanent replacement.

I think what they mean is that it looks blurry after being resized. Probably due to being resized by the monitor rather than the program.

I figured since the game logic has to run at 35 Hz and uncapped framerate enables some rendering interpolation, it might introduce some discrepancies. Some people complained about that in regards to ZDoom. I never noticed it personally; in fact, ZDoom always had the greatest mouse handling for me. Tried it myself and can't see any difference with vsync off. I'm really curious about this issue because people's accounts vary so wildly. Hard to ascribe it to perception. Even with vsync and uncapped framerate on, the handling feels perfectly agreeable to me.

Does disabling uncapped framerate change anything?

The core logic doesn't care, but it also doesn't care if you give it uncapped movement in any direction, if what I remember about that driver discussion is accurate. So there have to be standards, and speedrunning already has some arbitrary ones in place. It's not something I care about though. There's already an easier way to do SR50 that's discouraged in recording. So it's more of an organizational issue.