mikeday

Most source ports do widescreen by extending the horizontal FOV. It's only 90 degrees if you play at 4:3. At 16:9, the FOV is around 106 degrees. I think the large majority of players use widescreen aspect ratios these days and I'd guess the it's the same for mappers. Therefore I posit that the majority of playtesting and tuning is done with wider FOV as well. So if you like to play with wider FOV (either by way of widescreen aspect ratio or via a FOV scaling factor) I would argue you're most likely getting the dev's intended experience.

By default Woof outputs an aspect ratio corrected fullscreen image at your monitor's native resolution. The 400p is an internal rendering resolution only. It uses a combination of nearest-neighbor and linear scaling to go from 400p to the final image. It normally presents the image using non-square pixels. If you want square pixels (and a squashed image) you have to set "correct_aspect_ratio" in the config file to 0. EDIT: If you want nearest-neighbor used for all scaling set "Smooth pixel scaling" to "no".

Does your Homebrew symlink into /opt/homebrew/opt/openal-soft instead? If that’s not it, could you run brew reinstall openal-soft and look for a message telling what PKG_CONFIG_PATH should be set to? Thanks!

Actually I think I know what’s going on. Do you have a non-Intel device? It appears Homebrew uses a different path for Apple Silicon.

I don’t have my MacBook in front of me, but I’m wondering if reinstalling openal-soft via Homebrew might address the issue. It’s supposed to symlink the openal-soft files into /usr/local/opt/openal-soft but it seems like that didn’t happen for some reason.

This might be relevant: https://github.com/coelckers/prboom-plus/issues/524 In this instance the user found that Game Bar may have been the cause of the issue.

Here's what I see with Chocolate Doom. With the 1.9 Ultimate Doom iwad, everything loads without crashing, but there are some "column with a patch" warning messages on a few of the textures. There is corruption on the textures on the table left of the main building: If I use the 1.666 iwad, there are no warning messages and the table textures display properly. So I think v1.666 is necessary if you want the intended experience.

If you'd like you can also try out the latest snapshot of Crispy by running the following: brew unlink crispy-doom brew install --HEAD crispy-doom This will build Crispy Doom from the latest commit on master branch. If you want to switch back to the released Homebrew binary I think you just run: brew unlink crispy-doom brew link crispy-doom

What distro are you using? Nugget (and Woof!, Crispy, Chocolate, etc) use SDL. Your distro's build of SDL is preferring X11 over Wayland. You can change this by setting the environment variable SDL_videodriver to "wayland".

Items in DOOMWADPATH need to be separated by semicolons on Windows.

The short answer is yes, via the "-gameversion" argument. From the manpage:

I started looking into this but now that summer is underway I’ve been spending more time away from the computer. Maybe I’ll get back into it when the weather gets hotter. :-)

Source port developers are usually happy to elaborate on such questions but you may want to reconsider your approach here. Coming in here and dumping all over the port probably won’t have the effect you think it will.

Just remember ALL CAPS when you spell the man name

Try the latest Chocolate autobuild found here: http://latest.chocolate-doom.org/

As for what caused the issue exactly, it's difficult to say after the fact. If you happen to find a consistent way to reproduce the problem please share here or on Github so the developers can assess whether anything can be done in Crispy to address it.

Try Control Panel > Power Options and then select the "High Performance" power plan. Apologies if that's not the exact right sequence of menus, I'm not on Windows these days. :)

It sounds to me like you are being CPU limited. Maybe your processor is overheating and being throttled? Or perhaps a Windows power setting is slowing the CPU down?

What do you get with showfps if you turn off vsync in the Crispness menu?

What frame rate is reported when you use the “showfps” cheat?

In your crispy-doom.cfg file, what are the values for the following? crispy_fpslimit, force_software_renderer

Works fine on my end. What do you mean by "That or the weapon doesn't exist"? Are you using doom2.wad as the iwad?

I think if you always pass the "-noautoload" parameter then those directories should never get created.

I think SS_START and SS_END should also work. (Make sure they are uppercase)

Do you have S_START and S_END markers immediately before and after your replacement sprites? For example, as shown for a simple widescreen assets wad: