Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

This is Woof! 12.0.2 (Dec 13, 2023)

Recommended Posts

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. 

Share this post


Link to post
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+.

Share this post


Link to post

 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.

Share this post


Link to post
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?

Share this post


Link to post

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?

 

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post
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 by fabian

Share this post


Link to post

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".

Share this post


Link to post
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 by fabian

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

 

 

 

Share this post


Link to post
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?

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post
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. 

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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+?

Share this post


Link to post
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 by fabian

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×