This is Woof! 14.3.0 (Mar 15, 2024)

[fabian]

22 minutes ago, Graf Zahl said:

Why are you releasing this only as a 32 bit build?

Because I'm lazy and the build/release process isn't automated yet. I still manually create these Zip releases. 

[Revenant100]

7 hours ago, VGA said:

What happens if you timedemo it against prboom+, which of these is faster?

Well, I know of no better ultimate stress test than the ultimate stress test! And, unfortunately, Woof!'s performance is severely lacking compared even to just the original WinMBF, let alone PrBoom+.

 

As the baseline, WinMBF loads MAP01 of 100krevs.wad in ~30 seconds. During the height of the action, gameplay runs at ~1-2 SPF. Not ideal, but tolerable. On the other hand, Woof! loads MAP01 of 100krevs.wad in ~2 minutes. During the height of the action, gameplay runs at ~12-20 SPF, a terribly drastic reduction. Here's a video I recorded showing this comparison:

Note I was running 1.0.0 at the time of recording a few hours ago, but I've just repeated this test in 1.0.1 and can confirm that there's no improvement in this regard. Based solely on performance, the original WinMBF is the much superior choice over Woof! by a considerable margin, and of course both pale in comparison to PrBoom+.

[drfrag]

 But on a real use case i don't think there will be much of a difference besides i suspect it mostly has to do with the compiler and options used.

 That said both Crispy and Woof crash for me, have you used the -mb parameter? RUDE passes the test BTW and loads instantly (it's simpler), on UM i got a Z_Malloc error but runs with -mb 256. And no that doesn't mean 200K revenants as the algorithm won't spawn them if there's not enough space.

 I see max MAXVISSPRITES is capped at 4096 and that's for a reason.

[chungy]

7 hours ago, Graf Zahl said:

Why are you releasing this only as a 32 bit build?

Why would a port like this need a 64-bit build?

[Graf Zahl]

Because it is faster, maybe? For a software renderer the higher number of CPU registers will result in a noticable performance gain.

 

The real question is, why is 32 bit still considered essential on Windows when on all other platforms it has been essentially retired?

 

[chungy]

Huh, I don't know if that's actually true. 32-bit EXEs generally work on every Windows install, and especially when programs don't need multiple gigabytes of RAM, they're just the default really.

 

@Revenant100 Maybe you could try this build for performance? Same compiler for both 32- and 64-bit EXEs, hopefully they work (as fabian mentioned, the build system is rather broken so... it's being done manually); should be good for doing direct comparisons.

 

https://chungy.keybase.pub/woof-windows-bin.zip

[Redneckerz]

3 hours ago, Revenant100 said:

Well, I know of no better ultimate stress test than the ultimate stress test! And, unfortunately, Woof!'s performance is severely lacking compared even to just the original WinMBF, let alone PrBoom+.

 

As the baseline, WinMBF loads MAP01 of 100krevs.wad in ~30 seconds. During the height of the action, gameplay runs at ~1-2 SPF. Not ideal, but tolerable. On the other hand, Woof! loads MAP01 of 100krevs.wad in ~2 minutes. During the height of the action, gameplay runs at ~12-20 SPF, a terribly drastic reduction. Here's a video I recorded showing this comparison:

Note I was running 1.0.0 at the time of recording a few hours ago, but I've just repeated this test in 1.0.1 and can confirm that there's no improvement in this regard. Based solely on performance, the original WinMBF is the much superior choice over Woof! by a considerable margin, and of course both pale in comparison to PrBoom+.

I can't verify what settings you used, but i do want to point out that Woof! has a toggle for Hardware Acceleration through SDL.

[fabian]

4 hours ago, Revenant100 said:

On the other hand, Woof! loads MAP01 of 100krevs.wad in ~2 minutes.

 

If you grant it some more memory, e.g. '-mb 256', it loads the map within seconds. Also, did you build you own WinMBF binaries or which ones did you take?

 

Edit: I think the official WinMBF executables were compiled without the RANGECHECK macro. This could make quite some difference on a map like this...

 

Edit2: Also, please run all ports with the exact same window dimensions (not fullscreen). Scaling is expensive...

Edited March 3, 2020 by fabian

[VGA]

I checked this port out, it's kinda good, I guess. Although I had to disable the laggy Vsync.

 

Not sure why I'd use this, though. I like 2x-native-res ports like Doom Retro and Crispy Doom (and GZDoom with downscaling) but Woof doesn't fix the "wall wiggle bug".

[fabian]

20 hours ago, VGA said:

Woof doesn't fix the "wall wiggle bug".

Not yet. This is already fixed in the v1.1.0 branch. 

 

Edit: Woops, this will include the long line wobble fix, not the wiggle fix, sorry!

Edited March 4, 2020 by fabian

[Revenant100]

8 hours ago, chungy said:

 

@Revenant100 Maybe you could try this build for performance? Same compiler for both 32- and 64-bit EXEs, hopefully they work (as fabian mentioned, the build system is rather broken so... it's being done manually); should be good for doing direct comparisons.

 

https://chungy.keybase.pub/woof-windows-bin.zip

These executables did not affect the performance.

 

7 hours ago, fabian said:

If you grant it some more memory, e.g. '-mb 256', it loads the map within seconds.

However, this launch parameter did. The map loaded instantly, and the framerate was hovering just above 1 FPS, now slightly edging out WinMBF.

 

Quote

Also, did you build you own WinMBF binaries or which ones did you take?

Straight from the idgames archive.
 

Quote

Edit2: Also, please run all ports with the exact same window dimensions (not fullscreen). Scaling is expensive...

Both ports were running straight out of the zip files at the default settings except for enabling the High Resolution option in each since a 320x200/240 window is a bit uncomfortably small on a 1080p screen.

[chungy]

3 hours ago, Revenant100 said:

These executables did not affect the performance.

Unless there's a common circumstance that can demonstrate otherwise, I would be pretty confident in saying only a 32-bit binary is needed. The cost of compatibility in going 64-bit-only isn't really worth it.

 

The decision is really up to Fabian, of course.

[Graf Zahl]

A map like is a very poor test case due to the high impact from the playsim and CPU cache - both elements where 64 bit's advantage is a lot less. In short: It's very uninteresting for making a 32 vs. 64 bit decision. For testing the renderer, maps like Frozen Time, or better P:AR would be recommended because those really stress test the renderer, not something that processes 100000 sprites - which is just slow no matter what. This is just like Nuts squared - an edge case far outside any realistic usage scenario.

 

 

 

[garbaged]

-

Edited March 5, 2021 by garbaged : slow deletion process

[Redneckerz]

7 hours ago, Revenant100 said:

Both ports were running straight out of the zip files at the default settings except for enabling the High Resolution option in each since a 320x200/240 window is a bit uncomfortably small on a 1080p screen.

So how would Woof! performance be when hardware acceleration is enabled?

[fabian]

Hardware acceleration should be enabled by default in Woof. Now it would be interesting how both ports perform at fullscreen resolution. 

[Danfun64]

Doesn't the 32 bit version save mbf compatible savegames, something which the 64 bit version is incapable of doing ATM?

[fabian]

1 hour ago, Danfun64 said:

Doesn't the 32 bit version save mbf compatible savegames, something which the 64 bit version is incapable of doing ATM?

Yes, right. 

[unerxai]

I'm somewhat ignorant about mapping formats beyond vanilla so forgive me for my question. Do I have to toggle compatibility settings to play "Boom" maps as opposed to "MBF" maps?

[fabian]

Boom is a subset of MBF. 

[Redneckerz]

Woof! has been given an article on Realm667 by yours truly.
 

[Gez]

On vendredi 6 mars 2020 at 9:06 PM, unerxai said:

I'm somewhat ignorant about mapping formats beyond vanilla so forgive me for my question. Do I have to toggle compatibility settings to play "Boom" maps as opposed to "MBF" maps?

The main gameplay impact of playing a Boom map in MBF is that monsters are now affected by friction and pushers/pullers.

[drfrag]

I'm playing 20ydoom.wad and demos desync, should they play? Most likely i already played it back in the day but i can't remember.

[fabian]

5 hours ago, Redneckerz said:

Woof! has been given an article on Realm667 by yours truly.

Cool, thank you very much! 

 

3 hours ago, drfrag said:

I'm playing 20ydoom.wad and demos desync, should they play? 

No idea. Which demos do you mean, the internal ones? Do they play in sync in PrBoom+?

[drfrag]

 Yes but i've noticed the text file says tested with PRBoom.

[fabian]

18 hours ago, drfrag said:

 Yes but i've noticed the text file says tested with PRBoom.

 

It's a Boom 2.02 demo, so it should be supported. Sync is fixed in GIT, thanks for noticing!

 

Edit: BTW, this is already desyncing in WinMBF. 

Edited March 10, 2020 by fabian

[taufan99]

Just tried this source port, and I like it a lot. Maybe you would like to consider adding the "whistle" feature for the helper dogs like in Eternity?

[fabian]

Nope, no new features are planned. This will stay MBF. 

[maxmanium]

6 hours ago, fabian said:

 

It's a Boom 2.02 demo, so it should be supported. Sync is fixed in GIT, thanks for noticing!

 

Edit: BTW, this is already desyncing in WinMBF. 

 

I don't know if this is relevant, but demos for MAP33 of sf2012_final.wad also desync since it has a three-key door.

[VGA]

All demos that use the 3-key bug should be banished from space and time.