V_NOSCALESTART, software, graphic offsets, and resolution don't go well together.

[Lat']

So, this flag, which is used by the SCORE / TIME/ RINGS HUD as well probably others behaves extremely weirdly in software rendering if offsets are used to modify a sprite's location ever so slightly while using any other resolution than 320x200;

In these screenshots, offsets of the SCORE HUD have been modified to +18 on the Y axis.

Spoiler: 1600x900 (offsets are barely taken into account)

Spoiler: 640x400 (offsets are half taken into account)

Spoiler: 320x200 (intended behavior)

Do note that this is also an issue with any of the higher green resolutions as well.

OpenGL as a whole behaves as if the game was always on 320x200, so it's only an issue with software.

I don't really know why some of the vanilla HUDs use V_NOSCALESTART while some others don't (Exemple: Monitors icons, those use V_SNAPTO flags, but SCORE/TIME/RINGS and lives use V_NOSCALESTART), especially because this flag makes it a pain to align custom HUDs properly with vanilla's since not many people even know what this flag does if they know it exists to begin with, and it requires a few extra steps that wouldn't be necessary if they used V_SNAPTO flags which are anyway advertised on the wiki as better, heck, the wiki even says that V_NOSCALESTART is NOT recommended in most cases anyway.

 

[Monster Iestyn]

Whatever the wiki says may be a leftover from when the video flags list was mostly relevant only for cechoflags, to be fair. =V

Anyway the issue itself looks quite simple, the offsets of the graphics don't appear to be scaled at all ...so in 320x200 they're as expected, in 640x400 they're only half as much since all dimensions are 2x as large, and in 1600x900 they're tiny because now the screen height is over 4x as large as the base 320x200 resolution. This probably wouldn't be too hard to fix, though I'm not entirely sure if they're supposed to be scaled with the patch scale or not, hm...

What V_NOSCALESTART does is disable the code to scale x/y positions with respect to resolutions. This means x and y will always be the exact number of pixels from the left and top edges of the screens respectively! So in a 640x400 reolution for example, a position of (320, 200) is actually the center of the screen rather than just beyond the bottom right corner.

From what I've been able to gather, the HUD code uses V_NOSCALESTART so it can scale the x/y positions of the HUD elements manually, rather than relying on the patch drawing functions to do the scaling automatically.


EDIT: welp I guess the offsets ARE scaled actually, I need to look into this a bit more perhaps. Ignore the last statement, I think I have it at last: the offsets themselves aren't multiplied by dupx/dupy when V_NOSCALESTART is in effect. They would be normally, but V_NOSCALESTART ignores dupx/dupy for x/y (which the offsets are added to), so the offsets end up unscaled too. The only way to fix this would be to make sure offsets are ALWAYS multiplied by dupx/dupy regardless of V_NOSCALESTART, if that is a good idea at all.