fabian Posted March 3, 2020 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. 0 Share this post Link to post
Revenant100 Posted March 3, 2020 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+. 6 Share this post Link to post
drfrag Posted March 3, 2020 (edited) 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. 0 Share this post Link to post
chungy Posted March 3, 2020 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? 0 Share this post Link to post
Graf Zahl Posted March 3, 2020 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? 8 Share this post Link to post
chungy Posted March 3, 2020 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 0 Share this post Link to post
Redneckerz Posted March 3, 2020 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. 1 Share this post Link to post
fabian Posted March 3, 2020 (edited) 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 0 Share this post Link to post
VGA Posted March 4, 2020 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". 0 Share this post Link to post
fabian Posted March 4, 2020 (edited) 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 1 Share this post Link to post
Revenant100 Posted March 4, 2020 (edited) 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. 2 Share this post Link to post
chungy Posted March 4, 2020 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. 0 Share this post Link to post
Graf Zahl Posted March 4, 2020 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. 2 Share this post Link to post
garbaged Posted March 4, 2020 (edited) - Edited March 5, 2021 by garbaged : slow deletion process 0 Share this post Link to post
Redneckerz Posted March 4, 2020 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? 1 Share this post Link to post
fabian Posted March 4, 2020 Hardware acceleration should be enabled by default in Woof. Now it would be interesting how both ports perform at fullscreen resolution. 1 Share this post Link to post
Danfun64 Posted March 5, 2020 Doesn't the 32 bit version save mbf compatible savegames, something which the 64 bit version is incapable of doing ATM? 0 Share this post Link to post
fabian Posted March 5, 2020 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. 2 Share this post Link to post
unerxai Posted March 6, 2020 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? 0 Share this post Link to post
Redneckerz Posted March 9, 2020 Woof! has been given an article on Realm667 by yours truly. 3 Share this post Link to post
Gez Posted March 9, 2020 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. 2 Share this post Link to post
drfrag Posted March 9, 2020 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. 0 Share this post Link to post
fabian Posted March 9, 2020 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+? 2 Share this post Link to post
drfrag Posted March 9, 2020 Yes but i've noticed the text file says tested with PRBoom. 0 Share this post Link to post
fabian Posted March 10, 2020 (edited) 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 0 Share this post Link to post
taufan99 Posted March 10, 2020 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? 0 Share this post Link to post
fabian Posted March 10, 2020 (edited) Nope, no new features are planned. This will stay MBF. 0 Share this post Link to post
maxmanium Posted March 10, 2020 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. 0 Share this post Link to post
VGA Posted March 10, 2020 All demos that use the 3-key bug should be banished from space and time. 0 Share this post Link to post