MacOS ARM Scope issue

[173duprot]

[173duprot]

The scope is not scaling to the screen.

[173duprot]

The advanced crosshair is not scaling to the screen.

[173duprot]

The hacky

[173duprot]

fuck I misclicked lol

the hacky solution I found was to turn

	/* calculate the coordinates */
	center_x = ( ScreenWidth / 2 ) * gHUD.m_flScale;
	center_y = ( ScreenHeight / 2 ) * gHUD.m_flScale;

into

	/* calculate the coordinates */
	center_x = ( ScreenWidth ) * gHUD.m_flScale;
	center_y = ( ScreenHeight ) * gHUD.m_flScale;

in the ammo.cpp.

I don't think this is the proper solution, but it's what I'm working with for now.

[Buggem]

For me his also happens with the enhanced crosshair. By the way you should re-open the issue, it's a button next to the comment submit button

[Velaron]

Do you use DPI scaling or smth?

[Buggem]

Furthermore fix for the scope is changing cl_dll/hud/sniperscope.cpp drawing values to 2x, similarly to the ammo.cpp hack. No idea why this occurs.

EDIT: as velaron suggested, it could be related to DPI scaling. will check
EDIT: (I actually have no idea what DPI scaling is)

[Buggem]

After some research, I found the/a reason for this.

If you set your display resolution to the real resolution of your screen, and set it to that in CS16Client too, the scope+crosshair displays correctly. Most likely the reason it is a factor of 2 in your fixes is due to the fact that Macs usually tend to default to exactly 50% of the physical screen's maximum resolution. Some weird "retina scaling" quirk.

[Buggem]

Some images and their associated resolutions:

High-res

crosshair, 2560x1664

scope, 2560x1664

Low-res

NOTE: Despite the weird image res, this is a 1470x956 screenshot. My display can't even handle 1912p, no idea why it set that.

crosshair, 1470x956

scope, 1470x956

[a1batross]

What's the value of vid_highdpi cvar and what if you try to invert it?

Seems like an engine bug to me.

[Buggem]

@a1batross vid_highdpi is 1.

On a side note, I've written some (ugly and disgusting) code to fetch the backing scale factor, that confirms my suspicions.

#include <stdio.h>

#include <ApplicationServices/ApplicationServices.h>
#include <objc/objc.h>
#include <objc/objc-runtime.h>

int main()
{

	CGDirectDisplayID mainDisp = CGMainDisplayID();
	printf("%u disp ID\n", (uint32_t) mainDisp);
	CGSize mainDisp_size = CGDisplayScreenSize(mainDisp);

	// print disp dimensions in mm
	printf("w: %f mm\nh: %f mm\n\n",
		mainDisp_size.width,
		mainDisp_size.height
	);
	printf("w: %zu px\nh: %zu px\n\n",
		CGDisplayPixelsWide(mainDisp),
		CGDisplayPixelsHigh(mainDisp)
	);

	struct objc_class* nsScreen = objc_lookUpClass("NSScreen");
	struct objc_object* mainDisp_nS = ((struct objc_object* (*)(struct objc_class*, SEL))objc_msgSend)(nsScreen, sel_getUid("mainScreen"));

	double mainDisp_bSF = ((double (*)(struct objc_object*, SEL))objc_msgSend)(mainDisp_nS, sel_getUid("backingScaleFactor"));

	printf("backing scale factor: %f\n", mainDisp_bSF);

	printf("scaled w: %.0f px\nscaled h: %.0f px\n",
		CGDisplayPixelsWide(mainDisp) * mainDisp_bSF,
		CGDisplayPixelsHigh(mainDisp) * mainDisp_bSF
	);


	
	return 0;
}

out (1470x956)

1 disp ID
w: 290.568089 mm
h: 188.968091 mm

w: 1470 px
h: 956 px

backing scale factor: 2.000000
scaled w: 2940 px
scaled h: 1912 px

out (2560x1664)

1 disp ID
w: 290.285710 mm
h: 188.685711 mm

w: 2560 px
h: 1664 px

backing scale factor: 1.000000
scaled w: 2560 px
scaled h: 1664 px

[a1batross]

In fact, we shouldn't care about window scaling factor at all. We always need to draw in real pixels, instead of what operating system and compositor tries to impose on us.

On Windows, we explicitly disable it by telling the OS that we are "aware" of non-default DPI scaling. Same on X11 and Wayland.

[a1batross]

@a1batross vid_highdpi is 1.

@Buggem and what if you invert it, save the config and restart the engine?