This is Woof! 15.0.0 (Nov 23, 2024)

Alright, thanks. I guess that's one way to maintain decent framerates, besides multithreading.

I have a question, was integer scaling removed due to incompatibility with DRS?

Hi - total noob here. I'm wondering if there's a way for Woof to change the monitor resolution on launch? Currently I'm changing my VGA CRT monitor's resolution to a custom 640x400@140hz resolution right before launching Woof, but could the game do that step for me? Perhaps a command line parameter or something in the .cfg? Thanks!

3 hours ago, rzh said:

I have a question, was integer scaling removed due to incompatibility with DRS?

Integer scaling sounds good, but it's difficult to use in practice: it only works well at some resolutions. It is not compatible with DRS, we could have added a separate mode for it, but we decided not to complicate the code. Have you used it?

2 hours ago, matijaerceg said:

I'm wondering if there's a way for Woof to change the monitor resolution on launch?

No, Woof never changes the desktop/display resolution. Not sure if this feature would work well on all platforms, on Windows it is very annoying in some old programs.

On 12/27/2023 at 3:16 AM, rfomin said:

Have you used it?

I used it whenever I felt like playing at the original low-resolution (sometimes I preferred to use 320x200 with integer scaling rather than 640x400). Sure it made the actual game window smaller, since neither 320x200 or 640x400 scale perfectly on my monitor, but non-integer scaling looks blurry in comparison at that resolution.

I've just tried the "Triple" resolution option for the first time. Amazing!

One thing I noticed: Is it just me or are widescreen statusbars not properly fit to screen size? I'm using a width for STBAR replacements of 426px and I'm seeing minor seams on both sides. That didn't happen before with earlier dev snapshots (or it did and I'm just noticing it now). Maybe the laptop display I'm currently using instead of my large monitor is also simply screwing things up.

3 hours ago, NightFright said:

I've just tried the "Triple" resolution option for the first time. Amazing!

 

One thing I noticed: Is it just me or are widescreen statusbars not properly fit to screen size? I'm using a width for STBAR replacements of 426px and I'm seeing minor seams on both sides. That didn't happen before with earlier dev snapshots (or it did and I'm just noticing it now). Maybe the laptop display I'm currently using instead of my large monitor is also simply screwing things up.

It definitely did it before. In earlier versions 426px wide status bar fits perfectly only when "high resolution" was set to "yes". Otherwise you'd need to use a 428px wide stbar...

Integer math is to blame, along with the constraint that horizontal resolution needs to be rounded to the nearest multiple of 4. (Constraint of SDL paletted rendering, see Fabian's comment here.)

1x Scale: 16:9 horizontal pixels needed = 426.6667 -> round up to 428. Status bar width = 426 x 1 = 426 -> status bar not wide enough.

2x Scale: 16:9 horizontal pixels needed = 853.3333 -> round down to 852. Status bar width = 426 x 2 = 852 -> status bar wide enough.

3x Scale: 16:9 horizontal pixels needed = 1280. Status bar width = 426 x 3 = 1278 -> status bar not wide enough.

4x Scale: 16:9 horizontal pixels needed = 1706.6667 -> round up to 1708. Status bar width = 426 x 4 = 1704 -> status bar not wide enough.

The moral of the story here is that 426px is not wide enough, it should really be 428 px.

I followed the measures imposed by the Unity port, hoping it would fit in all cases. If I have to add 2px for all the statusbars in my widescreen HUD mod, I'm entering a world of pain...

Plus: To make things worse, in ports like Crispy which use 400p, the 426px versions are still needed, too. That's... not ideal.

Crispy can definitely use > 426 px wide status bars. It center-aligns, so having one wider than your screen is no problem. 

I guess in general, the best choice would be a widescreen bar without defined borders on both sides, with dimensions like e.g. 576×32 or something. Best example is the Rekkr statusbar. Covers all possible scenarios.

8 hours ago, NightFright said:

I guess in general, the best choice would be a widescreen bar without defined borders on both sides, with dimensions like e.g. 576×32 or something. Best example is the Rekkr statusbar. Covers all possible scenarios.

This would be perfect, but I have restored the 426 width in the current master. At the moment we are experimenting with various parameters.

17 hours ago, rzh said:

I used it whenever I felt like playing at the original low-resolution (sometimes I preferred to use 320x200 with integer scaling rather than 640x400). Sure it made the actual game window smaller, since neither 320x200 or 640x400 scale perfectly on my monitor, but non-integer scaling looks blurry in comparison at that resolution.

I guess we should restore the integer scaling mode then. @fabian What do you think?

12 minutes ago, rfomin said:

I guess we should restore the integer scaling mode then. @fabian What do you think?

Fine with me, but only in non-DRS mode. 

Integer scaling in fixed "low" resolution modes like x1,x2,x3 and x4 would be fine for the pixel lovers. And most old or low spec PCs should be able to handle those resolutions. For everything above x4 is DRS the ultimate thing in my opinion. So every user should find its perfect option.

426px wide statusbars confirmed to be working as intended again with 3x res in latest snapshot. Be praised, once again!

Or what about a switch to toggle between "DRS mode" and a "fixed Integer scaling Mode" to say Woof how it should handle the selected resolution?

So the problem with extreme high resolution Displays is gone, when the user can say resolution, for example any 200p based resolution like 1200p, and then could choose to handle it as maximum target-resolution for DRS or handle it as fixed resolution with integerscaling.

Edit: Please forget what i said about integerscaling. I thought it was meant in which steps DRS switches the resolution. That would be too big and really notable steps to switch.

I like integer scaling.  It keeps the ratio correct, the feel of the game true and everyone understands what 2x, 3x, 4x etc means.  Nice and simple.  And if you've got a huge monitor with billions of pixels I'm sure a wee border around the game isn't the end of the world.  I have a 32" 1440p monitor and I set a custom resolution to run Woof! at 1400p and it looked great even with the pretty small border.  Anyway, that's just my daft wee thoughts. :)

BTW, for anyone who wants to try it, here's a ready-to-use version of Cheello's voxel pack. Latest Woof dev snapshots run it perfectly. 

woof_voxels.zip

6 minutes ago, NightFright said:

BTW, for anyone who wants to try it, here's a ready-to-use version of Cheello's voxel pack. Latest Woof dev snapshots run it perfectly. 

woof_voxels.zip

What's the method to run voxels in Woof?

Well, I'm using a launcher (DoomRunner) for this, but in general, it's as simple as adding -file woof_voxels.zip to your command line.

9 minutes ago, s4f3s3x said:

What's the method to run voxels in Woof?

With dev version, just put voxel_doomII_v2_1.zip from https://www.moddb.com/mods/voxel-doom-ii/ into the autoload folder or run it with the -file command. Note that it's not finished yet, there are some minor issues and we plan to tweak it a bit to improve performance.

Cool, wasn't aware of that release. Seems to contain even more voxels than mine. Colored blood doesn't seem to work with voxels, btw. Not sure if it's due to something inside of this pack or a port-related thing.

21 minutes ago, NightFright said:

Colored blood doesn't seem to work with voxels, btw. Not sure if it's due to something inside of this pack or a port-related thing.

We haven't implemented it yet. Currently we are in the middle of development, bugs and unfinished features are expected ;)

Well, I gotta say it already works quite well, all things considered.

14.0.2 seems to have an issue with UMAPINFO on Doom II where starting a new game on episodes other than 1 on Nightmare will just send you to MAP01. Other skill levels work as expected.

48 minutes ago, Dreemurr Deceevurr said:

14.0.2 seems to have an issue with UMAPINFO on Doom II where starting a new game on episodes other than 1 on Nightmare will just send you to MAP01. Other skill levels work as expected.

Thanks for the report, it will be fixed in the next version.

On 12/26/2023 at 4:43 PM, rzh said:

I have a question, was integer scaling removed due to incompatibility with DRS?

It's more that it's incompatible with aspect ratio correction. The only resolutions that can be integer scaled with 5:4 pixels is multiples of 1600x1200.

Outside of that resolution, integer scale becomes kind of meaningless, because either the horizontal or vertical would not be integer scaled if the other is.

Quote

One thing I noticed: Is it just me or are widescreen statusbars not properly fit to screen size?

Indeed not if it is 426 wide. Try out the status bar in a higher res port like GZDoom or DSDA/PrBoom. There are tiny gaps to the left and right. It must be 428 wide with the expectation that the leftmost and rightmost pixel columns will be cut off a bit.

The alternative would be coming up with a new port standard for aspect-ratio-agnostic status bars where the left and rightmost borders, if desired, could be separate patches that are drawn on the edges of the screen.

Quote

I guess in general, the best choice would be a widescreen bar without defined borders on both sides, with dimensions like e.g. 576×32 or something. Best example is the Rekkr statusbar. Covers all possible scenarios.

This for sure. And not just because of the 16:9 rounding, but also because 16:10 and 3:2 monitors exist (and in somewhat popular platforms such as Steam Deck, or Macs, and increasingly windows laptops as well)

And 21:9 has a similar issue where actual 21:9 labeled resolutions are actually anywhere between 21.3333:9 to 21.5:9, so if you do the math on a 240px tall 21:9 screen to arrive at 560px wide bars, it is too short to span actual "21:9" resolutions. That's why the correct number is 574px. But just a tiny bit more: 576px covers the next widest monitor standard which is 24:10.

32 minutes ago, Trov said:

 

And 21:9 has a similar issue where actual 21:9 labeled monitors are actually 21.5:9, so if you do the math on a 240px tall 21:9 screen to arrive at 560px wide bars, it is too short to span actual 21:9 resolutions.

The lesser-known truth is that 21:9 was only a marketing term from Philips, that the customers could compare these numbers with the 16:9 TVs.

By the way, this Philips TV had a resolution of 2560x1080 which is not 21:9.

Most used ultrawide aspect ratios are 64:27 (2560x1080), 43:18 (3440x1440) and 12:5 (3840x1600). So 21:9 is not real, even it is communicated nearly everywhere.

I wouldn't ride the 426px train if the Unity port had not introduced it as its standard. There are people using those assets, so you should have them covered.

The question is how? Do you force all high resolutions to have black borders on the left and right so that the game is no wider than the status bar? Or do you scale the status bar slightly wider and therefore have some poorly scaled and repeated columns?

The Unity port gets away with it because it renders at a multiple of 426x200. But that isn't truly 16:9, which is the source of this problem.