This is Woof! 14.5.0 (Apr 30, 2024)

[No-Man Baugh]

44 minutes ago, Alaux said:

Looking at the code, the only condition for it to be selectable is for the complevel to be vanilla; indeed, merely changing Default Compatibility Level to Vanilla in the Compatibility menu is enough to make it selectable on my end.

 

Are you sure that you're not loading any PWADs that could be forcing a certain complevel, or forcing the intercepts setting to a certain value? In autoload, maybe?

Nope, typing out the string `-noautoload -complevel 21` or `-noautoload -complevel 2`on plain-jane Doom2.wad still doesn't let me toggle intercepts overflow emulation on Woof 14.3.0

[rfomin]

4 hours ago, No-Man Baugh said:

The screenshot above was taken on compatibility level 3 in the Ultimate Doom, but also playing on complevel 9, 21, or with no parameter set in command-line at all: it still isn't selectable in those instances

 

I can confirm that it's only selectable if enable "vanilla" complevel from the menu. But I guess we should make it selectable if the user chooses complevel from the command line.

 

Intercepts overflow emulation only works for "vanilla" complevels (2, 3, 4).

Edited March 17, 2024 by rfomin

[No-Man Baugh]

2 minutes ago, rfomin said:

 

I can confirm that it's only selectable if enable "vanilla" complevel from the menu. But I guess we should make it selectable if the user chooses complevel from the command line.

 

Intercepts overflow emulation only works for "vanilla" complevels (2, 3, 4).

Oh the though never even crossed my mind to switch complevels in-game, I'm just so used to using the command-line that I thought it would work the same. That should totally be accessible for anyone using parameters

While we're on the topic of compatibility options I got a question: Any reason why "Improved Hit Detection" is hard-disabled on vanilla comp? seems about as anachronistic as any of the other options like auto-SR50 or vertical aiming and not as redundant as Intercepts Overflow emulation is on higher port comps

[rfomin]

26 minutes ago, No-Man Baugh said:

Any reason why "Improved Hit Detection" is hard-disabled on vanilla comp?

 

It just doesn't work, it's bugged with the vanilla algorithm. It could probably be fixed, but there's not much demand for it (why fix hit detection and use a vanilla complevel?).

[No-Man Baugh]

Just now, rfomin said:

 

It just doesn't work, it's bugged with the vanilla algorithm. It could probably be fixed, but there's not much demand for it (why fix hit detection and use a vanilla complevel?).

fair enough, most of the changes made in MBF and MBF21 do boil down to bugfixes anyways

[s4f3s3x]

Is there a difference between raw / interpolated mouse input when playing capped at 35fps?

[ceski]

5 hours ago, s4f3s3x said:

Is there a difference between raw / interpolated mouse input when playing capped at 35fps?

 

If raw input is disabled and mouse acceleration is enabled, then an additional config-only setting is used: "mouse_acceleration_threshold". This is carried over from Chocolate Doom and means that every tic (1/35th of a second) the game checks how far the mouse moved (counts). If the mouse moved more than the threshold value (default is 10 counts), mouse acceleration is applied. If raw input is enabled, "mouse_acceleration_threshold" is ignored and treated as zero, therefore mouse acceleration behaves as an overall sensitivity multiplier only.

 

Here is an interactive plot that shows exactly how mouse acceleration behaves in Chocolate Doom (or Woof with raw input disabled).

[s4f3s3x]

@ceski Thank you. I suppose then that setting interpolated and capping at 35 (with acceleration) in Woof is equivalent to simply cap in Crispy?

 

I find the new mouse feeling simply perfect when raw input is applied with uncapped framerate. A real pleasure, to me it feels even better than DSDA. Unfortunately, it seems to be extremely power hungry on my MacBook, eating up a lot of battery even in "energy saving" mode. That's why I cap to 35 if I'm not playing home with a recharger.

[ceski]

12 hours ago, s4f3s3x said:

Unfortunately, it seems to be extremely power hungry

 

Is that the case with uncapped framerate in general (e.g. in Crispy Doom or DSDA-Doom too) or are you implying this is specific to Woof with raw input and uncapped framerate? If it's the later, are you saying that disabling raw input with uncapped framerate draws less power somehow? That doesn't make sense. Are you playing at a reasonable resolution scale? Do you have vsync on? What does the framerate and resolution show when you type "rate"?

Edited March 19, 2024 by ceski

[Ar_e_en]

While testing between 14.0.0 and 14.3.0 - I find that specific wads cause 14.3.0 to crash whenever a map change occurs. The crash usually occurs after an intermission screen. While I can exit a map and get the intermission screen with all the stats being counted up, the moment I press use/fire to change the last map stats screen to the brief introduction screen for the next map - the game crashes without showing the introduction screen. Also, pressing the "warp to next map" button or using "idclev" also causes the game to crash (at least sometimes), but using the "-warp" parameter works fine. I think that this might have something to do with the graphics of the map titles, but I'm not sure because I remember experiencing this sort of issue on an older version of Woof, but it eventually got fixed there, so I don't know what to think. 

[liPillON]

20 minutes ago, Ar_e_en said:

specific wads

which one?

 

[CacoKnight]

Nugget did it once for me too but only before the new settings (after the merge) were applied to the .cfg, once I did a clean exit and made the port save all the setting it never crashed again.

[rfomin]

52 minutes ago, Ar_e_en said:

specific wads

 

Does this WAD happen to have non-MIDI/"silent" music lumps? More information is needed to reproduce the issue.

[Ar_e_en]

2 hours ago, liPillON said:

which one?

 

I was testing the private beta release of Pirate Doom II and Woof 14.0.0 was able to play all the maps fine, however - all the MP3 music tracks didn't play for some reason.

Woof 14.3.0 on the other hand - kept crashing between map changes, and all the MP3 tracks also didn't play. 

 

2 hours ago, rfomin said:

 

Does this WAD happen to have non-MIDI/"silent" music lumps? More information is needed to reproduce the issue.

It has "silent" music lumps, but all the silent music lumps from what I can tell are MIDI lumps. 

 

I'm going to do some tests with a bunch of music files (Midi, Ogg and Mp3) in a custom test wad. I'll report back in a few minutes.

[Ar_e_en]

I made a test wad where Map 01 and 02 have MP3 music tracks. In all of the tests - music didn't play. Here's what I found:

 

* Woof 14.0.0 (Tested with both Fluidsynth and OPL3)
    - Map 01 can be accessed through the menu.
    - Map 01 and 02 can be accessed through "-warp", "idclev" and map exits. 

 

* Woof 14.3.0 (Fluidsynth)
    - Map 01 can be accessed through the menu. 
    - Map 01 and 02 can be accessed through "-warp".    
    - Map 01 and 02 CAN NOT be accessed through "idclev".    
    - Map 02 CAN NOT be accessed through map exits.    

 

* Woof 14.3.0 (OPL3)
    - Map 01 CAN NOT be accessed through the menu. 
    - Map 01 and 02 can be accessed through "-warp".    
    - Map 01 and 02 CAN NOT be accessed through "idclev".    
    - Map 02 CAN NOT be accessed through map exits.    

 

Here's my testing wad: MP3_CRASH_test_wad.zip
    

[plums]

@Ar_e_en to be clear, this is with the Windows binaries linked from here, right? Which one (32-bit or 64-bit) are you using?

[mikeday]

Re: MP3s not playing - If you're on Linux or otherwise building from source, libsndfile needs to be at least version 1.1.0 to support MP3 playback.

Edited March 18, 2024 by mikeday

[s4f3s3x]

9 hours ago, ceski said:

 

Is that the case with uncapped framerate in general (e.g. in Crispy Doom or DSDA-Doom too) or are you implying this is specific to Woof with raw input and uncapped framerate? If it's the later, are you saying that disabling raw input with uncapped framerate draws less power somehow? That doesn't make sense. Are you playing at a reasonable resolution scale? Do you have vsync on? What does the framerate and resolution show when you type "idrate"?

 

@ceski Yes, it's exactly what I'm saying. It might sound weird, but that's what I witnessed so far: uncapped in Crispy and DSDA doesn't seem to draw battery power as much as Woof does with raw imput + uncapped. To me this isn't much of a surprise, to be honest: back when Woof didn't have the option to set custom uncapped framerate, I experienced my laptop becoming actually hotter! At the time my MacBook Pro M1 was brand new, so I'd tend to exclude a machine's fault.

 

Anyway, be it with Crispy, DSDA or Woof I always play 768x400, 280 fps, vsync OFF.

 

 

[ceski]

21 minutes ago, s4f3s3x said:

280 fps, vsync OFF.

 

Any particular reason for these settings? Also, have you actually tried raw input disabled + uncapped and confirmed there is lower power draw? How do you measure it?

Edited March 18, 2024 by ceski

[s4f3s3x]

1 minute ago, ceski said:

 

Any particular reason for these settings? Also, have you actually tried raw input disabled + uncapped and confirmed there is lower power draw?

 

It's a strange question, I have to admit. I use the exact same settings for all the ports.

 

Vsync ON makes my mouse feel devoid of control, sluggish and unprecise (and this is true for other games as well, like Quake for example). 280 fps is the OG 35fps x8, which sounds nicer because I like to play with 2x resolution (or a lot less frequently, 4x). But apart from this sillyness, it's just because it looks and feel very smooth on my monitor and for the mouse. I also can confirm raw input disabled + uncapped mitigates this issue, and it's comparable to Crispy and DSDA in terms of power draw (which is, minimum); only reason I don't use it it's because it feels wonkier. Your work with raw imput + uncapped is and feels perfect, on the other hand.

 

So, yeah... these settings simply grants me the best experience.

[ceski]

41 minutes ago, s4f3s3x said:

I also can confirm raw input disabled + uncapped mitigates this issue, and it's comparable to Crispy and DSDA in terms of power draw (which is, minimum);

 

How did you measure it? I'm not as familiar with system monitoring tools for macOS. For comparison, here are my results on a decent PC:

 

 

For this test scenario, Woof is actually the most efficient overall for my system and the raw input setting doesn't make a difference. In any case, thanks for the feedback.

[s4f3s3x]

8 minutes ago, ceski said:

 

How did you measure it? I'm not as familiar with system monitoring tools for macOS. For comparison, here are my results on a decent PC:

 

 

For this test scenario, Woof is actually the most efficient overall for my system and the raw input setting doesn't make a difference. In any case, thanks for the feedback.

 

The small battery icon on the upper side of the screen of MacOs regularly tells you what currently executing application is the most power consuming at the moment; to give you an idea, tipically this is Google Chrome. One time I saw instead it was RocketLauncher (the app which I use to run Woof).

 

Anyway, I wouldn't consider this a real issue nor something to fix. Apart from this occurence, as I stated before, this new mouse work is excellent and I'm enjoying a lot! I am actually more bothered by the camera notch covering a part of the game image in exclusive fullscreen mode, but this is also a very specific MacBook issue :' ))

[rfomin]

13 hours ago, Ar_e_en said:

I made a test wad where Map 01 and 02 have MP3 music tracks. In all of the tests - music didn't play.

 

Thanks for the test map. It looks like you're using Linux with an old libsndfile library that doesn't support MP3. Indeed, there were changes in Woof 14.2.0 that caused crashes when music lumps were not recognized, this has recently been fixed. Could you try AppImage from this page? It should work.

[CacoKnight]

I don't know what the heck @ceski did with the mouse thing exactly but let me tell you guys, I've played A LOT of FPS games in my life, growing up more than recently, but this Woof! is the absolute best mouse to gun "feel" I've ever experienced, ever. You can't even explain it to people until they try it, it's just so refreshing and responsive it puts everything else to shame. Congrats, congrats, congrats to @fabian, @rfomin, @ceski and everyone involved. Wow.

 

Will Crispy have this too?

[Ar_e_en]

15 hours ago, mikeday said:

Re: MP3s not playing - If you're on Linux or otherwise building from source, libsndfile needs to be at least version 1.1.0 to support MP3 playback.

15 hours ago, plums said:

@Ar_e_en to be clear, this is with the Windows binaries linked from here, right? Which one (32-bit or 64-bit) are you using?

I was using the Linux Appimage version of 14.3.0 (as far as I know - there is only a 64 bit version of that) and I checked my systems version of "libsndfile" - it was 1.2.0. 

 

9 hours ago, rfomin said:

 

Thanks for the test map. It looks like you're using Linux with an old libsndfile library that doesn't support MP3. Indeed, there were changes in Woof 14.2.0 that caused crashes when music lumps were not recognized, this has recently been fixed. Could you try AppImage from this page? It should work.

I don't know if I'm blind or stupid, but I went to that link and as far as I can tell - there is no download link for an updated Appimage. The thing that looks like a download listing just seems to be some static text.

 

However, I do have some good news!

I did notice that the main master version of Woof had some minor file updates from 4 hours ago, so I tried compiling the master version and that version actually works now! All of the MP3 files now play and I can access the maps that use them in any way. 

 

[rfomin]

7 hours ago, Ar_e_en said:

I was using the Linux Appimage version of 14.3.0 (as far as I know - there is only a 64 bit version of that) and I checked my systems version of "libsndfile" - it was 1.2.0. 

 

Our AppImage of 14.3.0 is broken, we are building it on Ubuntu LTS 22.04 (this is what is provided on GitHub), witch has an old libsndfile. Anyway, we fixed these issues, thanks for testing.

[fabian]

30 minutes ago, Ar_e_en said:

I was using the Linux Appimage version of 14.3.0 (as far as I know - there is only a 64 bit version of that) and I checked my systems version of "libsndfile" - it was 1.2.0. 

 

If you are using the AppImage, then the libsndfile library embedded into this AppImage is used. And in this case, that is (no, "was", see below) libsndfile 1.0.31 from Ubuntu 22.04 which is the system used to build the AppImage.

 

30 minutes ago, Ar_e_en said:

I did notice that the main master version of Woof had some minor file updates from 4 hours ago, so I tried compiling the master version and that version actually works now! All of the MP3 files now play and I can access the maps that use them in any way.

 

If you compile from the sources yourself, your system's own libsndfile library will be used anyway.

 

The commit that you have seen was to update the libsndfile package in the virtual environment that is used to build the AppImage to version 1.2.0 from Ubuntu 23.04. This means that the new library version with MP3 support will get embedded into the AppImage, but nothing else. This doesn't have any impact if you compile the port from its sources on your own system.

[Ar_e_en]

So, the newer Appimage versions after 14.3.0 will have an up to date version of that sound library.

I'll stick with the compiled version for now, but once a newer release gets uploaded - I'll go back to the Appimage version again.

[CacoKnight]

Sorry if this was asked 200 times before but can I have a technical explanation on fullscreen vs exclusive fullscreen? Which one is "better"? Did anyone perform tests/benchmarks? Thank you.

[dasho]

26 minutes ago, CacoKnight said:

Sorry if this was asked 200 times before but can I have a technical explanation on fullscreen vs exclusive fullscreen? Which one is "better"? Did anyone perform tests/benchmarks? Thank you.

 

Exclusive fullscreen means the program is allowed the change the actual resolution of your display among other things, which if you've ever done this with a low resolution will leave your windows jacked up when you exit the program. Historically this offered performance improvements but I don't know if that's necessarily the case these days.

 

Fullscreen, if it's what I'm thinking, is sometimes called "Borderless" or "Windowless" fullscreen where it is essentially a full screen window but does not gain control over your display settings in the same manner.

Edited March 20, 2024 by dasho