Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Italianmoose on February 06, 2015, 02:21:52 pm
-
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)
-
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 :P
-
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.
-
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?
-
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
-
Well, after spending four hours hammering away at it today, I have succeeded in making the problem worse. Doh! :banghead:
-
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
-
I have suspected something like this was going on for a while now, good to see it being confirmed here.
-
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.
-
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?
-
Just FYI, MageKing17 proposed a patch that looks promising in Mantis #3140 (http://scp.indiegames.us/mantis/view.php?id=3140).
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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 (https://dl.dropboxusercontent.com/u/89353583/FreeSpace/LockTest.zip)
-
how did we screw up the 640x480 lock time compared to retail?
-
I'm guessing that resolutions only gradually became larger so we just assumed we were getting old. :p
-
I think it might be worth investigating where in the revision history the lock time for retail resolutions became accelerated, might shed some more insight into the overall behavior changes.
-
I've attached a new patch to the Mantis issue (http://scp.indiegames.us/mantis/view.php?id=3140) that may fix both problems simultaneously; only downside is that the way the HUD gauge renders may need changing if we want the visual for the lock indicator to still move across the entire screen. Could probably do some sort of scaling based on the resolution of the HUD gauge in comparison to the resolution of the virtual frame...
-
I think it would also start to get noticable over time as the box in which the targetting functions gets relatively smaller and smaller in comparison to the rest of the screen as resolution and pixel density increases. (It could make a fun addition though - better fighters can lock on over a wider area!)
-
I think it would also start to get noticable over time as the box in which the targetting functions gets relatively smaller and smaller in comparison to the rest of the screen as resolution and pixel density increases. (It could make a fun addition though - better fighters can lock on over a wider area!)
The size of the "virtual frame" the tracking happens in has no effect on the cone in which aspect tracking starts.
-
Fair enough, my bad. I'll get to testing lock times to quantify the effects of the new patch.
-
New patch, same testing method as before:
1024x768: 2.2, 2.2, 2.5, 2.3, 2.5, 2.2
1920x1080: 2.4, 2.2, 2.5, 2.3, 2.3, 2.4
5760x1080: 2.4, 2.5, 2.4, 2.5, 2.3, 2.3
3.7.2 RC5 (i.e. no fixes whatsoever):
1024x768: 2.5, 2.5, 2.4, 2.5, 2.1, 2.5
1920x1080: 3.2, 3.3, 3.3, 3.2, 3.3, 3.2
5760x1080: 8.7, 8.6, 8.7, 8.6, 8.7, 8.5
ATM I can't compile FS2O under windows so I can't test extremely high resolutions. The minimum lock time for the Harpoon (according to weapons.tbl) is 2.0 seconds.
-
While trying to test MageKing17's newest patch, I think I found out why my lock times are different between retail and FSO.
In retail, the lock triangle starts at one of these points, whichever is farther from the target:
- The center reticule
- A point far enough from the target such that at least a certain amount of time is necessary for the triangle to reach the target, assuming the player and the target are not moving
This means that if the triangle would start between the target and the center reticule, then it instead starts at the reticule.
FSO, however, doesn't appear to perform this check, so if the target is far enough away from the reticule, then the triangle starts too close to the target. I will check to see when this behavior was introduced.
-
I think this was changed because of TrackIR. Because of TrackIR, the assumption that the player's view direction would always be in the center of the screen was no longer always valid. Therefore, the lock code had to be updated to match this assumption.
-
That sounds likely. I found that the behavior changed sometime between 3.6.9 and 3.6.10, and according to the SVN log, the TrackIR stuff was added during that time.
I did some more testing, this time while pointing my ship at the target. At 640x480 resolution, the lock time was about 2.0 seconds (consistent with what's in weapons.tbl) in both retail and FSO r11315! And yes, I also tested the mission in FSO r11315 without moving my ship and got the same times that I got in r11242, so lock times don't seem to have changed since then. This means that, in cases where retail would put the lock triangle at the center reticle, FSO is putting it somewhere between the two points described in my previous post.
-
That sounds likely. I found that the behavior changed sometime between 3.6.9 and 3.6.10, and according to the SVN log, the TrackIR stuff was added during that time.
I did some more testing, this time while pointing my ship at the target. At 640x480 resolution, the lock time was about 2.0 seconds (consistent with what's in weapons.tbl) in both retail and FSO r11315! And yes, I also tested the mission in FSO r11315 without moving my ship and got the same times that I got in r11242, so lock times don't seem to have changed since then. This means that, in cases where retail would put the lock triangle at the center reticle, FSO is putting it somewhere between the two points described in my previous post.
Why would lock times have changed since r11242? No changes to hudlock.cpp have been committed since r10622, and that was just the debug console...
While trying to test MageKing17's newest patch, I think I found out why my lock times are different between retail and FSO.
In retail, the lock triangle starts at one of these points, whichever is farther from the target:
- The center reticule
- A point far enough from the target such that at least a certain amount of time is necessary for the triangle to reach the target, assuming the player and the target are not moving
This means that if the triangle would start between the target and the center reticule, then it instead starts at the reticule.
FSO, however, doesn't appear to perform this check, so if the target is far enough away from the reticule, then the triangle starts too close to the target. I will check to see when this behavior was introduced.
The fundamental logic of hud_calculate_lock_start_pos() doesn't seem to have changed from retail, though...? If the hypotenuse of delta_x and delta_y (distance of the target's projected position from the center of the screen in the "virtual frame") is greater than or equal to Lock_start_dist, the starting position is set to the center of the virtual frame. The actual position it gets drawn at may vary greatly from its coordinates in the virtual frame; however, the actual lock time should (theoretically, and assuming I actually understand this code, which is far from guaranteed) be the same.
-
Why would lock times have changed since r11242? No changes to hudlock.cpp have been committed since r10622, and that was just the debug console...
I was only verifying that my result from r11315 was indeed not caused by a recent change, whether to hudlock.cpp or some other file. I didn't think that it would be different, but it seemed like a good idea to check anyway.
-
Out of curiousity, how much will this affect game balance? In theory it should make most missions easier, though stock missions will return to the difficulty we remember them to be (I'm thinking the de-fanging of the Sathanas in particular)
-
Well, game balance was being slowly eroded from retail by this. It really should just restore the natural game balance for this part of the game.
-
Regardless, the latest version of the fix in Mantis #3140 was committed and is in the latest round of nightlies.