[Italianmoose]

I've started looking into my issue with aspect locking with wide resolutions, and I've discovered that the rate of tracking is based upon a fixed number of pixels, which does not depend on the x and y resolutions. A possible solution involves scaling the tracking speed based upon the x and y resolutions (using the original resolutions as a baseline), however I'm not that confident a coder and it would require a fair amount of change to the hudlock.cpp file.

Any help would be hugely appreciated. (IRC keeps hiccuping and losing my train of thought)

[chief1983]

So it's easier to get a lock at 640x480 than 1920x1200?  I thought that it seemed harder to get a lock over time, must have been because my monitor kept getting bigger

[Italianmoose]

Bascially, yeah. I can't get a recording, but the locking wotsit for me is impossible to lock onto a moving target if it's moving across the screen in the x-direction at all! It waves all over the place. I'd imagine a higher resolution would also slow down the locking speed.

[BirdofPrey]

Oh, is that why I have to actually dogfight basilisks when I used to just send a couple pack of hornets their way so I have more time dogfighting the dragons?

[jr2]

Heh, mayhaps forcing 1600x900 on the 3DFX nGlide as a res in FS1 was the cause of my crummy dogfighting in FS1 instead of my louse controller skills, then.. maybe.  (I think it's just 640x480 stretched with the aspect ratio kept).


/offtopic

[Italianmoose]

Well, after spending four hours hammering away at it today, I have succeeded in making the problem worse. Doh! 

[Italianmoose]

Ouch, higher resolutions really do slow down missile tracking!

Times in seconds
640x480           1920x1080          3840x2160
2.3                    3.1                      5.9
2.3                    3.0                      5.7
2.2                    3.0                      5.8
2.2                    3.1                      5.3
2.3                    3.0                      5.8
2.2                                               5.8

The setup was a fighter at (100,500,0) with the player facing up the y-axis. EDIT: Missile used was a Harpoon.

Looks like there are two issues.
1) Higher Resolutions slow down tracking
2) Wide aspect ratios maul the tracking when the player is yawing his craft

[Spoon]

I have suspected something like this was going on for a while now, good to see it being confirmed here.

[Herra Tohtori]

Well, sounds like the speed of the tracking cursor needs to be measured in angles rather than pixels.

This should also be done taking into account the FOV setting used by the player.


Measure the tracking speed with stock FOV and the highest stock resolution (1024x768 I believe) and calculate the intended angular velocity from that.

[jr2]

What if the high resolution (1024x768) had that bug, too?  The original FS1 was 640x480, tracking speed set and accounted for.  Then with 1024x768, because of the bug, the tracking speed decreased (it took longer) but it wasn't enough to notice?


In other words, should the baseline be 1024x768 or should it actually be 640x480?

[chief1983]

Just FYI, MageKing17 proposed a patch that looks promising in Mantis #3140.

[Herra Tohtori]

What if the high resolution (1024x768) had that bug, too?  The original FS1 was 640x480, tracking speed set and accounted for.  Then with 1024x768, because of the bug, the tracking speed decreased (it took longer) but it wasn't enough to notice?


In other words, should the baseline be 1024x768 or should it actually be 640x480?

I would say it depends on which game we're talking about, FS1 or FS2.

It's entirely possible that the "bug", or questionable coding decision, was there right from the beginning, but the games are different enough that both had their own balancing and testing done to them.

You would need to pick something to use as a reference point. And I think the tracking speeds were originally balanced for the highest possible resolution for each game. 1024x768 for FS2 and... 640x480 for FS1, I guess.

[Italianmoose]

You could set it so it loads the lower res corrections for FS1-based mods, but defaults to the higher-res corrections?
It's a bit more complicated, but it could keep the "feel" of the original FS1 missiles.

As it happens, thanks to MageKing17   's fix, the aspect ratio issue basically eliminated. Though it's probably worth checking to see if it's altered normal-ratio tracking in any way.
I can definitely feel the difference with tracking speeds though, especially trying to take out the Sathanas beam turrets (as an example). I used to be able to take out all four, now I struggle to get two as I spend so much time trying to get Helios torpedoes to lock after the initial pass.

[AdmiralRalwood]

Though it's probably worth checking to see if it's altered normal-ratio tracking in any way.

It will have, but the difference should be insignificant (going from a 4:3 ratio to perfectly square). The difference might be slightly more noticeable on 16:9 and 16:10, but the old behavior was clearly wrong anyway.

[chief1983]

So is there no easy way to make 4:3 the baseline and the other ratios behave like it, instead of it being 1:1?

[Herra Tohtori]

Easiest solution would be to limit the starting position of the tracking cursor to a 1024x768 area in the center of the image.

Or 640x480 in the case of FS1 era weapons.

Technically it should be also possible to scale this to any resolution or aspect ratio, but if you want the cursor to appear in the edge of screen then it would have to move faster in the horizontal than in the vertical direction.

[AdmiralRalwood]

So is there no easy way to make 4:3 the baseline and the other ratios behave like it, instead of it being 1:1?

The math is more complicated (i.e. I wouldn't know how to write it), and I'm not sure there's really a massive need for yawing to result in 1-and-a-third times the movement of the tracking gauge as pitching.

Easiest solution would be to limit the starting position of the tracking cursor to a 1024x768 area in the center of the image.

Or 640x480 in the case of FS1 era weapons.

Technically it should be also possible to scale this to any resolution or aspect ratio, but if you want the cursor to appear in the edge of screen then it would have to move faster in the horizontal than in the vertical direction.

The starting position of the tracking cursor is tied to a circular radius around the target's screen position, equal to the weapon's pixels-per-second multiplied by the weapon's minimum lock time. There's an exception for if the target's screen position is >= that distance from the center of the clipping area; in that case, it just uses that location as the starting location. This is no doubt the cause for the different lock times in Italianmoose's earlier test; if the target were dead-center in middle of the screen, I think the tracking times should be identical regardless of resolution.

[Yarn]

I made a test mission (link is at the end of this post) to see whether there's really a difference in lock time between 640x480 and 1024x768 and whether retail worked differently. I also tested 1366x768 as well as MageKing17's patch. Here are my results, using my phone's stopwatch:

Retail 640x480
3.09
3.09
3.07
3.06
3.13

Retail 1024x768
5.00
4.89
4.87
4.92
4.89

FSO r11242 640x480
2.30
2.31
2.29
2.27
2.29

FSO r11242 1024x768
3.64
3.63
3.66
3.64
3.70

FSO r11242, 1366x768
4.87
4.88
4.90
4.84
4.92

FSO r11242 w/ MageKing17's patch, 640x480
1.94
1.95
1.99
2.03
1.98

FSO r11242 w/ MageKing17's patch, 1024x768
2.73
2.75
2.72
2.79
2.80

FSO r11242 w/ MageKing17's patch, 1366x768
2.72
2.80
2.75
2.78
2.70


Here's what I notice from the results:

• In both retail and FSO, lock time is about 1.58 times faster in 640x480 than in 1024x768.
• Lock time in FSO is about 1.34 times faster than in retail.
• MageKing17's patch does indeed make aspect ratio have no effect on lock time, but it does make lock time in 4:3 resolutions about 1.17 times faster than FSO r11242.

If you ask me, I would try to match the retail 640x480 times. Why? Because it's probably how FS1 worked, and I doubt that the developers of FS2 would deliberately slow down the lock times in the code rather than the tables.


Here is the mission that I used: https://dl.dropboxusercontent.com/u/89353583/FreeSpace/LockTest.zip

[chief1983]

how did we screw up the 640x480 lock time compared to retail?

[karajorma]

I'm guessing that resolutions only gradually became larger so we just assumed we were getting old.